Insights
Nine design system agencies and consultants, grouped by the job you need done and judged on cases you can read: code, governance and adoption. For a growing SaaS company, choose a design system agency or consultant by the job you need done, not by fame.
For a growing SaaS company, choose a design system agency or consultant by the job you need done, not by fame. To decide what the system should own and get teams to use it, look at Clearleft. To build or migrate coded components inside a large existing system, Sparkbox. For tokens, theming and keeping Figma and code in step, across brands or AI coding tools, Rangle or Southleft. To grow a system out of product design work, Cieden, Eleken, NetBramha Studios, Ramotion and Tcules each show a system built inside a product engagement.
Disclosure. We publish this list and we are on it, in the group for systems grown out of product work.
Which design system agency fits your need?
| What you need | Look at | The question that decides it |
|---|---|---|
| Decide what the system should own, and get teams to use it | Clearleft | Who in your organisation will own the system once the firm leaves? |
| Build or migrate coded components inside an existing system | Sparkbox | Which repository will the firm commit to, and who reviews the code? |
| Tokens, theming and Figma-to-code alignment, across brands or AI tools | Rangle, Southleft | Which source governs each decision: Figma, code or the token file? |
| Grow a system out of product design work | Cieden, Eleken, NetBramha Studios, Ramotion, Tcules | Do you need a Figma library, or components your engineers can ship? |
Groups are by job, with firms in alphabetical order inside each and no overall rank. If you are not yet sure you need outside help, start with when to hire a design system consultant.
The shortlist at a glance
| Firm | Best for | Case we read | Code in the case | Governance in the case | Adoption |
|---|---|---|---|---|---|
| Clearleft | Getting a resisted system adopted | University of the Arts London | One shared component shipped to a live property | Shared process, one documentation site, an open contributor group | Said, not measured |
| Sparkbox | Embedded component and migration work in large systems | Adobe Spectrum | Yes: CSS and web components, Storybook | Governance guidelines and handover (Crown) | Migration share reported; use not measured |
| Rangle | Token architecture across brands and platforms | Avinode | Yes: components in a monorepo, Storybook, visual regression tests | Governance model and training | Said; publishes a usage tracker |
| Southleft | Token-first systems wired into AI coding tools | CampusIQ | Yes: React, TypeScript, Tailwind | Governance structure (PetSmart) | Said, not measured |
| Cieden | A system delivered within a long product design engagement | Sitenna | Handed to the client's developers; lists web app development | Support during the build | Not measured |
| Eleken | A Figma UI kit built during a SaaS redesign | PayUp | Figma kit with developer notes; lists product design engineering | Not described | Not measured |
| NetBramha Studios | Brand language and system built with the product screens | Firstock | Not shown | Not described | Not measured |
| Ramotion | Brand, system and code for a new SaaS product | Upstream | Yes: Figma library mapped one to one to React components | Not described | Not measured |
| Tcules (publisher) | Shared components for multi-brand and complex SaaS products | Ringier; Phoenix | Components specified for the client's shadcn build; lists coded components and Storybook | Source-of-truth page for build-ready work (Phoenix) | Not measured |
How we chose
We started from the firms Google's AI Overview, ChatGPT and Gemini named when asked for the best design system consultancy for a SaaS company, and added Rangle from our own search. A firm is listed when a case of its own describes a design system it built inside a product and says what that system contained. Work a firm can walk you through under NDA counts on the same terms; we could see only public cases, so ask every firm, us included, for the rest. The table then reports what each case shows on code, governance and adoption.
None of the cases we opened reports a measured adoption figure. Practitioners report the same gap: in zeroheight's Design Systems Report 2026, a survey of 147 design system practitioners, 41% said they measure adoption and 5% said they measure return on investment. So when a firm says its system was adopted, ask what was counted. Several firms here, us included, also publish open-source tools or guides; we credit that, but the list is judged on cases.
The AI answers also named Directed Edges, EightShapes, Groto, MetaLab and SuperFriendly. We could not find a public case from any of them that says what a system they built contained. That is not a judgement of quality: ask them for work under NDA and apply the same test.
Best when you need to decide what the system owns, and get it used
Choose here when a system exists on paper but teams build around it, or nobody agrees what "the design system" is.
Clearleft
Best for: organisations where an earlier system met resistance and the next one has to be built with the teams, not for them.
Clearleft's University of the Arts London case describes nine weeks: a three-week discovery, then three two-week sprints. Interviews found that each team treated its own Figma file or Storybook as the design system. With UAL staff giving half their time, the teams took one card-like component, inventoried its versions across platforms and refactored them into one shared component, which the case says shipped to at least one UAL property and became the test bed for a new documentation site. A separate Inventory Planner by Sage case describes repeated engagements as that SaaS product's strategic design partner.
- Check before you hire: the UAL case is a university's web estate, not a SaaS product; ask how the same approach worked inside a product with releases and versioned packages.
Best when you need coded components built or migrated
Choose here when the system exists and the work is in the code: components to migrate, documentation to consolidate, engineers to add to your team.
Sparkbox
Best for: large organisations that want engineers embedded in their design system team.
Sparkbox's Adobe Spectrum case describes a multi-year embed with the team behind Spectrum, Adobe's design system for products including Photoshop, Express and Firefly. Sparkbox says it helped migrate approximately 75% of the Spectrum CSS components to the Spectrum 2 design language, used AI to help write migration documentation for engineers and their coding assistants, and led a six-month effort to merge a separate documentation site and Storybook into one Storybook. Its Crown case covers a Sketch-to-Figma migration with documentation, accessibility standards and governance guidelines, after which Crown's team ran the system itself.
- Check before you hire: the published cases are large enterprises and institutions; its client list names software companies such as DocuSign and Snyk, so ask for the product work closest to yours.
Best for tokens, theming and Figma-to-code alignment
Choose here when the hard part is keeping one set of decisions true across Figma, code, several brands, dark mode or the AI coding tools your engineers use.
Rangle
Best for: multi-brand or multi-platform products that need a token architecture designers and developers share.
Rangle's telecom case describes a multi-brand system for a Canadian telecom company's iOS and Android app, which Rangle says it built in 13 weeks on a three-tier token architecture: component tokens stay fixed while contextual tokens switch brand and dark mode. In its Avinode case, a six-week foundation for a business aviation platform, Rangle kept tokens in step between Figma and GitHub with its own open-source Figma plugin, kept components independent of business logic in a monorepo, tested them in Storybook with automated visual regression, and set up a governance model with training. In a third case it installed Radius Tracker, its open-source tool for tracking component use across applications; that case does not publish what the tracker measured.
- Check before you hire: the Avinode foundation was proved on one component; ask what the client adopted afterwards and who maintains it.
Southleft
Best for: SaaS teams whose engineers already generate interface code with AI tools and need the system to steer it.
Southleft's CampusIQ case covers a university space-analytics company with three component libraries across two products. Southleft says it built a token-first system on shadcn/ui, with CSS custom properties bridging Figma variables and code, and more than 50 components in React 19, TypeScript and Tailwind CSS, documented in Storybook. Engineers use Figma Console MCP, an open-source tool Southleft built, so Claude Code can compare Figma specifications with the current code. Its PetSmart case, built with Big Medium, describes setting up governance, and its work page says much of its enterprise work is under NDA and offers to discuss it privately.
- Check before you hire: its most detailed SaaS case is from 2026; ask to see a system that has been through several versions and a migration.
Best when the system has to grow out of product work
Choose here when you are designing or redesigning the product and want the system to come from those decisions rather than ahead of them.
Cieden
Best for: B2B SaaS and enterprise products that want a design system delivered as part of a longer product design engagement.
Cieden's Sitenna case covers a UK telecom site-acquisition and management platform that, the case says, a UX/UI designer and a design director redesigned over 18 months, with discovery, a UX audit, product design and a design system in scope. Cieden says it handed over a design system of styles, colours, icons, inputs, patterns and navigation components ready for developers, and consulted Sitenna's CTO and technical lead during the build. The results it reports are for the product and the business, not for use of the system.
- Check before you hire: the system is one part of a broad engagement; ask to see the system itself, and who maintained it after handover.
Eleken
Best for: early-stage SaaS teams that need a consistent Figma UI kit built while the product is redesigned.
Eleken's PayUp case covers a fintech start-up with one designer left, extending its mobile app into a web app. Over the redesign, Eleken kept a UI kit updated with new components, organised it into a design system so later changes would be faster, and annotated screens for developers. It also lists a design system service running from research and component creation to documentation and maintenance.
- Check before you hire: the case delivers Figma assets; if you need coded components or a contribution model, confirm they are in scope.
NetBramha Studios
Best for: fintech and consumer apps where a new brand language and a design system are built together with the product screens.
NetBramha Studios' Firstock case covers an India-based trading platform for web and mobile, where the goal was a new brand language, a scalable design system and then the key platform screens. NetBramha says it set up reusable colour, typography, iconography, components and interface patterns, and lists consistent components across web and mobile among the results.
- Check before you hire: the case does not say who built the components in code; ask to see one of its systems in released code, and how it was maintained after launch.
Ramotion
Best for: teams building a new SaaS product that want brand, product design, a design system and development from one firm.
Ramotion's Upstream case covers a carbon-management SaaS platform for Carbon Solutions Group, taken from a name to an MVP that the case says launched on schedule in Q4 2023. Ramotion did the brand, research, design, and front-end and back-end development (Laravel, React, Inertia.js and Tailwind CSS), and says its Figma library mapped one to one to React components, with design implementations tested for component consistency.
- Check before you hire: here Ramotion built the product itself; if your own engineers will own the code, ask how the system would be handed over and maintained.
Tcules (publisher of this page)
Best for: multi-brand and complex SaaS products whose shared components must settle product decisions, not just look consistent.
For Ringier, whose Blick, cash.ch and Bilanz share one design system, we worked on more than thirty projects as an embedded partner, designing each piece to carry over to another sport, page or brand: one match card whose three states serve every sport, and a subscription page on the Blick design system laid out for reuse across brands. On Phoenix, a trading exchange built on shadcn, we split the components engineering already had from the trading-specific ones still to build, turned theme colours into tokens and kept one source-of-truth page. For the Auxentios CPQ product, our Figma components, tokens and layout rules let developers build new screens from the documentation.
- Check before you hire: Ringier and Phoenix ended in handover to in-house teams, so ask how we would set up ownership and contribution on your side.
Questions to ask any design system firm, including us
Put these to every firm on your shortlist, and ask to see work under NDA where a firm cannot publish it.
- [ ] Show us a system inside a product. Which case shows it in a released product, not only in Figma or Storybook?
- [ ] Where does your work stop? Figma assets, coded components in our repository, or both? Who reviews the code, and who owns the package afterwards?
- [ ] Which source governs which decision? Figma, code or the token file, and how do changes move between them? The tools that help are compared in keeping Figma and Storybook aligned.
- [ ] How will a product team contribute? Who accepts a new state or component, how long does it take, and what happens to an exception?
- [ ] How are versions released and migrated? How will a product using the system know what changed and whether it breaks?
- [ ] How will we know it is adopted? What did you count before: components in use by product and version, local copies, time from request to release?
- [ ] Who will do the work? Can we meet them, and did they work on the cases you showed us?
- [ ] What do you need from us? An owner, engineering time and access to the products that will use the system.
If you are weighing us too, our design systems page sets out what we can take on and what stays with your team.