Design System

Developers were playing whack-a-mole

Imagine if every time you wanted to change something, on the website, you had to break another part of it. That was the developer's reality every sprint. Because of this, the company went further into technical debt. The backlog was cluttered with bug fixes, innovation was sidelined, and users were frustrated.

What did this mean for the business?

A fragile frontend had real downstream consequences, not just for the dev team, but for the business.

• KLAS users were using our platform to help make million dollar decisions. An inaccessible experience created real legal liability.
• Developers were working overtime every sprint, as bug fixes kept getting prioritized over new features.
• Clients bypassed the website entirely and called managers directly, creating bottlenecks and burning out our employees.

KLAS didn't have the resources for a team, so I did it myself

It would be almost impossible to overhaul the design system without first understanding what existed and how each component was used. The first month was spent documenting:

• Use cases for every component
• All existing components and variants
• Interactions and states
• Accessibility issues and failures

The best lessons are the ones you teach yourself

The results of my audits made one thing clear: I needed to become an expert in accessibility before making any major changes. I read books, took courses, and studied WCAG standards. By the end of my self-directed boot camp, I was recognized as an accessibility expert by UXCEL, scoring in the top 10%.

Re-designing the components

The existing design system had more components than KLAS needed, confusing designers and creating inconsistencies we couldn't afford. All that clutter was also a problem for developers. Manually coding each component meant projects took longer than estimated. I needed to show the team that less is more. A simpler design system would create a better user experience across the board.

Simplifying data visualizations

Users were frustrated because data visualizations had too many colors and data points, making them hard to read. Best practice calls for no more than 6 data points on a graph, but KLAS frequently had up to 12. I collaborated with multiple teams to build a color palette that was:

• 12+ accessible colors covering all department use cases
• AA accessible across all combinations
• Flexible enough to meet the needs of every team

Creating design tokens

Several of KLAS's bugs stemmed from developers manually coding each component, opening the door for errors every time something was deployed. I created a naming structure and implemented design tokens used for every component in the system, then worked with developers to connect those tokens to Azure DevOps for easy implementation.

Documentation and implementation

All this work would mean nothing without documentation. I created documentation for every component and color, covering:

• Proper use
• Improper use
• Best practices
• Accessibility standards

What changed?

The redesign didn't just fix bugs — it changed how the team worked and what they were able to build.

• Complete accessibility: KLAS now has a fully accessible design system, letting designers work confidently and reducing legal liability.
• Made headway on technical debt: developers could finally focus on innovation instead of sprint after sprint of bug fixes.
• Created respect for design company-wide: collaborative sessions with multiple departments turned the design team into a real resource.