Design Systems

Below is a documented and summarized process on how I approached design systems across multiple organizations. Although the approach and final result were different for each project, the core framework can be utilized as a guiding tool for future design systems iterations or implementation.
‍
To read about how I apply this process, click below.

design systems & process
Read Case Study
Home IconHOME
  1. Framework
  2. Assessing a design system current state
  3. Design system structure
  4. How I build a design system from scratch
  5. Maintaining a design system
  6. Governance process
  7. Measure adoption
  8. Maturity stages

Jump to

Framework

Design System framework represented in a flow which is covered in the next sections

Assess the current state

  1. Analyze the design system maturity stage.
  2. Address accessibility as a practice.
  3. Evaluate process for development & design collaboration.
  4. Gather analytics on how the design system is used.
  5. Evaluate the maintenance & governance process.

Design system structure

Design systems have multiple structures to support an organization development/production phase. Below are a few of those pillars and their elements.
A 3d image of a piramid

Principles

Rules for maintaining and adapting the system
A 3D image of a sphere

Design language

Defined language for components across the system
A 3D image of a cube

Design artifacts

Accessibility guidelines
Use cases
Tokens
UI components & patterns
A 3D image of a sphere

Component library

Naming conventions
Code standards
Code source for components & patterns

Process

Icon of people sharing ideas
Understand developers' needs and eco-system
Users icon
Assess UX & Dev design hand off process
List icon
Create UI inventory & find components language
Users outlined icon
Buy-in from leadership and key influencers in the process
A person's head with a lightbulb icon
Address architecture and tech debt
Map icon
Define a blueprint and build an MVP for the future
A rocket icon
Launch design system pilot/MVP
Graph chart icon
Gather data & analytics to measure success and system adaptability

Maintaining a design system

Design systems have shared ownership with UX, development, and product.

In the early stages of building a design system, most teams start out being dispersed. Dispersed teams are composed of subject matter experts that belong to other teams - designers, researchers, product owners, QA, developers. These things usually depend on the structure and organization size. The organization structure and size of the UX team will also dictate additional responsibilities within the design system team (e.g. design reviews, developer experience, on boarding process, etc.)

As the design system becomes more mature, a centralized dedicated team will allow the system to scale and support multiple applications and platforms.

Who should maintain the system?

Illustration displaying the difference between centralized and dispersed teams.

Types of systems

Illustration displaying the multiple layers of an external as well as internal design system
With different layers of complexity, some design systems are built using other open source systems.

While some of those systems offer Theming, customizing the elements of open-source systems can inevitably happen as "out of the box" components don't always solve all business problems & use cases. An established governance process for when things should be customized or added to a system will avoid tech & design debt. I refer to the design systems built on external sources as micro-systems.

A design system built in-house will require a similar governance process that will address things such as adding new features, adapting existing components, pushing changes, and communicating them to the organization.



Governance

1. IDENTIFY COMPONENT NEED

  • Define use cases
  • Review (custom) component case with a governance group

2. INITIATE THE PROCESS

  • Add request to backlog
  • Agree on a timeline to push the changes
  • Prototype new component design
  • Review design with dev & product lead

3. TEST

  • Usability test
  • Accessibility
  • Responsiveness
  • Browser & device check
  • Pilot complex patterns

4. ADD COMPONENT

  • Update library with changes
  • Update documentation & use cases
  • Prepare demo
  • Communicate updates with team leads
  • Track usage & adoption for improvements

Measure adoption

Why measure adoption?

Design systems work as an aid for organizational problems. Inconsistencies are a symptom of a misaligned design production.
‍
I worked with teams to set out a clear goal (what problems do we want the system to solve?) and base metrics which served as KPI's in early stages of the system.

Design system adoption can be measured for existing or future features. That means requests and tasks will need to be built into a roadmap, followed by a backlog to support that. Adopting design systems for future features is typically easier, as it doesn't require rewriting old legacy code, or revisiting forgotten code sources. To update legacy systems and code requires clear alignment with architecture and tech leads, as well as PO's and scope.

What do we measure?

Measure the things you want to improve.
‍
This will depend very much on each organization. Some examples from my past include sprints efficiency, code implementation, quality of documentation, etc.
Icon of people sharing ideas
process and team transparency
Questionnaires and surveys.
Interviews to dive into more specific data points.
Open office hours.
Users icon
TEAM PRODUCTIVITY AND EFFICIENCY
SCRUM burndown charts.
SCRUM velocity.
Time spent during design hand-off.
Onboarding time spent for a developer.
Onboarding time spent for a designer.
Code icon
code & design implementation
Running queries for commits information that involve the component library.
Code reviews.
Design reviews.

Maturity stages

A product goes through multiple maturity stages. And so do design systems.

Establish
This phase is dedicated to learning, establishing tokens and base components. Teams spend time creating processes and analyzing the current state of applications and technologies.

GrowAs the system is growing, some components' use cases might overlap. Best practices guidelines, do's, and don'ts can establish ground rules for everyone. The team starts performing, and there is awareness of the design system in the organization.
‍
OptimizeThe design system team focuses on creating more complex patterns & layouts, and at this point in time, the product roadmap aligns with the design system one. 

ScaleThe design system synchronizes with initiatives and all teams in the organization. A mature design system has established processes, and it's a breathing product.
‍
‍
Illustration displaying the difference between centralized and dispersed teams.

Speaking engagements

Speaking engagements about this topic include UXPA Cleveland, ConveyUX Seattle, and UserDefenders Podcast. The most recent one below at @Mento Design Academy.
MediumLinkedin

Homepage photography provided at the courtesy of NIK.