Created a shared foundation for internal tools that had been evolving independently.
Case study
West Monroe
Created 2023
Wemo Design System
I led the design strategy and Figma architecture for a shared system that helped 3-4 internal product teams move from fragmented interface decisions to a scalable product language.
My role
Lead designer for system strategy, Figma architecture, component guidance, and adoption support.
I translated repeated delivery friction into a reusable foundation designers and engineers could trust.
Built the system around reusable decisions rather than one-off page decoration.
Structured documentation and component properties around the people using the system daily.
Gave teams a clearer starting point for product work and handoff decisions.
Hiring manager takeaways
How I approached the work beyond making a component library.
This case study is about system thinking, not just UI inventory. The value was in creating structure that could survive active delivery work, designer preferences, and engineering constraints.
Aligned product teams around shared decisions
I framed the system around recurring product choices: color use, spacing, naming, variants, component states, and patterns teams were already rebuilding.
Designed the system experience inside Figma
I treated the library itself as a product, with findable structure, useful properties, clear prompts, and documentation that reduced hesitation.
Bridged design standards and implementation reality
The system was shaped to help engineers map visual decisions to reusable product behavior instead of interpreting static mockups every time.
The purpose
To create and deploy a design system to align with 3-4 internal tools designed and built by individual product teams.
Wemo
Design System
Case Place
Team of 12
Pricing Tool
Team of 11
Nigel
Team of 8
Problem framing
What problems were we solving?
The system needed to remove recurring decision debt without turning into a heavy process layer teams would ignore.
Consolidating styles
Convert all styles into a single system by addressing primitives first, then semantic styles, and tying them together using variables.
Component framework alignment
Select a UI framework such as Material or Mantine that all teams could agree on.
Eliminate custom components
Find and convert one-off custom or embedded elements that were not componentized.
Reduce time and resources
Minimize the effort for designers and engineers to build out experiences from scratch.
The research
How do I determine a design system framework that works best for users?
Before building, I studied familiar UI frameworks and design systems so the library would feel intuitive to designers and legible to engineers. The goal was not to copy a system, but to choose conventions my users could recognize quickly.
I compared examples from product teams and community libraries, looking for patterns in naming, navigation, component anatomy, and variant behavior.
- Popularity
- Usability
- Commonality
Material
Atlassian
Salesforce
IBM
Airbnb
Mantine
Some of the key areas I focused on during the initial setup in Figma.
Organize
Identify a hierarchy to organize the Figma file to match common UI component libraries and design systems.
Naming
Name each component, component part, and variant to reduce ambiguity and improve findability.
Properties
Break down components so their properties were mostly binary and easier to adjust.
Planning a phased approach in order to minimize issues.
Rather than asking teams to adopt everything at once, I sequenced the work from foundations to patterns so each layer could validate the next.
Mockups
To help establish styles using a reference.
Figma setup
Create a Figma file with necessary page structure.
Foundational variants
Create colors, gradients, typography, elevations, and border radius styles.
Semantic variants
Connect foundational colors and type to corresponding uses.
Spacing and grids
Define spacing values and responsive grid types.
Basic components
Create components that require alignment such as buttons and text fields.
Complex components
Create complex components such as date time picker and modals.
Patterns
Define common layout use cases that can be templatized.
The foundation
Using variables in our design system was going to minimize ambiguity and promote scalability effectively.
Variables used in the initial phase
Primitive
- Colors
- Font size
- Font weight
- Letter spacing
- Line-height
- Border radius
- Icon weight
Semantic
- Text colors
- Action colors
- Surface colors
- Border colors
- Type styles
User goals for using variables
- Reduce guessing for designers and let them focus on creating the experience.
- Help engineering mirror variants from the design system into the UI component library.
Guidelines and specs
Documenting the system so designers and engineers could move with less ambiguity.
The guidelines provided naming conventions, variants, technical and functional specifications, and implementation cues to help both designers and engineers create or implement with little-to-no ambiguity.
Base color palettes
Utility color palettes
Type styles
Spacing
Figma components and property setup
Building an experience inside Figma for the designers who would use it.
When designing components, I carefully structured properties into clear prompts so designers understood how to change states, variants, and behaviors. It was essentially a user experience inside the design system for user experience designers.
Component
Avatar status and status dot
Property menu
Component
Button
Property menu
Component
Slider
Property menu
What changed
The system made everyday product decisions easier to repeat, explain, and hand off.
The strongest outcome was not a single screen. It was a shared language that reduced ambiguity across design, engineering, and delivery conversations.
Less time guessing, more time designing the experience.
Tokens, naming, and component properties created a clearer path from rough concept to high-fidelity product work.
More explicit component behavior and handoff details.
Property menus, component specs, and examples helped reduce interpretation during implementation.
A reusable foundation for future internal tools.
The design system gave teams a shared starting point while still leaving room for product-specific decisions.