Industry

Design Systems

Client

Skynamo

A mobile and web Flutter design system built to scale.

Main Project Image

The platforms were already diverging. The Flutter migration was the chance to stop that.

Skynamo runs on iOS, Android, and a web management system, and for a long time each lived in its own codebase doing its own thing. Every new feature meant designing and building the same thing three times over, and the gaps kept widening. The Flutter migration was the moment to sort that out. The system lives in two places: a Figma file designers work from, and a Widgetbook instance where developers interact with real production components instead of static specs. If it's in Widgetbook, it's in code. 23 components, a colour system rebuilt to work with the framework rather than against it, and custom additions for the patterns Material has no opinion on. Flutter's theming handles contrast and touch targets at a system level, so accessibility is there by default. 14 developers across multiple squads use it now. The first product built on it was a catalogue ordering app, where we replaced the cart screen with the first complete page view made entirely from system components. A bulk actions checkbox took two days to build once and has cost nothing to reuse since. The decisions that mattered weren't the obvious ones. Material covered the basics; the harder calls were about what didn't belong at all. The rule we settled on: if something appears in more than one place it belongs in the system, if it's one-off it doesn't, and holding that line stopped it becoming a dumping ground. Nothing went in without both a Figma source and a working Widgetbook story, which kept the single source of truth actually single as the team grew.

Large Project Gallery Image #1
Project Gallery Image for 50% width of the screen #1
Project Gallery Image for 50% width of the screen #1
Project Gallery Image for 50% width of the screen #2
Project Gallery Image for 50% width of the screen #2
Project Gallery Image for 50% width of the screen #1
Project Gallery Image for 50% width of the screen #2
Project Gallery Image for 50% width of the screen #2
Project Gallery Image for 50% width of the screen #2

Testing where it's going

I also wanted to know how the system held up against AI tooling, so I connected the Figma file to Claude via the Figma MCP and asked it to generate code from a production screen. Token names, documentation and variant structure came through cleanly, but the output fell apart: it defaulted to React/Tailwind, and icons came through as image URLs. My first read was that this was a tooling problem, not a documentation one. Then I tested it. I wrote an AI-readable spec for the Quantity Selector, resolving tokens, exact sizing, and the behavioural rules that live in design intent, then ran the same prompt with and without it. Without the spec, Claude got 2 of 9 decisions right. With it, 9 of 9. The tooling gap is real, but documentation closes more of it than I expected. What's still unsolved is how that spec reaches Claude without manual wiring, the pipeline problem we're now working on with Widgetbook exports. It changed how I think about what AI-ready means: not whether the model can read your tokens, but whether your documentation carries the intent behind them. And the real test wasn't technical. While I was away, another designer picked up the catalogue app and shipped without needing to touch the system, which is what you're building toward. A design system is only as useful as the trust people have in it: developers need to know it won't shift under them, designers need to know it reflects how the product actually works. Getting both right is mostly a people problem, not a design one.