Many apps, one UI: first steps to a unified user experience

Introduction

Many organizations have several applications, each with its own frontend. I recently worked on this problem firsthand. The symptoms were easy to spot: the apps looked and behaved differently.

Sometimes the gap is small: another shade of the brand color, a button with a different radius. Often it's not. One app navigates with a top bar, the next with a sidebar. One form validates as you type, another only after you submit. The same data table sorts, filters, and paginates in three different ways. A user switching between two of these apps can feel like they switched companies.

The goal sounds simple: one consistent design across all of them. The ambitious version goes further and brings every app into a single application with one user experience.

This kind of project often gets postponed. It touches every team, ships no new feature on day one, and is hard to estimate. AI tools can help with repetitive implementation work, but they do not replace the design and architecture decisions.

If it works, you get:

• visual consistency across products
• UI and UX patterns built once, not reinvented by every team
• easier collaboration between design, engineering, and product
• shared accessibility standards that teams can apply consistently
• UI updates made centrally and shipped everywhere

Scope of this article

This article covers one slice of that work: the visual layer. Colors, typography, spacing, and the CSS that applies them. It's the most practical place to start across Angular, Vue, and React. Shared design tokens can reach each app through its styling system, although adopting them still takes work in each codebase.

Shared component libraries, project structure, and micro-frontends come later and deserve their own articles. What follows isn't a fixed recipe either. It's a set of possible first steps, and how far you get with each one depends on the projects you start with.

The starting point

Yours will differ in the details, but the shape is usually the same:

• no shared tech stack: on the frontend you'll find Angular, Vue, React with Vite, and React with Next.js, often in different versions
• no shared component library, so each project builds its own buttons, forms, and tables
• design lives in Figma, one file per project, as the source of truth

The diagram below shows the layers such an architecture usually has, and who owns each one.

The design team defines the UI for each project separately and owns it in Figma. Product teams build features on top of it, each with its own UI implementation, and every clarification has to travel back to the design team. One design per project, one implementation per team, and nothing shared in between.

That has a price. Every fix gets made six times, and every new pattern gets invented six times.

Not every project starts in the same place

Complexity varies a lot between projects, and it decides how quickly each one can adopt a new visual layer:

• low: one theme file and a handful of screens, ready for new tokens almost immediately
• medium: styles spread across components, but with enough structure to build on
• high: legacy code, several styling approaches mixed together, and no theme at all

Low-complexity projects make good pilots. High-complexity ones usually need cleanup before any redesign can land.

Step 1: a common design system

Start with the design team and a common design system in Figma. It's the building block every other team will stand on, and the reference every later step checks against.

Before designing anything new, identify the patterns every app already shares. For the visual layer, the foundations matter most. They become your design tokens:

• typography: font families, sizes, weights, line heights
• colors: brand, neutrals, and semantic states like success or error
• spacing scale
• border radius and border widths
• shadows and elevation
• breakpoints
• motion: durations and easing

Then map the major components, even if you won't share them yet:

• headers and footers
• navigation, both top bars and sidebars
• buttons and links
• form fields and validation messages
• data tables with sorting, filtering, and pagination
• modals, toasts, and other feedback
• empty, loading, and error states

Step 2: redesign with AI

AI can speed up exploration, but architecture decisions still need care. Treat generated designs as drafts. Check them against your design system, the existing product, and the constraints in code.

Once the design system exists in Figma, try AI-assisted exploration. Tools like Claude Design support quick iterations:

• bring real screens from Figma into Claude Design as visual references
• redesign them on top of the design system
• hand the result off to coding agents

Early experiments are worth the time. The integration between Claude Design and Claude Code lets you move into code quickly and see what a change would actually do to your codebase.

An example redesign prompt

Expect the first attempts to need a lot of manual steering. It can be frustrating. Typical problems:

• lost context halfway through a session
• design patterns that don't match the design system
• unwanted layout changes
• made-up elements nobody asked for

Each of these corrections is useful. It tells you what the next version of the instructions has to say.

Turn it into a shared skill

Once the workflow works, don't keep it in your chat history. Turn it into a reusable skill: a packaged set of instructions the agent loads whenever the task matches. Your teammates get the same rules, and so does every team across the company.

Step 3: move the redesign into code

Anyone who has been through this knows how hard it is to turn a new design into real, existing code. It rarely goes as planned. Unexpected situations show up all the time, even more so when the goal is consistency across several applications at once.

Keep the scope on the CSS layer. Before you change any code, check that you have:

• a contract between Figma and code, usually design tokens, kept in sync on both sides
• a theme mapping in each project that consumes the shared token values
• a well-structured frontend codebase
• a readable component architecture
• clean styling with good naming conventions

Each gap here comes back in every redesigned screen, so close it first. In a high-complexity project, that cleanup can be most of the work.

Plan the first experiments

Start small and widen the scope step by step:

1. redesign the existing theme
2. redesign the common components
3. redesign specific pages
4. redesign the components and layouts that only live on those pages

A side note from experience: for this step, Claude Code usually gives a better experience than Claude Design. It works directly in your codebase, so it sees the real constraints.

The first changes are the hardest. Once they meet the requirements, the next ones go faster, and the process becomes almost automated. To keep both sides aligned, run /design-sync in Claude Code. It brings your design system into Claude Design, so redesigns start from your real components, and it can push what you've built back to the Claude Design canvas.

Step 4: review and sync

At this point you have:

• turned existing Figma screens into redesign drafts in Claude Design
• handed the drafts off to Claude Code
• implemented code changes that meet the redesign requirements

Next comes the review, and that's where it gets tricky. The biggest gap is the missing sync between the dev teams, the design team, and Figma.

The redesign now lives in Claude Design, while the source of truth is still Figma. Claude Design's documented export options do not include a native Figma Design file. Figma's MCP server can write to the canvas, but access depends on the team's plan and seat permissions. That leaves a practical question: how will the design team review and approve the changes in Figma?

If the approved design never makes it back to Figma, the file stops reflecting what the product ships.

What I'd do differently

Looking back, I'd use a shorter implementation flow:

1. skip the Claude Design step
2. start in Figma and keep it as the only source of truth
3. create a deterministic hand-off from Figma to Claude Code
4. implement the code changes with Claude Code

Deterministic means the same Figma file always produces the same tokens, for example Figma variables exported and turned into CSS custom properties by a build step, not by an agent's interpretation. Design reviews then happen where the design lives, and code always follows Figma.

Summary

None of this works without careful planning, and that includes the experiments. Each team needs to focus on its architecture and the complexity of its projects.

This article covered the visual layer. The next layers are topics for future articles:

• project structure
• micro-frontend integrations, where they fit
• shared component libraries

Put together, the UI side of the organization might end up with new layers and a new structure:

The design team owns Figma and defines the visual layer. UI framework teams turn it into shared component libraries, one per framework, with stable component APIs. Product teams build their apps on top of those libraries, possibly as micro-frontends, and feed product design needs back to the design team. Visual changes move from design to implementation. Product teams bring new needs back to design, and each layer has a clear owner.