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.
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