Insights
When outside design system help is worth it, when it isn't, what a good consultant or agency should deliver, and how to judge the work. Hire a design system consultant when your team needs a decision it cannot make from the inside: what the system should own, why teams keep working around it, or how it should be run.
Hire a design system consultant when your team needs a decision it cannot make from the inside: what the system should own, why teams keep working around it, or how it should be run. Do not hire one to replace an owner. A good consultant leaves decisions, a working contribution path and adoption evidence your team can keep running.
Last reviewed September 29, 2026.
The same test applies whether you call the help a consultant, a design system agency or a studio. What differs is how much building they do. What should not differ is what stays behind when they leave.
When should you hire a design system consultant?
Short staffing is the challenge design system practitioners report most often. In zeroheight's Design Systems Report 2026, a survey of 147 design system practitioners, three in five teams said they were understaffed, and 56% of respondents selected lack of resourcing or staffing as a challenge. Capacity is a legitimate reason to bring someone in. It is a better reason when it comes with a specific problem the extra people will solve and an owner who will keep the result.
These are situations where outside help can pay for itself, and the kind of help each one calls for.
| What you are seeing | What kind of help it calls for | What to ask for first |
|---|---|---|
| Design, product and engineering all want a system, but for different reasons: speed, consistency, accessibility, brand | A scope decision | A record of what should be shared, what varies, what stays local and what is excluded, with an owner proposal |
| A library exists, but teams fork components or build around it | Diagnosis before any rebuild | A trace of one repeated component family through Figma, code and a live screen |
| Figma and code describe different systems, and tokens are synced by hand | Alignment across design and code | A map of which source governs which decision, and a token pipeline. zeroheight found only 40% of teams have any token pipeline |
| A named owner, not enough people | Bounded build or repair capacity | A defined slice of work the owner accepts and can maintain afterward |
| Several products or brands need to share foundations | An architecture decision | A choice between foundations only, a shared core, or a parent and child setup, with the trade-offs stated |
| AI coding tools now produce interface faster than anyone reviews it | Making the rules explicit and machine-readable | Semantic tokens, component intent, state definitions, code mappings and tests an agent can check its work against |
The common thread: each row names a decision or a bounded piece of work. "We need a design system" is not yet a brief.
When a consultant is the wrong answer
Outside help does not fix a missing owner. Nathan Curtis made the point in 2016 in A Design System Isn't a Project. It's a Product, Serving Products: a system's value arrives only when product teams ship features with it, and it rarely survives long without a sponsor funding it on purpose. In 2024 he went further in The Fallacy of Federated Design Systems, reversing his earlier preference for federated teams and observing that "virtually all productive output is delivered by central people."
A consultant is, for a while, those central people. When the engagement ends, someone inside has to be. If nobody will be, you are paying for a library that starts drifting the week the invoice closes. That is our reading of Curtis's argument applied to outside help, not a claim he makes about consultants.
A consultant is also the wrong answer when:
- One feature keeps drifting between design and production. That points first to implementation acceptance, not to the system. Implementation QA or a design-to-code audit fits better.
- You need screens designed. Product design capacity and design system work are different jobs. A system consultant who designs your roadmap features is doing the first job at the second job's rate of change.
- The honest answer is a smaller system. The responsible outcome may be foundations only, one shared pattern, or no new system at all. A good consultant will say so. One who assumes a full multi-platform system before looking is selling the build.
What should a good design system consultant deliver?
Judge the work by the decisions it settles and whether your team can run it afterward. A larger component count is not evidence of either. Use this as a checklist when you scope the engagement and again when it ends.
| Deliverable | Why it matters | How to check it |
|---|---|---|
| A scope decision: shared, variable, local and excluded, with triggers to reopen it | Overreach makes the system a bottleneck; underreach leaves teams rebuilding the same behavior | Every exclusion has a reason and a condition for reconsidering it |
| A system map | Shows where decisions live (Figma, code, documentation), who owns them and which products consume them | You can name the owner and release path for any shared component |
| An ownership and contribution path | A product team that needs a new state this week will fork if the system cannot answer in time | Each request type has a decision owner, required evidence and an expected response |
| Figma and code correspondence | Two sources of truth guarantee drift | A stated rule for which source governs tokens, components and states, and token sync that does not depend on someone remembering |
| Components with states, accessibility and usage rules, proven in a real product | A component that has only lived in the library has not met real data, permissions or edge cases | At least one consuming product uses the output, not only the documentation site |
| A migration and adoption sequence | Adoption happens in consuming products, one change at a time | An ordered list your team can work through, with blockers named |
| Adoption measures beyond component count | zeroheight found only 41% of teams measure adoption and 5% measure ROI | Versions in use, local forks and why they exist, time from request to release |
| Agent-readable context | Coding agents now read the system directly (more below) | Semantic tokens, component intent, code mappings and runnable interaction and accessibility tests |
| A handover your team can run | The engagement ends; the system should not | Your team can make the next release without the consultant in the room |
The vocabulary behind several of these rows, including ownership models and contribution routes, is in our definitions of design system governance and design system drift.
Consultant, agency or agent: which kind of help?
Search is starting to blur these words. On September 29, 2026, Google autocomplete for "design system agen" suggested "design system agent" ahead of "design system agency." They are different kinds of help, and a growing SaaS company may use all three.
An independent consultant or specialist is strongest on strategy, architecture, governance and team practice. Brad Frost's consulting, for example, covers buy-in, architecture, documentation, team structure, workflow and governance alongside front-end practice. Build capacity can be limited, so expect your team to do most of the implementation.
An agency or studio adds design and frontend capacity to build or repair the system across Figma and code. The risk is the one above: the people who understood the system leave with the contract. Ask how handover works before you ask about the portfolio. Be careful with "best design system agency" lists, too. Several are written by agencies that rank themselves: Superside's list puts Superside first, and 925Studios' list includes 925Studios. Judge any provider, us included, on inspectable work and the deliverables above.
AI agents consume a design system; they do not decide what it should own. Figma's MCP server passes variables, components and layout data to coding agents, and its Code Connect mappings help agents reuse your real components. Figma's own argument for design systems in AI workflows compares an agent without design system context to a new engineer shipping before onboarding. Storybook's MCP server, still labeled a preview, lets agents read component documentation, write stories and run interaction and accessibility tests on what they generate.
What these tools do is raise the value of explicit rules. An agent can apply a semantic token it can read. It cannot decide whether a new status belongs in the shared system or should stay local to one product, or who approves the exception. Those are still decisions for people, and they are the part of the work a consultant should leave written down. zeroheight's 2026 survey also found only 10% of teams had AI built into their design system processes, with 46% experimenting, so most teams are early here.
How to judge the work before and after you sign
The answers to these questions separate a partner who will leave you with a working system from one who will leave you with a library.
| Question to ask | A good answer sounds like | A warning sign |
|---|---|---|
| What will you look at first? | A real product path: a component family traced from Figma to code to a live screen | A Figma inventory or a maturity score on its own |
| What might you recommend we not build? | Scope options, including foundations only, with reasons | A full multi-platform system assumed before any evidence |
| Who owns this after you leave? | A request to meet the owner early and design around their capacity | Ongoing maintenance by the provider as the only plan |
| How will we know it is adopted? | Versions in consuming products, forks and their causes, time to decision | Component count, library opens or documentation visits |
| What will agents get from this? | Semantic tokens, component intent, code mappings, tests | "AI-ready" with nothing specific behind it |
| What does handover include? | A decision queue and migration sequence your team can run alone | A documentation site and a final presentation |
What drives the cost. We don't publish prices here, but the drivers are predictable: how many products and platforms are in scope, whether coded components are in scope or only Figma, how many consuming products need migrating, how much accessibility repair is needed, and whether governance has to be designed or only documented. A diagnosis of one component family is a much smaller commitment than a multi-platform build, and it can tell you whether the larger one is needed.
Where Tcules fits
Tcules is a digital product design studio that works on design systems across Figma and code for SaaS and complex products: strategy, implementation, Figma and Storybook alignment, and governance and adoption.
If a system already exists and teams keep working around it, an audit is a smaller first step than a build. Ours traces shared decisions into real product use and leaves a system map, findings tied to product consequences, a decision queue and an adoption sequence. The decision queue and migration sequence are written for your system team to run without us.
Matter is Tcules' public Figma design-system reference, so you can inspect how we structure tokens and components before you talk to us. It is published and not actively maintained, so treat it as a design reference, not evidence of adoption.
