Had a 55-minute conversation with Simon Eriksson from ICA’s Design Experience Team.
They have everything you would expect from a serious, mature design organisation. Figma libraries. Storybook. Tailwind. GitHub-connected design pipelines. A real team, real systems, real production work.
And they were asking the same three questions I hear from solo operators and three-person startups:
- When do you wireframe, and when do you go straight to code?
- Who owns the design system once the product evolves?
- How do you bring a new designer in without stopping the work?
These aren’t small-team problems.
They’re process problems. A bigger organisation doesn’t solve them — it amplifies them. More designers asking the same unanswered question, in more places, at the same time. More handovers happening without a shared definition of what was handed over. More tools doing more things, but the same fuzzy spot between “we’ve talked about it” and “this is ready to build.”
The tools are almost always good enough
This is the realisation I keep coming back to in these conversations: the tools are not the bottleneck. Figma is not the bottleneck. The component library is not the bottleneck. The design system is not the bottleneck.
The gap is one step earlier. Before the first frame.
What is the problem we are actually solving. Who is it for. What has to be true for it to work. What changes when this lands.
When that part is clear, the tool you pick is almost incidental. When it isn’t clear, no tool, no library, no AI agent will save you. You will spend the same week in Figma, the same month in Storybook, and the same quarter in retros wondering why the work feels heavier than it should.
What changes when you name the phases
What we walked through together was the WDS approach. A clear Product Brief before anything is designed. Trigger mapping before drawing screens. Letting the process carry the intent — not just the deliverable.
The reason this matters at scale, not just for solo designers, is that locked terminology changes the conversation. “Are we still in briefs or have we moved to design?” becomes a real question. Not an abstract one. People can answer it. They can disagree about it. They can decide to go back one step instead of pretending the step happened.
That single shift — being able to name where in the process you actually are — is the thing that scales. It works for one designer. It works for one hundred. It works whether your agents are humans, AI, or both.
A note on AI
When I bring this up, people sometimes assume the AI part is the interesting part. It isn’t.
The interesting part is that AI agents need exactly the same clarity that a new designer needs on day one. A Product Brief is not an AI artifact — it’s a human one that happens to also unlock AI. A Trigger Map is not a prompt template — it’s a way of thinking that an agent can follow precisely because a person already could.
The teams that will make AI useful are the teams that already have process discipline. The teams that won’t are the teams hoping AI will paper over the gaps. It won’t. It will just generate the same confusion faster.
If that gap sounds familiar
If you’re sitting in a team where the tools are sharper than the process — where you have the libraries, the systems, the components, and still the question “are we ready to design this yet” doesn’t have a clean answer — I’d love to compare notes.
The questions don’t change with the size of the org. The cost of leaving them unanswered does.
