61.2970°N 23.5025°E
Tel. +358 50 433 7843
Email sami@bumblebee.fi
/////////////
© Sami Surakka 2026
Writing/Design systems used to take months
10 Sept 2026
Loading...
61.2970°N 23.5025°E
© Sami Surakka 2026
I used to treat a design system as a programme. The ranges I heard, and sometimes lived, were three to twenty-four months of FTE work: foundations, components, documentation, governance, adoption. That investment was real. It was also a reason teams postponed the work until they could “do it properly”.
My own times have collapsed, and not only because of AI.
Before AI tools were part of how I built, the fastest I had stood up a serious system was at Tietoevry, with the lead developer. Figma library plus Storybook, in weeks to a month or two, adopted by two teams. At Cambri I built a coded component library as a side effect of shipping a survey editor, in a few weeks, documented in Storybook. Engineers now extend it without me. At Kaiku, standing up Storybook took an hour. That last number needs the caveat immediately: an hour gets you scaffolding.
The interesting part is which work collapsed and which did not.
Scaffolding got faster. A Storybook repo, a token file, a first set of buttons and inputs, a dark theme switch. That used to be weeks of ceremony. AI makes the first pass cheap enough that I can do it in a sitting.
At Cambri I treated the visual direction as useless unless it existed as something engineers could build with. A specification of the components would have been another handoff. The deliverable had to be the components. I built the library in code. Storybook became the place we reviewed rendered behaviour instead of static screens. That move still matters. It is just less expensive to start.
The survey programming case study covers the product around that library. I am leaving the editor there. This piece is about the time.
At Tietoevry the reason I invested past a Figma kit was a survey: 69% of developers were already using the library daily or weekly. I also learned they struggled to navigate Figma and extract what they needed. That is a common pattern in my work. So Storybook became the developer-facing interface, implemented by the lead developer. I proposed a federated model where each team published implemented components back into the shared library, so the system would not depend on one designer as a bottleneck.
Later, an org-level decision reversed the original visual-identity brief. Because the system had theming from the start, mapping tokens and fitting the MUI library took days rather than a structural rewrite. Petri kept building on it after I left, which is the test I care about: the system was usable without me.
None of that is an hour of Storybook. Adoption, findability, governance, tokens that survive a brand reversal, a system that outlasts the person who started it: those were the expensive parts then, and they are still the expensive parts. More on the clinical product sits in the Tietoevry case study.
Cambri taught a related lesson from the other direction. The library accumulated while we shipped a feature. New work is built against it. Generating more of it did not mean the team could absorb it faster. I bundled very large pull requests, which were hard to review, hard to reason about, and hard to roll back. Speed I gained in authoring, I spent again in someone else’s review budget.
If I put the times in a line:
Calling the last one a design system in an hour would be selling the scaffolding. What dropped is the cost of starting. The remaining questions are the ones that were always the system: who publishes back, where developers look, whether tokens are real, whether the next person can keep it.
I am keeping Kaiku at that one-hour claim. The rest of that work is early, and it is not a case study.
A design system used to be easy to postpone because starting it looked like a year. Starting it no longer looks like that. The slow work is the same slow work it always was.