# Enterprise Design System: Building a scalable design foundation for enterprise applications UX case study by Rita Omatsone, Senior UX & Product Designer. https://ritaomatsoneux.com/work/enterprise-design-system > Shared components, responsive layout scaffolding, accessibility and documentation that let Lowe's product teams build consistent enterprise applications without solving the same problems over and over. - **Domain:** Design systems - **Year:** 2023 - **Platform:** Desktop web, responsive - **Role:** Product Designer - **Users:** Product designers, engineers and teams building enterprise applications - **Scope:** Design tokens, components, responsive layouts, accessibility, documentation - **Breakpoints:** XXL, large and medium ## Results - **40%** faster design delivery - **200+** engineering hours saved per quarter - **85%** of design and development teams adopted it within six months - **WCAG 2.1 AA** accessibility for audited components ## The challenge As enterprise applications grow, keeping one consistent experience across products, teams and screen sizes gets harder. Duplicated components, inconsistent interaction patterns and repeated design and engineering work slow delivery and make products harder to maintain. I worked on establishing an enterprise design system: **standardized shared components, responsive layout patterns, built-in accessibility and documentation** that helped teams apply the system across applications. ![Four existing applications side by side, each with a different header and navigation: stacked browser tabs, a centered logo, an icon-only rail, and filters nested in a dark side menu](https://ritaomatsoneux.com/images/cases/eds/before-audit-1200.webp) > The challenge was to create a shared foundation that improved consistency without stopping teams from meeting the specific needs of their applications. ## The opportunity **Three connected opportunities** - **Standardization:** Shared components and patterns that teams can apply consistently. - **Scalability:** Responsive layout foundations that adapt across screen sizes and application contexts. - **Adoption:** Documentation and guidance that help design and engineering teams understand and use the system. The objective was never just a component library. It was making consistent, accessible design **easier to deliver** across the organization. ## Understanding the system A scalable design system has to do more than look consistent. Components must work inside real product workflows, respond to different screen sizes, and behave predictably for designers and engineers alike. The system covered five layers, each building on the one below. ![Diagram: five layers of the design system, from design tokens to reusable components, responsive scaffolding, accessibility and documentation](https://ritaomatsoneux.com/images/cases/eds/system-layers-1200.webp) **From the working boards** ![FigJam board: global header anatomy with pinned home tab, browser tabs, new tab button, history navigation and slots](https://ritaomatsoneux.com/images/cases/eds/board-header-1200.webp) Global header anatomy ![FigJam board: interim-state concepts for single-instance applications such as Orders and Showroom in the tab bar](https://ritaomatsoneux.com/images/cases/eds/board-interim-1200.webp) Interim-state tab concepts ![FigJam board: layout combinations for body, navigation and support regions with inline and overlay drawers](https://ritaomatsoneux.com/images/cases/eds/board-layouts-1200.webp) Every layout combination ![FigJam board: navigation drawer scenarios, when it collapses to a rail and how icons are used](https://ritaomatsoneux.com/images/cases/eds/board-nav-1200.webp) Navigation drawer scenarios *Discovery happened in shared FigJam boards with product teams: every header state, layout combination and navigation scenario was mapped before anything became a component.* ## Design principles - **Consistency by default** (Shared and documented): Shared components and clear usage guidelines help teams deliver consistent experiences across applications. - **Reuse, not rigidity** (Room for real differences): Components support the common cases while allowing for legitimate differences between products and workflows. - **Responsive at the core** (Part of the system): Responsive behavior is designed into the system, not patched screen by screen. - **Accessible by design** (Inside every component): Accessibility is considered during component design and validation, not left to the end. ## A shared component foundation ### Decision 01 · Standardizing frequently used patterns When every team solves the same design problem independently, the result is duplication. I worked on defining reusable components for common enterprise needs, including navigation, the global header, tables and forms, with clear structures and variants. ![Global header anatomy: brand, pinned home tab, domain tabs and new tab on top; history, wayfinding menus, global search, customer controls and associate controls below, marked persistent or conditional](https://ritaomatsoneux.com/images/cases/eds/header-anatomy-v2-1200.webp) ![Layout anatomy: navigation, body and support regions, with drawers sliding over them, and the rule chain canvas, regions, panels, tiles, content](https://ritaomatsoneux.com/images/cases/eds/regions-1200.webp) - Consistent visual and interaction patterns - Clear component structures and variants - Components designed for reuse across applications - A shared foundation that still respects product needs > A shared foundation lets teams start from established patterns, and gives design and engineering a common language for discussing, documenting and maintaining the interface. ## Responsive layout foundations ### Decision 02 · Designing for every screen size Without shared layout rules, every team implements responsive behavior differently. I worked on responsive scaffolding across **XXL, large and medium breakpoints**, with consistent grid rules and layout constraints, so layout behavior became predictable instead of re-solved on every project. ![Breakpoint scale from 0 to 1585 plus, and local navigation behavior: up to three fly-out panels at XXL, one replaceable panel at large and XL, a rail with a drawer at medium](https://ritaomatsoneux.com/images/cases/eds/breakpoints-1200.webp) - Consistent grid and spacing rules - Defined behavior for each breakpoint - Components that respond as available space changes - A usable information hierarchy at every size ## Accessibility built in ### Decision 03 · Making accessible patterns reusable Components get reused across many workflows and products, so accessibility had to live in the components themselves. I incorporated contrast, keyboard navigation and labeling and semantics into the design-system work, with guidance documented alongside each component. ![Accessibility built into components: keyboard focus order across the header, contrast ratios for header, interactive and secondary text, and ARIA labels for icon buttons, field errors and menus](https://ritaomatsoneux.com/images/cases/eds/a11y-1200.webp) - Accessible color and contrast patterns - Keyboard interaction for relevant components - Clear labeling and predictable behavior - Accessibility guidance next to every component ## Supporting adoption ### Decision 04 · Documentation that teams actually use A design system creates value only when teams can understand and apply it. Alongside the component and layout work, I contributed documentation and standards that explain not just what components look like, but **how and when to use them**, including when a different solution is the right call. ![Usage guidance: do use one right drawer, strongly caution against a sidebar plus a drawer, do not combine navigation, sidebar and drawer](https://ritaomatsoneux.com/images/cases/eds/layout-rules-1200.webp) ![Governance workflow from request to review, approval and publishing, with a feedback loop, and the move from siloed systems to one unified system](https://ritaomatsoneux.com/images/cases/eds/governance-v2-1200.webp) ## Outcome & impact - **40%** faster design delivery. common flows went from about 10 hours to 6 - **200+** engineering hours saved per quarter - **85%** of design and development teams adopted it within six months - **WCAG 2.1 AA** accessibility for audited components Shared components, responsive foundations, accessibility guidance and documentation came together as one framework that reduced duplicated work and helped teams build more consistent enterprise experiences. ## Reflection This project expanded my perspective from designing individual experiences to helping build the foundations that let teams create consistent experiences at scale. **Three lessons that shaped my approach** - **Design for reuse:** Solve common interface problems in ways that support many products, not one-off fixes. - **Make the system understandable:** Components are only useful when teams know how and when to apply them. - **Treat adoption as part of the work:** A system has to fit how teams design, build and maintain products to last.