The design process is a trap.
For most projects, especially when the product designer has high domain knowledge, adhering to a strict process is an unnecessary waste of time.
It signifies either (1) a lack of confidence in your domain knowledge and design ability and/or (2) a lack of trust between members of a team.
The process is a way to narrow the range of your guesses. It is best for eliminating the lower end of the spectrum (cutting horrible ideas) and it is increasingly useless at the high end of the spectrum (picking the best idea).
It is risk-minimization, not product-optimization, and thus should be used piecemeal only and not worshipped.
The opposite of process is chaos, but an in-between is rapid adaptation, emphasis on rapid. Limit scope as much as possible, ship small things fast, and react to feedback quickly.
The design process assumes that dev time is the utmost priority, and this moves a bulk of labor into the design process. This is a faulty premise. The most valuable thing is not a dev’s time — it is the user’s happiness and the product’s usefulness to them. Once you eliminate your worst ideas, the only way to meet this goal of user happiness is to ship small things fast and get feedback. The faster and more frequently you can do this, the better. Sometimes you’ll ship the wrong thing, which will feel like wasting dev time. That’s ok. Saving dev time is only a worthy cause insofar as it helps you ship small things fast. Otherwise it is a vanity metric.
There is a gray area. You can’t ship total shit and you shouldn’t outright waste dev cycles building ideas with zero validation. But validation can come from an individual’s domain knowledge and doesn’t require going through the motions of a design process to prop it up every time.
A designer’s time is also valuable, and in many companies where cumulative dev hours outnumber design hours, design time is a resource of equal or greater value. Thus it should not be spent on trivial matters – like navelgazing for weeks while writing up personas, studying affinity diagrams, transcribing interview notes, mocking up 500 edge cases…
If you have a designer or PM whose domain knowledge you don’t trust, which requires outside validation for every project no matter how small, remove that person and hire someone you actually trust to move quickly and to leverage the knowledge they have.
So when is the process is useful? It has value, but you need to know when to use it.
- Generative research helps you figure out which way to point the product. Use when you don’t know which direction to go.
- Affinity diagrams help identify patterns. Pairs well with generative research when you are lost. Usually a waste once you’re deep in a domain.
- User journeys help you identify problems in more complex user workflows or in consumer products where every tap and click counts. In complex domains, it’s useful if you need to get your head around a complex process.
- Personas give you a sense of who you are building for, in cases where there are common archetypes. But more often than not, this is not the case! Most personas are just BS, made up primarily of poor fiction writing.
- Evaluative research helps you test your hypotheses. This is the most valuable step by far, and even when other steps are forsaken, this is the last line of defense between you and wasting dev time building garbage .
- Big PRD is useful for alignment when there is not enough alignment on a team. Failure-mode is writing PRDs for every little thing, even where alignment already exists, wasting time on wording and editing (instead of building and shipping, the only things that count)
Process is just a toolbox; keep it minimal; don’t worship; pick necessary tools only; stop navel-gazing; designer time is valuable; fuck your post-its; ship small things fast