How Design Systems Allow Companies to Scale: A UX Design Case Study

In 2022, I moved to the Corvallis, Oregon to work as an in-house designer for Active911 .? Active911 gained notoriety and much success over the last 10 years, grew their development team to 40+ developers, and are servicing over 500,000 monthly active users in North America, Latin America, and Europe. Amazing growth, all while neglecting design!

The CEO and product owners were excited to bring in designers, hoping we’d liven up their early 2000’s graphic user interface (GUI) but early I was faced with “noodley” code—code that is complex, unstructured, and difficult to maintain— that paved production roadblocks for our teams. Modularity was nonexistent and there was a pile of design debt—an accumulation of design inconsistencies, shortcuts, and compromises that occurred in our products' user interface (UI) and user experience (UX).

How did my team create consistent designs across smartphones, tablets, watches, netbooks, notebooks, desktops, TVs, and game consoles while following?important modular object-oriented programming concepts like?separation of concerns?and the?single responsibility principle?

This case study outlines the strategies employed and the outcomes achieved.

Problem Statement

Fix design debt while building a new product.

Lets create the context for the above statement: Active911 is available on web, iOS, and Android for all screen types. Their developers have been working in agile teams to build features and debug those features in an endless loop of tickets, managed by a product owners. Teams are divided by platform and developers are often jumping between teams scrambling to finish projects on schedule. The product owners are desperate to make their team more productive and the developers are desperate for order.

How it will help users: Collaboration and communication. A design system will allow teams to rely on a single source of truth (SSOT) across the whole company, minimizing miscommunication and discrepancies in production. Designers and developers will be able to make modular changes to components, styles, or pages. We are able to focus on separation of concerns?and the?single responsibility principle. Quality assessors (QA)s can isolate interface patterns to identify errors, inconsistencies, and performance issues.

How it will impact business metrics: Less meetings! Design changes/decisions are easily referenceable, and all component files become universally accessible. The initial creation of a design system costs time, thought, and effort, but once established, design and development will produce much faster. This in turn reduces the cost of fixing bugs, building minimum viable products (MVP)s, and testing.

Let's Create a Design System

Jeremy Keith defines a design system as:

“the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design?system. A system is a framework. It’s a rulebook. It’s what tells you?how?those patterns work together.”

Brad Frost’s simple definition:

“the official story of how your organization designs and builds digital products”

Conduct a Design Audit

Designers, developers, product owners, and QAs all began by gathering an interface inventory— going through the existing products screenshooting every page, braking down their elements and organizing it in one shared document. Read more about how I conduct my design audits in {Room2Room Movers | Conducting a Design Audit: UX Case Study}.?

Organize Your Style Guide

We predefined a set of design standards governing the visual and functional aspects of a product with a style guide. Style guides ensure consistency across your design system by standardizing elements such as typography, color schemes, and component behavior. This structured approach not only enhances the user experience but also streamlines collaboration between designers and developers, reducing design debt. By enforcing these guidelines, we maintain an organized, scalable design system that supports efficient product growth.

Next: A Component Library

A component library is a collection of reusable UI elements that are consistently styled and functionally tested, serves as the foundation for building an organized design system. By providing pre-built components like buttons, forms, and navigation elements, we ensuring consistency and reducing redundancy. Then we can focus on building our new product while maintaining a cohesive and scalable user interface.

We decided to leverage Material Design Component Library by Google to reduce development time, ensure cross-platform compatibility, and tap into a system that is constantly updated and supported by the broader developer community.

Building an Atomic Design System

Its composer, Brad Frost defines atomic design as “a mental model to help [product teams] think of our user interfaces as both a cohesive whole and a collection of parts?at the same time. Each of the five stages plays a key role in the hierarchy of our interface design systems.”?

The five stages in an atomic design system are:

• Atoms: the basic HTML elements, broken down as far as possible while remaining functional and have their own unique properties that influence how each they should be applied to the broader system.
• Molecules: simple groups of elements that work together to create functional, reusable components that teams put into broader contexts.
• Organisms: demonstrates components in action and serve as distinct patterns that can be reused.
• Templates: page-level layout that articulates the content structure.
• Pages: instances of templates showing representative content. They provide a place to articulate variations in templates to helps teams create resilient design systems.

Collaborate and Communicate

Designers aim to collaborate with front-end developers during the design process not after decisions have been made. Designers?can create lo-fi sketches to establish while front-end developers?set up project dependencies, stub out templates, and write structural markup for anticipated patterns.

Stakeholders love to join brainstorming meetings and draw “templets” on whiteboards for designers to conceptualize their ideas. Designers can break down white board sketches into its stages and plan their tasks.

Spreadsheets...

All documentation is organized in folders by their tech stack.?

Folder access varies based on team roles with the ability to view documents open to all team members but editing access belonging only to the document owners— role responsible for or the creator/s of the document.

Documentation change requests are managed with tickets marked as high priority tasks for the document owner.

Completing a New Product Concept

While building the design system, I am also building grayscale prototypes to demonstrate interactivity and responsiveness for our team’s product concept.?

I take it into account stakeholders feedback and environment while detailing the low-fidelity prototypes with already existing elements in the design system.

Sending to Production

Design would create mockups and finalize design specifications with a development ticket. The ticket would then be ingested by the developers. Design then serves as design support for developers on the ingested tickets while creating mockups for the upcoming element. We used iterative testing and feedback loops to refine the UI and A/B testing helped us identify the most effective gamification strategies.

What Happened?

Post-implementation, we observed significant improvements in our production output and internal operations:

• Meeting Frequency: The frequency of meetings increased during the process of building the design system. Designers, developers, and product owners all saw a 20% increase to their scheduled weekly meetings. Once the design system was finalized, teams scheduled weekly meetings reduced from 12 to 7.
• Bugs : Having a clear reference reduced confusion for the whole team. Anytime styles or components where used, they’d be linked the ticket to our design system. This eliminated discrepancies between our products, reducing QA written design tickets by 90%.?
• Product Launch 1.0 : Product Concept 1.0 was launched in 2 months. With the backend of the product already built, the test version available to beta only needed design to build the frameworks and the team would fill in that framework with the elements existing in the design system.
• Product Launch 2.0 : Product Concept 2.0 was launched in 5 months. This product launch included innovative features which we designed and built using our design system. With a bigger team and more time, this product was a success and praised by our users. The demand for the hardware that accompany our new product is greater than the supply and it looks like Active911 struck gold again.

Developer and QA feedback on the atomic design system was overwhelmingly positive, with many appreciating the added value of the organized referencing system.

Challenges and Learnings

My biggest challenge was selling the design system to steakholders. Due to deadlines, our time was strictly focused on producing the new products and servicing them. It was also difficult convincing a team of engineers who are used to “building the plane as they fly it” to set time aside for meetings that have no immediate impact on user metrics. After explaining how design systems?promote consistency and cohesion,?speed up our team’s productivity,?establish a more collaborative workflow,?establish a shared vocabulary,?provide helpful documentation,?make testing easier, and?serve as a future-friendly foundation I was eventually granted a team and we set sail.

I learned the importance having communication funnels with engineering AND with stakeholders. Early, I failed to communicate to my product owner the steps for taking us from concept to complete. Low-fidelity/grayscale prototypes are essential in the process but are not meant to be looked at as final concepts, rather launchpads for discussion. This way, everyone is involved in the design process.

In this case where the benefits of grayscale prototypes was not clarified, the product owner took it upon themself to finish styling specific patterns and refining the overall structure of the model. The team feared design couldn’t produce and our product owner felt spread thin. We ended up building and releasing all the models our product owner had styled without any testing. The feedback from users was negative and design was at fault. The product concept was shelved and the whole team set to focus on product launch 2.0.

This failure stuck because I know that if I explained my process to team ahead of time, our collaboration would have been more successful. In response, I have since built presentations that explain my design process with feedback templets so team members know how I can help them and how they can help me.

At The End of The Day

How we plan on minimizing design debt moving forward:?

• Regular Audits: Periodically review the product’s design to identify inconsistencies and areas that need improvement.
• Prioritize and Address Debt: Just like technical debt, design debt should be tracked, prioritized, and addressed systematically as part of the product development process.
• Collaborate Across Teams: Ensure that designers, developers, and product managers are aligned on design goals and the importance of maintaining design quality.

Its inspiring to see the forward progress that comes from implementing a design system. The work being done at Active911 is ethically good work and I am always proud to speak on how our products help heroes save lives.?