Lee Walters / Hoare Lea: Open Origin

Establishing an evergreen design system for scalable engineering tools.

Architecture

Parallel delivery with clear boundaries

Consistency

Shared patterns guiding everyday decisions

Stewardship

A platform teams could own and evolve

Figure: Open Origin summary hero
Intent: summary
Explains: The case study’s framing statement and read-time, introducing the design system and architecture focus.
Claims supported:

  • The work established an evergreen design system for scalable engineering tools.

Project snapshot.

Open Origin was the architectural foundation beneath the wider Origin platform: a micro‑front‑end framework that enabled teams to build and evolve features independently while maintaining consistency. I led the front-end architecture and developer experience, established shared engineering standards, and created an evergreen component library that was created to form the basis of a firm-wide design system.

The challenge.

The Origin suite was growing quickly. Multiple teams needed to ship features in parallel, but our early prototypes showed fragmentation: duplicated UI patterns, inconsistent behaviour, and diverging code conventions. We needed a modular architecture, a shared source of truth for design decisions, and a scalable foundation that kept the product coherent as it expanded.

My approach.

Micro‑front‑end strategy

Drawing on emerging practices in micro-front-end architecture and Webpack’s Module Federation, I implemented an architecture where each platform tool could be built, tested and deployed in isolation and maintained as a separate feature bundle. Module federation handled shared runtime modules and allowed teams to iterate without version lock‑in. Shared contracts defined data shapes and behavioural expectations, while the central shell application managed routing, authentication and global state. A lightweight event bus enabled controlled cross‑feature communication without creating tight coupling or leaking implementation details.

Design system

To prevent UI fragmentation, I engineered an evergreen component library delivered through module federation. This allowed every micro-front-end to consume a single, versioned set of UI primitives, engineering-specific form controls, layout patterns and accessibility rules. All components were documented in Storybook, giving the organisation a shared source of truth for behaviour, states and usage guidance.

Over time, the library evolved into an early-stage industrial design system tailored to engineering workflows. The long-term vision was for it to sit alongside a sister presentational design system developed with the firm’s creative studio, both grounded in shared principles and design tokens as the common decision-making layer. The system was intentionally lightweight, with a clear roadmap shaped by known scaling challenges: federation-aware component governance, automated visual regression testing, stricter type contracts and more robust contribution workflows.

As with any design system, it was never treated as “finished”. Instead, it was designed to mature in response to real-world use, team feedback and the evolving needs of the platform.

Agnostic development, wider team enablement & engineering quality

The architecture and design system enabled truly agnostic feature development: internal teams, distributed teams and third‑party partners could all build independently with confidence that new features would integrate seamlessly. Module federation allowed contributions without dependency collisions, and Storybook ensured visual and behavioural cohesion.

To maintain quality at scale, I embedded component‑level testing using React Testing Library with a Jest runner. This safeguarded interaction patterns across micro‑front‑ends and ensured that shared components behaved predictably as the system evolved.

Shared ownership

A key intended outcome was that our central product and design‑engineering team would co‑own the system. The architecture, component library and governance model were deliberately designed so the team could contribute, refine and evolve the system together - ensuring it remained healthy, relevant and trusted as it grew.

Outcomes.

  • Parallel feature delivery without dependency conflicts
  • Faster releases supported by reusable components and clear patterns
  • Reduced maintenance overhead and improved onboarding for new contributors
  • A resilient design system that guided decisions and maintained coherence

Designed for humans, built for AI.

With the architectural foundations and design system established, the next planned evolution was to make the ecosystem more agent‑friendly. Storybook’s MCP add‑on offered a way to expose component relationships, constraints and flows as structured metadata - the ideal substrate for AI‑assisted prototyping and front‑end development.

By enriching components with semantic documentation, usage rules and behavioural contracts, we envisioned future AI agents being able to assemble screens, scaffold feature modules and validate interaction patterns automatically. This would allow teams to prototype faster, reduce rework, and extend the design system into an intelligent, self‑describing platform asset.

Technologies used

  • TypeScript
  • React
  • CSS
  • Chakra UI
  • Style Dictionary
  • Storybook
  • Testing Library
  • Webpack

Looking back.

Open Origin showed how micro‑front‑end architecture and a living design system can scale gracefully inside a complex engineering organisation. For me, it demonstrated the value of treating architecture, UX, and design governance as one continuous practice.