Manifesto

Code is the medium. Figma shows what could be. Code shows what is. The gap between them is where assumptions live, and die. I prototype in code because that's where branching logic reveals the edge cases no wireframe anticipated, where constraints become visible before they become expensive, where the interaction is real enough to actually test. A designer who doesn't engage with code is having half the conversation.

Confusion is always data. When six out of six people miss a warning message, that's not six inattentive people. That's a design that failed to communicate. When users struggle, the instinct is to add more explanation. The right instinct is to change the design. Whatever users do; what they click, where they pause, what they ignore: it's all information. Their mental model is the one that matters, not the one you assumed.

Complexity is the job. The urge to simplify is correct. The temptation to avoid complexity is not. Some things are genuinely hard: declarations with nine nested data structures, corporate relationships that loop back on themselves, multi-party journeys where one person's answer rewrites another's options. You don't simplify your way out of that. You map the dependencies, design through the constraint, and test until it holds. Complexity is not an excuse for bad design. It's the reason good design is hard.

Map before you make. Understand the information architecture before you open a design tool. Build the dependency model before you touch a component. The work that happens before the design (the landscape mapping, the data modelling, the constraint analysis) is often the most important work on the project and the least visible. Skip it and you will redesign the same screen four times.

Labels are design decisions. "Benefits and other factors" confused every user. "Benefits and risks" didn't. The label was the problem. Every word on every screen is a design decision: hint text, error messages, button copy, page titles, empty states. These are not tasks for someone else to handle downstream. They are the interaction itself. The moment you treat copy as decoration, you have already failed.

The pattern isn't sacred. The outcome is. Design systems and conventions exist for good reasons. Following them is usually right. But "usually" is not "always", and the difference matters. When research shows a convention is failing; when progressive disclosure confuses rather than guides, when one-thing-per-page loses the thread of a connected set of questions, the right response is to break the pattern, document why, and test the alternative. Convention without evidence is just habit.

Document the decision, not just the outcome. Future teams need to know why. Not what was built: what was tried, what failed, what the research said, what the constraint was, what the alternative would have cost. Without that context, every new person starts from zero. Design knowledge belongs to the organisation, not the individual who happens to hold it this week. If it is not written down, it does not exist.

Accessibility is structural, not cosmetic. It is not added at the end of a sprint or audited at the end of a project. It is a constraint that shapes every decision from the first one: the information architecture, the reading level, the interaction pattern, the error message. Designing for the hardest user does not restrict what is possible. It makes the design better for everyone who encounters it. This is not a compliance position. It is a design position.

Start with the riskiest assumption. Not the easiest problem. Not the most enjoyable thing to design. The thing most likely to be fundamentally wrong, and most expensive to discover late. If the riskiest assumption survives contact with real users, the rest becomes easier. If it does not, better to know in week two than week twenty.

Individual designers produce work. Design teams produce capability. The shared component library, the documentation system, the ways of working, the prototype standards: these are design problems too. A team without infrastructure is just a collection of individuals doing similar things independently, slowly converging on decisions the last team already made. Building the conditions for good work is as important as the work itself.