Selective's customer portal had grown for years without a design system leading to inconsistent patterns and duplicated work. As the newest designer on the team, I proposed and built a scalable system for a platform serving 500K+ users.
Timeline
My role
Sole designer (collaborated with UX team lead and developers)
Tools
Figma, FigJam, Adobe XD
The design system improved consistency, accessibility, and collaboration across MySelective while reducing duplicated work and creating a scalable foundation for future product growth.
Without a shared system, MySelective accumulated inconsistencies as features were added independently over time.
This created challenges across both the user experience and internal workflows:
Inconsistent patterns across the platform
Accessibility gaps across core workflows
Repeated work from rebuilding common UI patterns
Unclear implementation standards between design and development
Growing design debt as the product scaled
Getting buy-in was also a challenge. Since feature delivery was prioritized, there was no dedicated time allocated for systems work. To move the initiative forward, I focused on delivering incremental improvements through high-impact components instead of proposing a large redesign effort upfront.
At the same time, the team was migrating from Adobe XD to Figma, creating an opportunity to introduce shared foundations while existing workflows were already being rebuilt.
I broke the work into four phases shaped by real constraints. Since there was no dedicated time allocated for systems work, each phase needed to deliver immediate value while still contributing toward a scalable long-term foundation.
Before building the system, I needed to understand where inconsistencies were happening, which patterns caused the most friction, and what would create the biggest impact if standardized first.
I audited screens across claims, billing, onboarding, and account management flows to identify recurring UI patterns, accessibility issues, and duplicated components. I also spoke with designers and developers to better understand workflow friction and implementation challenges.
Key Insights
Prioritizing the System
Since the work was happening alongside active product deadlines, I could not build the entire system at once. To prioritize effectively, I evaluated components using three criteria:
Usage frequency: How often does this component appear across the product?
Workflow impact: Does inconsistency create user friction or team inefficiency?
Dependency level: Does this component support larger patterns?
Each criteria was rated 1-3 based on my findings. Components were then grouped into three tiers based on their combined scores. The rollout was phased based on those tiers:
Tier 1 - Foundations and core controls: color tokens, typography, spacing, buttons, inputs, navigation
Tier 2 - Shared patterns: forms, cards, feedback states, overlays
Tier 3 - Context-specific and low-frequency: skeleton loader, pagination, tooltip, accordion
With priorities established, I began building the system incrementally alongside active feature work, starting with foundational elements before moving into reusable components and shared workflow patterns.
Accessible Color System
One of the biggest challenges was the color system. The existing palette did not provide enough flexibility for accessible UI states and semantic feedback patterns. Some hover states were difficult to distinguish, error colors failed accessibility requirements, and disabled states often looked too similar to active states.
I expanded the palette systematically by:
creating accessible tints and shades,
introducing semantic success, warning, and error tokens,
and validating combinations against WCAG AA standards.
This process also required alignment with the brand team, who initially worried that expanding the palette would weaken visual consistency. I addressed this by demonstrating accessibility failures and showing how the updated system preserved brand recognition while improving usability.
Additional Foundations
I also standardized typography, spacing, and iconography to reduce one-off design decisions and improve consistency across layouts.
This included:
a typography hierarchy,
a 4px spacing scale,
and a unified icon system with consistent stroke weights and visual style.
To keep the system scalable and easier to maintain, I also established a consistent token structure across colors, spacing, typography, radius, and elevation values.
Designing the Component Library
I organized the system using Atomic Design principles so components could scale predictably over time.
Atoms: buttons, inputs, labels, icons
Molecules: form groups, search bars, alerts
Organisms: navigation, forms, tables, modals
Buttons were among the first components I standardized. The existing product contained inconsistent sizing, overlapping visual styles, unclear hierarchy, and incomplete interaction states.
To support different workflows across the product, I created a flexible button system with semantic variants, standardized sizes, and shared interaction behaviors.
The system included:
semantic button types for primary, secondary, destructive, warning, success, and accent actions,
five standardized sizes ranging from X-Small to X-Large,
and reusable states for hover, focus, disabled, and keyboard interactions.
To improve maintainability, I structured components in Figma using shared properties and variants. This allowed designers to swap styles and states without detaching components or rebuilding layouts manually.
Collaboration & Constraints
I worked closely with developers to align on naming conventions, component behavior, implementation expectations, and documentation standards.
This process surfaced one of the project’s biggest challenges: the engineering team’s low-code platform, Volt MX, could not fully support some of the variant structures and responsive behaviors built into the system. Certain component states required manual workarounds, and some interactions could not be replicated exactly within the platform.
Rather than simplifying the system around current technical limitations, I documented implementation gaps clearly and aligned with developers on phased improvements over time. This allowed the system to establish long-term standards while acknowledging short-term constraints.
Documentation
To support adoption and reduce ambiguity during handoff, I documented component usage, accessibility standards, interaction behaviors, spacing rules, and implementation notes.
I also included “dos and don’ts” examples to reinforce consistent usage patterns across teams.
As designers began using the system in active projects, several issues emerged that were not obvious during the initial setup. Some naming conventions caused confusion, certain component variants created unnecessary complexity, and edge cases appeared that were missing from the library.
I refined the system through real usage by simplifying component structures, reducing redundant variants, expanding documentation where friction appeared repeatedly, and validating accessibility across contrast, keyboard navigation, focus visibility, and interaction states.
Example: Simplifying the Button System
One example was the button system. The initial version supported a wide range of semantic actions, sizes, and interaction states, but testing showed that too many options slowed decision-making instead of improving it.
After reviewing feedback from designers using the system in active work, I reduced the structure to a smaller set of standardized options that still supported the primary use cases while making the library easier to navigate and maintain.
Publishing the Figma library alone did not drive adoption.
After the first month, only around 30% of new work used shared components. Most designers continued relying on familiar XD-era patterns because they were faster and already part of existing workflows.
This forced me to rethink the rollout strategy. Instead of relying on passive documentation, I shifted toward more active support by:
pairing with designers during feature work,
creating quick-reference guides,
answering implementation questions regularly,
and establishing governance with the UX lead.
Over the next three months, adoption increased from roughly 30% to 90% across new MySelective designs.
The numbers
20% faster design workflows based on internal team feedback and repeated workflow comparisons
40% reduction in duplicate components after consolidating shared patterns into reusable libraries
50+ reusable components created
90% adoption across new MySelective designs within 3 months
Beyond the numbers
More accessible experiences: Components included WCAG-compliant contrast ratios, keyboard navigation support, and clearer focus states by default.
Consistent workflows: Shared interaction patterns and reusable components reduced fragmentation across the portal experience.
Smoother collaboration: Clear documentation and shared standards reduced ambiguity between design and development during handoff.
Reduced design debt: Designers could build from established patterns instead of repeatedly creating one-off solutions.
Scalable foundation: The system established a structure that could continue evolving as the platform expanded.
This project changed how I think about design work.
At the start, I thought the biggest challenge would be creating the components themselves. In practice, the harder parts were:
getting buy-in without dedicated time,
balancing systems work with feature delivery,
navigating technical limitations,
and driving adoption across existing workflows.
I also learned the importance of involving engineering earlier. Understanding platform constraints sooner would have shaped some architectural decisions differently from the start.