Designing What Matters

Did QA Pass, or Is It Any Good?

  • Shared Standards
  • Clearer Experiences

A release goes out clean. No broken buttons, no console errors, every test case green. A search that finds nothing says "No results found" and stops there, with no hint about what to try instead. The confirmation message says "Operation completed successfully," which is true and tells the person nothing. The spacing between form fields is off in three places, not enough for anyone to file a ticket, just enough that the page feels slightly disorganized. Every check passed. The product is not good.

That is not a failure of QA. QA answered the question it was given, and answered it correctly. The question was whether the software does what it is supposed to do, and it does. What we have built is a process where that is the last question anyone asks before release, and it is the easier of the two questions worth asking.

It is the same question at a different fidelity

The second question is the one in the title, and the part I think we miss is that it is the same question at a different fidelity. Is this any good starts out testable. Does it function, and does it make sense to a real person. Functional validation and usability heuristics are the same instinct pointed at different evidence. Then the product gets real and the question grows up. Is the tone right for someone who is already frustrated. Does the whole thing hold together as something we would put our name on. Same question. It has just stopped being answerable with a pass or a fail.

The late version of the question is where craft lives, and craft is easy to dismiss because the evidence for it is hard to produce. Nobody files a ticket that says the vertical rhythm is inconsistent. What a user says is that the old tool felt easier. Alignment, spacing, elevation, the type scale, the restraint to use three colors instead of seven, a confirmation message that sounds like a person wrote it: people rarely notice any of it, and they respond to all of it. Two products that do the same job feel different because of a few hundred small decisions made consistently or made carelessly, almost never because of one large one.

I have sat in reviews where I could tell the product was not good and could not say why in a way that would survive the meeting. That is what it costs to leave the second question until the end: the only thing standing against a passing test report is a feeling, and a feeling loses.

The first question has gotten cheap to answer

This matters more now, because the first question has gotten cheap to answer. AI will produce something that works, quickly, in the right format. What it will not produce is a claim about this audience, this business, and what has already been tried here. That is what taste actually is: judgment built out of years of watching which solutions landed and which ones were technically fine and quietly ignored. The functional bar is close to free now.

The bar that decides whether the product is any good has not moved at all.

QA and UX are already asking it, in separate rooms

So the most useful move available is also the least dramatic. Get QA and UX asking the question together, starting at discovery instead of at the handoff. When QA is in the room that early, what it finds shapes the design instead of arriving too late to change anything. UX gains rigor and validation, QA gains the user lens and the heuristics, and both get a seat where the qualitative call gets made. Both groups are already asking whether the product is any good. We have been asking it in separate rooms, at different times, and calling it two jobs.

One quality thread: QA and UX together

UnderstandEmpathize · Define
ExploreIdeate · Prototype
MaterializeTest · Implement
Does it work, and does it make sense?

Functional validation and usability heuristics, checked side by side. QA and UX bring both lenses from the first stage.

Is it genuinely good?

Voice and tone, content quality, visual craft, and brand coherence, judged through business context, user psychology, and design principles.

Design system

Where these standards live, so the judgment has something to resolve to.

The question matures as the product gets real. Early it can be tested. Later it has to be judged against a standard, and that standard lives in the design system.

A standard nobody can point at is only a preference

There is one condition, and it is the whole difference between a standard and an opinion. If "is it any good" resolves to whoever is most senior in the review, or whoever argues hardest, it is not a standard. It is a preference with authority behind it. Taste that lives in one person's head only works when that person is in the room. It leaves when they do.

Did QA pass is a question with an answer. Is it any good is a question with a standard behind it, and that standard has to sit somewhere both people can point at. Voice and tone, content quality, spacing and type and color, what our brand feels like once it becomes software: those standards exist, they are growing, and they live in the design system. I want it to be something teams use, argue with, and improve.