Good product design is not about Figma
I have been thinking about this for a while and it keeps getting clearer: good design is not about making things complicated. It is definitely not about the Figma file.
I am not writing this from above the problem. I am writing it because I spent about two years being extremely good at the part that does not matter.
The three weeks I would like back
At one company I built a design system before we needed one. Twelve components, every variant, every state, naming convention documented, a page explaining the naming convention.
Three weeks. It was the best-looking file I had ever made.
Nobody used it. Not out of hostility, the team was four people, they were shipping fast, and the system solved a problem we did not have yet. A design system exists to stop the same decision being made twice, differently. We had not made most of those decisions once.
What we actually needed that month was for someone to sit with the sign-up flow, which was losing about half the people who started it. I did not do that, because the design system was the kind of work that looks like seniority.
That is the whole essay, really. The rest is what I took from it.
Design is not a performance
Design has drifted into performance. Processes, workshops, tokens, ideation sessions, double diamonds, feedback loops, and meanwhile nobody is solving anything. It becomes theoretical, perfect on the surface, and disconnected from the product.
You do not need to bring out the double diamond every time somebody speaks. You do not need four weeks of research to move a button. You do not need to justify every decision as if it were going to be peer reviewed.
You need to think clearly, talk to your team, understand the context, and design something that works. Nothing more, and nothing less.
The useful version of “how much process” is not a rule, it is a question: how expensive is it to be wrong? Moving a button is a reversible decision — decide it this afternoon and change it tomorrow if it is wrong. Choosing who the product is for is not, that one earns the fortnight. Most process arguments are really arguments about a cost nobody has bothered to estimate.
Stop designing for the file
The cult around Figma is the same mistake in a different costume. Spotless file, perfect auto-layout, endless variants, carefully named components, and then the person on the screen has no idea what to do.
Everything can be immaculate inside the file and still be wrong about the product, because the file is not the product. It is a drawing of an argument. If the argument is bad, the drawing being beautiful only means it takes longer for anybody to notice.
We are not designing to get likes from other designers. We design so somebody understands what they can do, how to do it, and why it is worth it. That does not come from making it pretty. It comes from making a decision and being able to say why that one and not another.
What I actually look at now
Three questions, in order:
Can they tell what to do? Not “is it discoverable”, can a real person, at speed, with something else on their mind, tell what to do. This is unglamorous and it is where most of the value is.
Why this and not the other one? If I cannot answer that in a sentence, I have not designed anything, I have arranged things. Anybody can produce a screen. The scarce skill is saying why that one.
What does it cost the team? A design that is right and takes six weeks can be worse than one that is 80% right and takes six days, depending on what else is on fire. Designers are bad at pricing their own work in team time, and I include myself.
The honest caveat
Everything above comes from small teams, two to forty people, mostly startups, mostly with less time than the plan needed. In a large organisation with twelve squads touching the same surface, the design system I mocked is not overhead, it is the only thing preventing chaos, and the person who built it was right.
So I am not saying process is bad. I am saying it is a cost, it should be paid deliberately, and the most common way to get this wrong is to buy the process of a company forty times your size because that is the process you read about.
Design is not about you. It is about the team, the product, and the person on the other side of the screen. If you can do that without overcomplicating it, better.
Questions people ask about this
Is Figma necessary to be a product designer?
You need a way to show people what you mean, and Figma is the current best one. What is not necessary is the craft around the file, the naming conventions, the variant matrices, the immaculate auto-layout. Those help a team when the team is large enough to need them, and cost you time when it is not.
What actually makes product design good?
Whether the decision inside it was right, and whether the person using it can tell what to do. A screen that is beautiful and wrong is worse than a plain one that is right, because the beauty buys it time before anybody questions it.
How much research does a design decision need?
As much as the cost of being wrong. Moving a button is reversible in an afternoon, so decide it in an afternoon. Choosing what the product is for is not, so spend the fortnight. Most process arguments are really arguments about a cost nobody has estimated.
Do design systems slow teams down?
They do when they arrive before the repetition does. A system solves the problem of the same decision being made twice differently. If that has not happened yet, you are maintaining an answer to a question nobody asked — I have built exactly that, and it took three weeks.