The Question That Changed the Design
Have you ever asked - Who is this hardest for when designing a system?
The room goes quiet. Not uncomfortable quiet, a different quality entirely. The kind that happens when a group of capable professionals simultaneously understands that it does not have an answer to a question it should have been asking all along.
The question came in the middle of a design review that had been going well. The wireframes were done. The architecture was settled. The team had been professional throughout and the design was technically sound. Someone near the back of the room looked up from the screen and said four words that were not on the agenda: who is this hardest for?
Nobody answered immediately. Alex looked at the wireframes. The design had a user in it, of course it did, but that user was implicit, unexamined, averaged into the decisions without ever being named. The silence in the room was the collective recognition that the person who would find the design hardest to use was probably not the person the design had been built around.
What the room had been reviewing
Before the question arrived, the review had been evaluating what design reviews are structured to evaluate. Does it meet the technical requirements? Is it consistent with the component library? Does it follow the agreed interaction patterns? Is it on schedule? All of it legitimate. None of it the wrong question. And none of it asking who the design would fail.
A review process evaluates what it is structured to evaluate. The structure of this review did not include a question about the hardest user. And so that question had not been asked — not through negligence, not through indifference, but because the agenda did not have a line for it.
The design had an implicit user at its centre: someone who could read the instructions without difficulty, navigate the steps without support, understand the error messages without translation, and complete the verification without a second attempt. That user was not wrong to design for. They were just not the only person who would have to use the product.
The review had been thorough and the design was ready. The question changed what ready meant.
The structural fix is a single line
The absence the silence named is not expensive to address. It does not require a new team, a revised budget, or a different process. It requires one question added to the structure — to the design brief, to the review agenda, to the definition of done — in a form that is not optional and not supplementary.
Who is this hardest for, and what have we done about it?
Asked early and written into the process, that question is the intervention. Not at the end of the project, when the architecture is fixed and the cost of change is high. At the beginning, when a question in a brief costs nothing to answer and the answer shapes what is built. In the middle, when a question in a review can still redirect a flow, a content decision, an error state, a test plan. Before release, as a criterion that must be met before the product ships.
The reason the question is not already standard is not that it is expensive. It is that the processes governing design were built to evaluate what their authors cared about, and the hardest user was not in the room when those processes were written.
What made the question work in Alex’s review was that it arrived without defensiveness, a genuine inquiry that assumed the team capable, not a challenge to what they had produced. It was followed by something specific: not “users with lower digital literacy” as an abstract category, but a named-enough description of a real kind of person the team could treat as a design constraint. From there they knew what to do.
That specificity is what turns a question from a philosophical concern into a piece of work. Abstract categories — accessibility, inclusion, the underserved — are easy to acknowledge and difficult to act on. A specific person in specific circumstances is a brief. The question that produces a brief is the question that produces a change.
What the question produced
The first change was to the onboarding instructions. Written for someone who already understood the purpose of the system, they assumed knowledge that the hardest user would not have. Rewritten at a lower reading level, with the purpose of each step stated plainly before the step itself, they carried the same information to a wider range of people. The change took two hours. It had been available from the start of the project.
The second change was to the verification flow. Designed as a four-step process with each step branching on the user’s input, it required a correct first attempt to avoid a dead end that offered no clear route forward. The hardest user — the person the team named after the question was asked — would have reached that dead end reliably. The flow was restructured: two steps, linear, with a recovery path at every stage. Completion rates in user testing improved across all participants, not only the hardest case.
The third change was to the error messages. “Invalid input” had appeared throughout the design. The hardest user would not know from those two words what was invalid, why, or what to do about it. The messages were rewritten to name the error specifically and state the fix plainly. It took an afternoon.
The fourth change was a user test. Before the question, the test plan had included participants matched to the central profile, engaged users who knew what they were doing. After the question, a round of testing was added with participants who represented the hardest case. They revealed a fifth issue the team had not anticipated: a step considered self-explanatory that three of the four hardest-case participants read differently from how it was intended. The step was reworded before the product shipped.
None of these changes were large. Together they constituted the difference between a product that served most of its users and one that served a wider range. The only cost was the question that had not been on the agenda until someone put it there.
Designing for the outlier
The six-word question contains more than it appears to. Asking who the design is hardest for forces the team to ask something they had not been asked before: does this product genuinely help the person who needs it most, or does it add to the capability of people who were already capable without it?
The pattern is not unique to design reviews. Netflix has reported that 80 per cent of its subscribers use captions at least monthly, a feature built for people who are hard of hearing, now used daily by people watching in a second language, in rooms where the sound cannot be loud, putting children to sleep. Microsoft’s Inclusive Design programme names the principle: solve for one, extend to many. Designing for the person who finds the product hardest to use does not produce a narrower product. It produces a more useful one.
That is what the redesign of Alex’s verification flow demonstrated. A flow restructured to be navigable for the person who would have found it hardest did not improve completion rates only for that person. It improved them across every participant in the test. Designing for the outlier is the strongest test a design can face. It reveals what designing for the average conceals.
The design processes that do not have this question built in are not negligent. They evaluate what they were built to evaluate, and the people who built them made decisions about what mattered. The person who would find the product hardest to use was not part of those decisions. That has not been corrected, not because the correction is expensive, but because the people who govern design practice have not decided that it is required.
Four questions worth asking
Think of the last design review you participated in as a designer, a stakeholder, a commissioner, or a user tester. Was the question asked: who is this hardest for? If it was, what happened? If it was not, what do you think would have been different if it had been?
If you run or participate in design reviews, what would it take to add the human question as a standard agenda item not optional, not supplementary, but required? What is the obstacle, and is the obstacle proportionate to what it is protecting?
If you commission technology, does your brief require the supplier to answer the question: who is this hardest for, and what have you done about it? If not should it?
If you had one question to add permanently to your design process — not as guidance, but as a required criterion — who in your organisation would need to decide that? Have you ever been in the room where those decisions are made?
The silence in Alex’s design review did not last long. The team had a description within a few minutes grounded enough in the work to treat as a constraint. And once it was a constraint, they knew what to do with it. The question that was not on the agenda was the most productive thing the review produced.
Authors note
Alex is a fictional character. Their story is drawn from a combination of professional observation and personal proximity to real events. The experiences described are real. The person is not.
You’re reading The Next Evolution by Neil Catton, articles that explore the human world and the intersection of technology, they try and ask difficult questions - not to scare - but to inform. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com.
Neil Catton is the author of The Next Evolution, The Cognitive Crucible and The Shadow System - available on Amazon, and writes at the intersection of technology, ethics, and human purpose.