When every designer on a team is working from a different version of the same component, the product doesn't just look inconsistent — it slows down, costs more, and breaks trust with users who notice the cracks. That was the reality at a fast-growing tech company I joined as Lead UX/UI Designer. A single button existed in seven different forms across seven different files. Teams were miscommunicating about UI implementations. Developers were rebuilding what designers had already solved. The company needed more than a cleanup — it needed a shared design language built to scale.

I led the end-to-end design and documentation of a unified design system grounded in Atomic Design methodology and the mathematical precision of the Fibonacci sequence — creating a single source of truth that transformed how the entire product team worked.

NOTE: Some visual resources have been replaced due to a client NDA.

Goal

Architect a unified design system — a single source of truth for UI elements across all product teams — that accelerates workflows, eliminates redundancy, and ensures consistent, accessible product development at scale.

Target Audience

The multidisciplinary product team: UX/UI Designers and Front-End Developers who needed a shared design language to collaborate without friction.

My Role

Lead UX/UI Designer, concept to launch. Owned the research, information architecture, design, documentation, and cross-team rollout of the full system.

The Problem

Three compounding failures were draining the team's capacity before a single line of code was written:

• Fragmented assets, multiplied. A single component existed in up to seven duplicate versions across disparate files and repositories — creating version control chaos, bloated storage, and no reliable way to know which version was current or correct.

• No shared visual language. Without a clear design hierarchy, the user experience was inconsistent across products. Outdated, off-brand assets made it difficult for teams to find — let alone trust — the right components.

• Miscommunication at the seam between design and engineering. The absence of shared standards meant design intent regularly got lost in translation. Developers were interpreting specs inconsistently, designers were fielding questions they'd already answered, and everyone was pulled away from the work that actually mattered.

Research

Understanding the people who would use the design system every day was as important as designing the system itself. I ran a mixed-methods research study with the product team:

• User interviews with designers and project managers to map their daily workflows, frustrations, and unmet needs around design components.

• Contextual inquiry — observing designers in their actual work environment to see how they navigated existing assets and where they got stuck.

• Surveys to gather quantitative data on usage patterns, satisfaction gaps, and feature priorities.

Personas

Felix

• Age: 32
• Education: BFA
• Hometown: San Francisco, CA
• Occupation: UI/UX Designer
  

Felix needs to find and implement components quickly so he can focus on creative problem-solving, not repetitive design tasks. Every minute spent hunting for the right asset is a minute not spent designing.

Sonya

• Age: 45
• Education: MBA
• Hometown: Bellevue, WA
• Occupation: Senior Project Manager
  

Sonya needs clear, well-organized design documentation because her job depends on projects shipping on time, on budget, and with a consistent brand experience. Chaos in the design system is chaos in her timeline.

Starting the design

The foundation came before the components. I established the system's core principles first — drawing from the Fibonacci sequence for spacing and proportional harmony, and Atomic Design methodology for the component hierarchy (atoms → molecules → organisms → templates → pages).

Initial structural ideas were explored through mind mapping and low-fidelity wireframing before any visual decisions were made. 

Ideation, Sketching & Wireframing

Take a look at the Design System low-fidelity prototype

Key Mockups

The high-fidelity prototype demonstrates the design system in action: navigating the component library, understanding implementation guidelines, and seeing the visual system applied consistently across multiple interface contexts. It's not just a collection of components — it's a living document that teaches the team how to use them.

High-fidelity prototype

The final high-fidelity prototype showcases a clear and workable user flow. It empowers users to explore design libraries and understand how to implement specific components. Furthermore, it provides essential guidelines and rules for their proper usage, among other functionalities. Take a look at the Design System high-fidelity prototype.

Style Guides

Going forward

Business Impact

The design system didn't just reduce duplication — it changed how the team worked. Developers stopped waiting on designers for answers they could find in the documentation. Designers stopped rebuilding components they'd already solved. Cross-team collaboration became faster because everyone was finally speaking the same visual language.

The clearest signal came unsolicited, from a developer on the team:
"We get something from the library and it's done in a snap… faster than expected is phenomenal."

That's the measure of a design system that works — not how beautiful it is, but how invisible it becomes.

Next Steps

1) Build a Storybook integration to connect the design library directly to the codebase across web apps and the marketing site.

2) Refine design tokens — particularly brand colors and spacing — for greater flexibility as the product scales.

3) Establish a tone-of-voice standard for documentation, so the system is as accessible to read as it is to use.

LinkedIn  |  edith@edithmoreno.com

© 2026