Thread by @jmspool

Let's talk about the relationship of Software Quality Assurance and User Experience Design.

Any conversation about QA & UX needs to focus on the intersection of this question:

When is a product good enough to ship?

Software QA was first about "Does this thing do what the technical specifications say it should?"

(Early QA practices were derived from manufacturing QA, which was primarily about ensuring new parts were within specified tolerances.)

We now live in a day where there are no accurate technical specifications. That's a good thing, but it left QA without a way to judge "Is this thing good enough to ship?"

Theoretically, requirements could be a substitute for technical specifications. They seem like they'd work.

Yet, requirements are not specific enough. Nor are they usually validated to be correct.

Just because a product meets all requirements doesn't mean it's good enough.

This puts a burden on QA. What is the definition of "good enough?"

How does QA say "This is what we should / should not ship?"

It's made more difficult with unit testing.

At best, UT validates an individual unit "meets the specifications" for that unit.

However, UT doesn't tell is if the units, when assembled, do the right thing in harmony. Do they make a product good enough to ship?

This is where User Experience Design enters the picture.

Part of the responsibility of UX Design is to define what the users need. That definition needs to have a solid definition of Good Enough to ship.

QA can take advantage of that definition, to define its own Good Enough.

The distance between QA and UX has started to shorten. Once on opposite ends of the product spectrum, they are now becoming closer together in their philosophies.

The QA definition of Good Enough and the UX definition of Good Enough are becoming the same.

We can deconstruct Quality this way:

In the early days, QA was about eliminating flaws from a product's design. Bugs, reliability issues, resilience. All flaws.

UX was also about removing flaws. Flaws that caused frustration to the user.

(If a flaw doesn't frustrate a user, is it really a flaw?)

We'd test, identify the flaws, and redesign until the flaws were gone.

However, once all the flaws / frustrations are removed, what you have left is quite dry and boring.

It works, but it's missing something.

In UX, the next step was looking at adding in delight. Making the design be more than something purely functional.

Something that provides pleasure, increases the user's flow (in the Csikszentmihalyi sense of the word), or embodies meaning.

Improving a product by removing flaws / frustration is subtractive. You remove all the bits that shouldn't be there.

Improving the product by making it more delightful is additive.

They are very different processes and the QA practices and UX practices behind them have to vary greatly.

We rarely see discussion about how QA assesses if enough delight is in the product. We've only recently seen discussion in UX about this.

In both cases, Good Enough needs to be determined by the product team, thinking in both terms of frustration and delight.

The best-designed products come from teams who have their QA and UX folks work hand-in-hand to define Good Enough and use it as ship criteria.

This thread was inspired by a private discussion with @johncutlefish.