Building an AI-Native Design System for Forward-Deployed Teams

Forward-deployed teams have to turn customer-specific requirements into working product experiences quickly. Each client introduces differences, but rebuilding the interface around those differences makes delivery harder to scale or sustain.

At Obin, a team rethinking a new AI native review workflow for a large enterprise client needs to focus on what the customer needs are, what evidence they need, and which actions need to happen. 

If, instead, they spend time defining page layouts, button behavior, and loading states for every workflow they are not going to be able to move at the velocity needed in these forward deployed environments. The difficulty is deciding which parts of the experience are shared and which parts are customer-specific.

That is the problem we’re designing our system around at Obin.

Faster prototypes still need a path into the product

AI-assisted tools make it easier to put an idea in front of a customer. The team can explore a workflow, get feedback, and change direction before investing in the full implementation.

To ensure we’ve set our teams up with the right starting point, we aligned on an approach very similar to Vercel. Use shared tokens, composable components, and registries to bring a product’s design system into AI-assisted prototyping. This gives teams approved building blocks to work with.

For a forward-deployed team, the prototype is one step in delivery. The work still needs to fit the application, accommodate the customer’s requirements, and remain maintainable as the product changes.

If a prototype introduces its own styling, components, and interaction conventions, the team inherits another implementation to reconcile. Our design-system work is about reducing that reconciliation.

The practice that makes this workable is a clear order of reach. When a team builds, whether by hand or through an AI-assisted tool, they reach for the highest layer available. First, the design system's own components: built, tested, and documented, with the platform's decisions baked in. Where a component does not exist yet, the fallback is a base primitive already wired to the shared tokens, so it renders on brand by default. And where something genuinely new is needed, it is built from the tokens directly, never from raw values, which makes it a candidate for promotion into the system later.

The point of the layers is that there is no dead end. A team never has to choose between staying on brand and continuing delivery, and the system does not need to anticipate every component a customer engagement will require; it needs to guarantee that whatever gets built starts from approved material.

Give teams a starting point at each level

At Obin, we organize product experiences around solutions—workflows such as loan origination and claims processing. These sit between the shared platform and an individual customer deployment.

That gives us three places to support reuse.

1. The platform supplies foundations and components. Typography, semantic colors, spacing, buttons, and layouts belong in shared packages. Our component work captures behavior alongside appearance: how a card grid responds to available width, how button sizes coordinate padding and text, and how interaction states behave.

2. Solutions assemble those components around a particular kind of work. A case-handling experience and a memo-writing experience need different compositions. Existing solution screens provide a starting point; making their reusable patterns discoverable as individual components is a next step for the system.

3. Customer deployments adapt the solution. Customer and solution themes already support scoped visual differences. Requirements specific to a customer’s process can be implemented within the relevant workflow without immediately becoming platform-wide behavior.

Consider a customer who needs an additional review step. The team can start with the solution’s existing review experience and build the new step using shared controls. The customer’s review rules stay scoped to that implementation.

If the interaction later proves useful across engagements, it becomes a candidate for a shared solution pattern. If the work improves a general-purpose control, that improvement can move into the platform.

The scope of reuse follows the scope of the need.

Make the building blocks usable in delivery

The fallback layer above only works because of deliberate implementation plumbing. 

Our implementation work connects the visual foundation to the product through token mappings, theme integration, component packages, and consistency checks. This is especially important where different UI libraries coexist.

For example, connecting shadcn variables to the shared tokens allows those components to consume the platform’s visual foundation. Theme integration must also account for MUI surfaces so a mode change works across the application.

These connections need verification. In one implementation, dark mode changed some surfaces while MUI components remained light. Synchronizing the theme mechanisms addressed the mismatch.

Adoption rules need the same attention. A check requiring shared loading components initially applied to packages that could not import the approved replacement. The check was reduced to a warning until the dependency path was available.

Enforcement goes below the component level too. The rules that hold the system together live in the codebase as lint checks, not in a guidelines doc: no raw color values, no off-system typography, no arbitrary pixel values where a named token exists. Whether it's a teammate or an AI tool reaching for a hex code, the check stops it before review instead of someone catching it after. Tests do the same for the facts the system depends on, like control heights and hardcoded colors in shared components, so a regression fails the build rather than shipping quietly. Consistency shouldn't depend on anyone remembering the rules, especially in the era of minimal human intervention.

The lesson for our system is: distribute the component, document its use, make it reachable from consuming applications, and then enforce adoption. Forward-deployed teams should have a clear way to satisfy a standard while continuing their delivery work.

Show Forward Deployed Pods what to use—and reviewers what changed

Pods need to see the components that are available for them to use. They need working examples that show the available sizes, states, and compositions.

Storybook provides that reference for shared components. It gives a team a place to inspect behavior before using it and gives UX a place to review changes independently of a customer workflow.

The assembled experience needs a second level of review and current examples serve another purpose. They give teams concrete material to use with their tools. Keeping those examples aligned with the shared packages reduces the chance that a prototype starts from an outdated implementation.

Bring useful customer work back into the system

Forward-deployed pods encounter requirements the shared system of solutions, platform and design system does not yet cover. They need room to build and validate those experiences.

We want promotion into the design system to be a deliberate step after that learning:

• Identify the behavior that helped the customer.

• Separate it from the customer’s terminology and business rules.

• Decide whether it belongs in a solution pattern or a platform component.

• Add an example and appropriate checks so another team can adopt it.

Leveraging our integration to storybook we plan to enable which components are used more frequently across solutions so that agents can learn to pick the right components through a weighted metric as early as the prototyping phase. 

It lets immediate customer work proceed while creating a route for proven improvements to reach other teams.

Measure the work left after the prototype

The first prototype shows how quickly a team can express an idea. The actual implementation shows whether the design system is helping delivery.

We want to measure how much of the prototype survives into the application, how often teams recreate existing components, and how much review time goes to recurring visual corrections. We also want to understand whether an improvement from one deployment becomes easier to use in the next.

Our foundations, shared components, themes, and review tooling provide parts of that system today. The next task is connecting them into a dependable workflow for forward-deployed teams.

Success is a team starting with an existing solution, adapting it to a customer’s needs, and reaching a working experience with less rebuilding.