Does UX Have “QA” to Catch Mistakes Early?

Most companies have QA Engineers who will check Developers’ work and fix bugs before they go live. There’s a layer of protection there.

HCD has that layer, but UX workers often aren’t given the time or resources to use that part of our?process.?

There is no guarantee that a company will invest time or money in catching UX problems earlier. Which types of problems should we catch before Engineering is coding (and would have to re-code to fix these, now or later)?

• The concept is wrong. Wouldn’t we like to know that earlier? Wouldn’t we like to know that before Engineers code a bad idea that’s likely to fail?
• The idea has potential, but its execution isn’t good. We think we have a good idea, but the design, flow, steps, and experience will likely be poor for the user. Wouldn’t we want to know that really early and before Engineering codes it?
• We solved the wrong problem, or we didn’t solve the right problem. Some teams allow UXers to do usability testing on a UX prototype. But these teams are often looking for, “Can people eventually stumble through this? If so, just ship it.” Our standards should be higher than that. In addition to testing for usability, we should check if we really solved the original problem without creating new problems for users.
• The design has room for improvement. You might have a decent idea and decent execution, but one or more rounds of usability testing will help you remove UX bugs and defects before they’re coded and baked into the product.

The above image shows QA testing as a cycle:

• Requirements
• Test planning
• Test case dev
• Test environment
• Test execution
• Test reporting

We’ll do all that for our code, but we rarely want to do that for our concept, idea, or?design.?

We assume we’ll “learn that later” once it’s out there. We evidently have endless time and money to experiment with an idea we hope to learn later was worth what we sunk into it.

UX has two “moments” of QA?testing

The first is usability testing.?

Sadly, this is often done on a prototype that can’t be used realistically. Rather than using a better tool like Axure (#NotSponsored), people use Figma, where you can’t even type in a field. It’s hard to test how well something matches people’s needs when people can’t use it realistically.?

We often blow the one chance we get to do good UX testing. We do the fastest testing we can do on the wrong type of prototype.?

The second is when this goes live to the?public.

At that point, it’s not “testing” anymore since we can’t fix it easily or cheaply. It has been released, it’s available to the public, and people can screenshot it and write about it.?

Even if it’s just an experiment, it’s somebody’s only experience of our product today. They didn’t get their usual A. They got our B, and who knows what they will get tomorrow. Lacking empathy for what this must be like for users, we carelessly drag them through cycles of guesses as we try to see what will make users do more of what we want.

It often takes a lot of guesses and lots of failures, and we’re still way off. Why??

Because we’re trying to optimize a user experience for business goals when an experience should be optimized for users’ needs and?tasks.

It’s that?simple.?

User experiences should be optimized for users, which leads to the achievement of business goals. You want people to convert, buy, use, etc.? Fine-tune the products and services for them.

If we care about testing code because we don’t want the public to deal with bugs, then we care about testing the concept and design. We don’t want the public to deal with bad idea or design. Great code for a bad idea or design is still a waste, dragging you far from agility or being lean.

?? dcx.to for courses, community, coaching, articles, & videos. I’m available for strategic and tactical product, service, and experience projects, leadership, and training.