Building a design system for AI-assisted building

From component implementation to review

Previously, two engineers built and reworked components. By the period described here, one engineer mainly reviewed and approved pull requests.¹

I built a shared component language for designers, engineers and AI tools. I audited the UI, defined components and states, agreed contribution rules and brought the system into our AI-assisted workflow.

From a component library to an AI-assisted workflow

I joined Mobal when its Vue.js component library supported a small, services-led listing product. As we expanded into an online marketing platform, we needed components that designers, engineers and AI tools could reuse across features.

I led the design-system work: auditing the UI, defining components and states, agreeing on contribution rules, and bringing the system into our AI-assisted workflow.

The cost of rebuilding the same UI

The original library helped us ship early versions. As we explored new features and brand directions, we introduced components with different styling, behaviour and logic. Developers duplicated or overrode existing UI code, then spent time fixing the inconsistencies.

After a team restructure, we had fewer people and still needed to test new product ideas in competitive Nordic markets. Rebuilding components for each feature was using time we needed for that work.

Audit the behaviour as well as the visuals

I began with John, a developer with an interest in design systems. We catalogued components, found duplicates and one-off implementations, and compared how similar controls behaved across the product.

During the 2023 platform redesign, I expanded the audit with the Head of Product, Tech Lead and developers. We mapped components, usage patterns and deviations in FigJam. Over four weeks, we agreed on priorities, translated shared patterns into coded components and resolved differences between design and implementation.

Define a smaller set of components

I removed redundant and overly specific components and defined the remaining set around variables, states and explicit behaviours. We could extend those components as requirements changed, rather than create another one-off version.

The same structure gave AI tools named tokens and documented patterns to work with. That became useful as we brought Claude and Devin into component development.

Make the system part of delivery

Throughout 2024 and 2025, I worked with engineering to refine components and document them in Storybook. Before implementation, we discussed each new component’s purpose, states and interactions.

Teams could reuse UI logic in new features, and we had a shared reference for checking whether the implementation matched the design. We continued maintaining the system as the product grew.

I brought AI tools into specific parts of this workflow:

• With Figma MCP Server, I checked structure, variables and states before handoff.
• With Devin, I mapped design variables to code logic and reduced configuration back-and-forth.
• With Cursor, I iterated on component code, debugged issues and refactored implementations.

Designers could prepare more of the component implementation before engineering review. Previously, two engineers built and reworked components. By the period described here, one engineer mainly reviewed and approved pull requests.

The following Figma views show the system’s foundations and reusable layouts.

Colour system

Typography

Layout grid

Reusable feature layouts

Component inventory

Working with AI-generated components

We implement and document components in Storybook. Claude and Devin can use those definitions to generate components that we validate and publish through the same workflow.

The system reduced repeated component setup and engineering rework. It also made it easier to test new features using existing patterns. We are extending Devin’s role in system maintenance and exploring prompt-driven interface creation in Claude using our tokens and components.

Close