How to incorporate validation into the UX process

[jacquidow]

We are wondering how people incorporate validation into their design / ux process.

Currently our process is as follows:

1. PO and BAs build up requirements, they think of as much validation as possible and this goes into the acceptance criteria
2. UX designers design the user flows and screens
3. Handover to devs
4. More validation issues crop up, added to acceptance criteria
5. Handover to QA, who write acceptance tests
6. More validation issues crop up

Our first question really is, who’s responsibility should it be to write the validation?

And does anyone have any advice in general as it is something we seem to come up against on a very regular basis?

[dopamino]

hi @jacquidow
this is a great topic!

As the design team, we join the “validation steps” together with other stakeholders such product owners, marketing people and tech people.

We try, as much as we can:

• to list all the pro&cons (for instance, we want to add a new calendar feature because the current one is not fully responsive)
• to prioritise the things we want to deliver according to the validation KPIs (for instance, we have to make it responsive because our competitors already have it)
• to evaluate the cost in terms of effort (for instance, to add this feature we need a third party JS library)
• the impact on the product(s) (for instance, we use this widget for other platforms and we want to update it only for one)
• to define a metric(s) upfront to measure how precise the feature hits the planned targets

We don’t have a strict plan to check all these points and the design team is always pushing to define a process related to the validation

I hope it will help

[jacquidow]

Thank you! However, I’m not sure if there is a possible misunderstanding of ‘validation’ here, or if I have misread your response.

I am referring to the following:

Validation examples for a username field

• Username must be between 1 and 30 characters
• Username must not contain the following symbols…
• Username must be unique
• User cannot enter SQL code into the field

For each of the above we would also specify an error message.

[dougcollins]

Note: My thoughts are primarily geared towards new features where validation requirements are an unknown.

My best advice is to bring in more people earlier in your development process to help review and validate the project. Changes are less expensive earlier in the process, and by involving more people while still in low res mockups makes changes cheap and uncovers these types of validation issues.

These don’t have to be formal meetings you need to get on people’s calendar (though there can be value to that as well, which I’ll discuss in a moment). It can be as simple as creating your low res mocks on a whiteboard in a heavily trafficked area where you can grab people as they walk by for opinions or input. It can be popping into a neighbor’s cube with a highlighter and a sketch. You could simply post your designs in a public area.

There could also be value in gathering a small group of stakeholders for a quick review of low res mocks prior to refinement. Getting together a BA, PO, QA, Dev, and any relevant higher ups can help uncover a number of potential design issues, such as issues with dependencies, architecture, and validation. If you opt for this route, there are a few things you can do to make sure this doesn’t become another cumbersome time suck:

• Make it a short standard half-hour meeting with a rotating group of attendees.
• Come prepared to present the designs you’ve been working on.
• Prepare a list of no more than two targeted questions.
• If you are having issues with validation, be sure to ask specifically for potential validation issues.

There are a number of other benefits of having this kind of meeting. You get better feedback for iteration, your company gets better awareness of projects down the pipeline, and it grows organizational awareness and interdepartmental working relationships.

What do you think? Would either of these approaches be useful for you?

[jacquidow]

Thanks for this.

Currently we show our designs to a range of people at different stages throughout the process but we don’t tend to ask specifically about validation. This could be where we are going wrong as currently it is thought of before the designs and then after the designs.

One thing we do struggle with is incorporating validation into the prototypes as it often makes them over complicated and look quite messy and distracting from the design itself (our software is mostly form based, so showing all validation for all fields on a page would be crazy!) so we tend to just note it in the stories, or explain it during handover meetings.

[dopamino]

@jacquidow
I misunderstood My post was related to the “idea/concept validation”

[jacquidow]

No worries, don’t suppose you have any feedback on error handling ?

[dopamino]

Well, we prototype a lot of scenarios, we are willing to design for the “real life” and in the real life, shit happens.
We prototype

1. server validation - for instance, a time-out error
2. client validation - for instance, a wrong type of content such as number within an only text field

to do that we design the prototypes in HTML, CSS and JS.
For each widget and for each component available in the showcase we display the validations.

Here an example:

I hope this time my answer is more consistent with your question

[jacquidow]

That’s brilliant, thank you.

We use axure for prototyping and find that it is not great for error scenarios, it takes us longer to program them in than seems worth it. We have tried adding them static to the screen but feel it looks very confusing when trying to show stakeholders and get user feedback.

We have a general look and feel for error messages and this has been handled in a seperate document to make sure it is consistent across the application, however we are struggling with all the edge cases and details for each scenario (for example, date fields where 2 fields interact with each other, like a start and end date. Dates much be in the future, end date must not be before start date, both fields are mandatory, etc etc)

[dopamino]

for example, date fields where 2 fields interact with each other, like a start and end date. Dates much be in the future, end date must not be before start date, both fields are mandatory, etc etc

we have the same issue here. A lot of edge cases that are related to specific client needs/setups. We are trying to keep our showcase as much general as possible. When we receive a specific need/requirement we create an InVision prototype. We use Balsamiq or SketchApp and afterwards, we include such deliverable within the Confluence page (there’s a plug-in for that).

At the moment is working but we already know that it will not be the final process. The reason is that designers are the bottleneck of this process and we are looking for a tool/process/whatever to allow other stakeholders to be more autonomous in prototyping the solution draft.

[boatiesnz]

Thats why in the real world BA’s right business requirements which are signed off by stakeholders, which also include UX design which is a function not a job title. Validation as you put it, is part of the BRD in waterfall/rad, the SAD aligns with the BRD so the business required validation aligns with the system designed validation and when system testing occurs these validations are carried over without being lost.

I like to run fast iterations, I see why people think waterfall cant be fast or on the fly, that the project sponsor is getting chunks of development up front in their face weekly. whilst having the rigidity of the waterfall SDLC.

Ok some people want this UX Designer thing to be a seperate function, I dont know why, the more you know the more valuable you are. BA’s are the designers and one who cant do UX isnt worth hiring, that simple. Like wise call the BA a UX designer, if they dont know SDLC of whatever methodology you want from start to fisnish then they arent worth hiring.

Next Program Managers will be called “Gant Chart Checkers” because thats one of their functions so lets break down Progam management and over complicate SDLC for no good reason. Hybrid RAD and Waterfall has been working for years, its just the Agile guys hadnt worked in jig saw iterative based hybrid SDLC with customers before. So it needed somebody to pretend it was new and give it all a new name. My bad, I apologise.

I do hope one day though the Soft Dev industry will stop inventing red tape for the sake of it and just use existing methodologies that are flexible, iterative and fast, if you want them to be.

Just some banter and my 2c.