Simvia: a design system that answers for itself

Simvia had been built screen by screen, so every team solved the same problem differently and every answer lived in a designer's head. I turned it into one structural design system, then gave that system a voice: an AI assistant that tells anyone on the team what pattern to use, and flags what's missing.

Simvia had grown one screen at a time. The same job looked and behaved differently from page to page, and nobody outside design had a reference to build from.

• One offs everywhere. Tables, buttons and chips were restyled locally, so no two pages felt quite the same.
• Cluttered navigation. Pages stacked two rows of tabs, and actions sat wherever there was space.
• Hard to scan data. Empty values, flags and dates were shown in different ways, so users had to hunt for the information that mattered.
• Design was a bottleneck. Engineers and product managers had to ask a designer, or guess, every time they built something new.

Why it mattered now: a rebrand was coming and the team hadn't chosen a component library. Styling an inconsistent structure would only have multiplied the problem. The structure had to be fixed first, in a way that would work whichever library we chose.

1. Fix the structure before the styling

I worked in four phases:

• Scope the system
• Rebuild the core components
• Agree the key decisions with the team
• Document and scale it

Eight principles gave everyone a way to make decisions, even when no rule existed yet. The two that mattered most were structure before styling, so we could move forward without a library decision, and don't bend the system for one outlier, so a single request couldn't reshape a whole pattern.

Decisions that changed the product

2. Build it once, reuse it everywhere

I organised the system using Atomic Design, so each rule lives in one place and everything built on top of it inherits it. Fix the button once and every page that uses it is fixed.

Page templates sit at the top. Pages that share a layout share one template, so engineers build it once. A single Overview template, for example, powers four different areas of the product.

3. Prove it on real screens

I wireframed the core templates in shadcn with the Simvia brand applied, and annotated each one with the rules it follows. Every screen doubles as a spec engineers can build from.

Overview. Views, filters, search and the main action share one row, and the table uses the same reusable cells as every other table in the product.

Details page. One level of navigation, with page actions that stay in the same place wherever you are.

Document preview. A focused three column layout that puts the document first, with a reusable side panel for reviewing and approving it.

4. Make the system answer for itself

A guide only works if people use it. So I built an AI design system assistant that reads the live guide and answers one question for anyone on the team: "Do we have a pattern for this?"

If the pattern exists, the assistant shares it with the rules and links. If it doesn't, it says so plainly and captures the request with enough context for design to pick it up. Once a new pattern is added, the assistant uses it in its next answer. Crucially, it never invents patterns of its own, so the system stays consistent.

I also used rapid prototypes built with AI tooling and GitHub to test the templates in real code and show stakeholders the end result before the styling decision was made.

In the ten days after the team's design system week, Simvia went from tribal knowledge to a documented, self serve design system.

• Self serve answers. Designers, engineers and product managers can check what to use without waiting for a designer.
• Less duplication. Shared templates and one table pattern replace many one off versions.
• A more consistent product. Overviews, details pages and settings now follow the same structure and action rules.
• Ready for the rebrand. Because structure and styling are separate, the new brand can be applied once, at the component level, and flow through every page.
• Design moved from bottleneck to enabler. Requests now arrive with context, so design time goes into solving new problems instead of answering repeat questions.

• Structure travels, styling doesn't. Agreeing the skeleton first meant our decisions held up regardless of the library we chose.
• Only write down what's decided. Being clear about what was agreed and what was still open built trust in the system.
• A design system is a service, not a file. Giving it a voice did more for adoption than any amount of visual polish.

• Review the system with engineering and roll it into everyday delivery
• Complete the remaining page templates
• Apply the new brand through the system once the component library is chosen
• Explore documenting Simvia's core objects, such as an organisation, with the same care as its components, so both people and AI can design better experiences around them