Writing about the parts of design that are hard to demo

Every product team I work with wants more research and has less budget for it than they would like. Almost all of them are sitting on a corpus of unprompted, timestamped, real-stakes user feedback that they treat as an operational cost rather than a research asset.

It is the support queue. Nobody in a support ticket is being polite to a researcher, performing for a moderator, or speculating about what they might do in a hypothetical situation. They hit a wall, in the middle of real work, and cared enough to write it down.

Reading twelve hundred of them changed a product I worked on more than any round of interviews I have run.

Most interface work starts with the happy path, because the happy path is the thing that is easy to imagine and pleasant to draw. The empty, loading, partial, offline, denied and failed states arrive later, if there is time, which there rarely is.

I have started working the other way round. I design the failure states before the success state, and it has made my work better in a way I did not expect: it changes the success state too, because the happy path stops being able to quietly assume things that are not true.

The fastest way to make a design system feel real is to ship components. Buttons, inputs, modals, something people can pull into a file this week. It is also the fastest way to build a library that becomes impossible to change eighteen months later.

Tokens first is slower to demonstrate and much harder to sell, because a token architecture looks like nothing. It is a spreadsheet of names. But it is the difference between a rebrand taking nine days and a rebrand taking a quarter.

I have now watched both approaches play out on the same organisation, and the gap is not close.

I have been on the reviewing side of about four hundred portfolios, mostly for product design roles at companies of thirty to five hundred people. The uncomfortable truth is that the first pass is fast. Ninety seconds is generous.

That is not because reviewers are lazy or the work does not deserve better. It is because a hiring manager is looking at forty portfolios in an afternoon, around their actual job, and they are trying to answer one narrow question before they invest real attention.

The question is: can this person tell me what they decided and why. Almost everything that gets a portfolio through the first pass is in service of answering it quickly.

A usability session in a quiet room with good lighting, a stable connection and a participant giving you their full attention will tell you whether your interface is comprehensible. It will not tell you whether it is usable, because comprehension is not the thing that fails in the field.

I have had two prototypes test perfectly indoors and fail completely within ten minutes of leaving the building. Both times the failure was environmental, and both times no amount of additional lab testing would have found it.

Designers going freelance ask me about rates more than about anything else, and most of the advice available is either a vague exhortation to charge more or a spreadsheet that assumes billable hours you will not have.

Here is what I actually do after six years of it, including the parts that took me an embarrassingly long time to work out, and the two pricing mistakes that cost me the most money.