This case study is password protected, please enter the password to continue!

Return to projects

Design System at Selective Insurance

Selective's customer portal had grown for years without a design system. As the newest designer on the team, I saw an opportunity everyone else had gotten used to, and proposed building one from scratch.

Timeline

April 2023 to July 2024 (~1 year, built incrementally alongside primary responsibilities)

4 Weeks, Fall 2025

Team

Sole designer (collaborated with UX team lead and developers)

Tools

Figma, FigJam, Adobe XD

At a Glance

The design system not only improved efficiency, consistency, and user experience across the product but also transformed how the team worked.

The Problem

Selective's customer portal had grown for years without a design system. As the newest designer, I saw what everyone else had gotten used to.

  • Inconsistent patterns: The same action behaved differently across every flow

  • Accessibility failures: Color contrast, focus states, and keyboard navigation broken in core flows

  • Repeated work: Designers rebuilt the same components from scratch for every feature

  • Developer guesswork: No specs meant developers made UI decisions case by case

Nobody had asked for a design system. The team was used to working this way. But I recognized these weren't just annoyances. They were symptoms of a missing foundation, and they were compounding with every new feature. So I proposed and led the initiative myself, with no dedicated time and no mandate.

The Approach

I broke the work into four phases, driven by constraints: no dedicated time, so every phase had to deliver value immediately while building toward the full system.

Phase 1: Discovery and Research

Understanding what was actually broken and where to start.

I audited the existing portal and talked to designers and developers to map the friction. Four insights shaped everything that followed:

One more thing fell into place: the team was migrating from Adobe XD to Figma. Instead of retrofitting a system into existing files, I could build from the ground up. I pitched this timing to my team lead, and that's what got the green light to start.

Phase 2: Foundation and Design

Building a system while shipping features on deadline.

I started with design tokens: color, typography, spacing, elevation, grid. Then moved to high-impact components, building each one with every necessary state (default, hover, active, focus, disabled, error).

Challenge: The color system conflict. Selective's brand colors didn't have enough range for a full UI system. I needed tints, shades, and semantic colors for error, warning, and success states. The brand team saw this as diluting the identity.

I couldn't override them. Instead, I demonstrated specific failures: error states that didn't meet contrast, hover states indistinguishable from defaults, disabled states identical to active ones. Once the brand team saw these concrete breakdowns, they agreed to a controlled expansion that maintained brand integrity.

Challenge: The stop-start reality. Some weeks I made major progress. Other weeks, feature deadlines consumed everything. This forced a useful discipline: every component had to be immediately usable in real feature work. No theoretical "might need this someday" components. Everything earned its place.

A key design decision: Simplifying what was overcomplicated.

For every component, I created usage guidelines with dos and don'ts, WCAG accessibility standards, and detailed implementation specs. Documentation wasn't an afterthought. It was the difference between a system that gets used and a library that gets ignored.

Phase 3: Testing and Refinement

Finding out what works in theory doesn't always work in practice.

I walked designers through the system and asked them to use it on real features. Some things worked immediately. Others didn't: naming conventions that made sense to me confused others, some components like button had many variants that made decision making harder, and some components needed additional states I hadn't anticipated.

Challenge: The developer platform crisis. When I brought the system to engineering, I learned their low-code platform couldn't support the component architecture I'd built. The variants, nested states, and responsive behaviors were beyond the platform's capability.

I had a choice either to simplify the system to match platform limitations or maintain design standards. I chose the latter option. A design system that codifies "good enough" isn't a design system. I documented the gaps clearly so the team could prioritize engineering improvements over time

Phase 4: Rollout and Adoption

The hardest part wasn't building the system. It was getting people to use it.

I published the Figma library, organized documentation, and created onboarding materials.

Then I waited for adoption to happen. It didn't.

Challenge: The 30% gut punch.

After the first month, only ~30% of new designs used the system. Designers kept reaching for old XD patterns out of habit. The system was available. Most of the team was ignoring it.

I realized publishing a library is passive. People don't change how they work because a Figma file exists. They change when someone helps them through the transition.

The Outcome

The numbers

  • 20% Faster design time

  • 40% Duplicate components eliminated

  • 50+ Reusable components created

  • 90% Team adoption

Beyond the numbers

  • Accessible by default: Every component WCAG-compliant with contrast ratios, keyboard nav, and focus states

  • Cohesive UX: Consistent patterns reduced user friction across the portal

  • Smoother handoffs: Shared language and clear specs reduced design-dev back-and-forth

  • Room to grow: Structured to expand beyond MySelective to other products

What I Learned

Being new was my advantage. Everyone else had normalized the inconsistencies. I saw them because I hadn't. I've learned to trust that perspective: what feels obviously broken to a newcomer often is.

Design systems are change management. I thought the hard part would be designing components. It wasn't. The hard part was getting people to change how they work. Building the system took design skills. Rolling it out took empathy, patience, and showing up for people one project at a time.

Maintain standards even when it's uncomfortable. When engineering couldn't support what I built, the easy path was to simplify. Holding the line meant the system represented where the product should go, not where the platform currently was.

This project changed how I think about design. Before this, I designed screens. After this, I designed how a team works. I went from being the newest person in the room to the person the team relied on for the foundation under every feature they shipped. That shift, from designing artifacts to designing systems and influencing culture, is what I want to keep doing.


Let's connect :)

Always happy to chat about design, research, or potential opportunities.

Let's connect :)

Always happy to chat about design, research, or potential opportunities.

Let's connect :)

Always happy to chat about design, research, or potential opportunities.

©

2026