Summary

The article outlines a comprehensive four-step process for developing robust components within a Design System, emphasizing the importance of research, design, build, and release phases to ensure system adoption and maintainability.

Abstract

The author discusses the necessity of a structured component process within a Design System, drawing from personal experience where a lack of detailed documentation and design rationale led to suboptimal adoption and usage. The article introduces a four-step approach: conducting thorough research to understand component usage and best practices, designing with feedback and testing to align with product experience, building with developer collaboration and documentation, and finally releasing with clear usage guidelines and monitoring. The process is presented as a flexible framework, likened to a choose-your-own-adventure book, allowing for adaptation based on the specific needs of different Systems and components. By following this guide, the author promises the delivery of accessible, well-justified components, along with comprehensive documentation, cross-platform alignment, team buy-in, and a healthy, maintainable system.

Opinions

The author believes that a Design System's success hinges on the effort invested in its creation, including detailed usage documentation and design decision rationale.
They emphasize the importance of a collaborative process, involving developers early and often to ensure alignment and adoption.
The article suggests that without a proper component process, Design Systems may suffer from lack of conviction in design choices, difficulty in defending design decisions, and potential issues with accessibility and usage.
The author advocates for continuous learning and improvement in Design System practices, as evidenced by their own journey of perfecting the process over five years.
They highlight the value of feedback, user experience testing, and cross-functional team alignment in refining components.
The author stresses the importance of maintaining flexibility in the process, allowing teams to adapt the guidelines to their specific context and needs.
They argue that following this structured approach leads to a Design System that is not only well-adopted but also healthy and sustainable in the long term.

Why your Design System needs a component process

And where to find one

Right now, you might be thinking, I already have a Design System or a UI kit that gives me everything I need, and it’s working just fine. Do I need a process for creating components in my Design System?

And, while I could sit here and tell you, yes, your System will fail if you don’t — that’s neither true nor a reason to read on.

So, I’ll start with my why —

My first experience building a Design System was in 2016, reskinning a UI kit for a multi-product platform. I had one Developer and six months to get it product ready.

Small team, big goal, plus a UI kit, you might be wondering — did I do anything aside from reskin the components to our brand? Not really. Was it widely adopted? Not by choice. Did people know how to use it? Kind of. Could I have done better? Yes, absolutely — and this brings us back to the importance of a component process.

While we reached our goal and delivered the System, we didn’t have detailed usage documentation or rationale behind our design choices. Not only that, I had no conviction that each application was the right one for our product, nor if they were truly accessible, and neither did those who had to use it — As a result, every time someone asked me about a component or pushed back on a design decision, which was often, I either had to yield, or get defensive over a decision I didn’t make — and for those of us who have been there, honestly, it’s wasted energy.

Your Design System is only ever going to be as good as the effort you put into it — so take the time, take people on the journey, and build something so good that people refuse not to use it.

After learning these lessons the hard way — I’ve spent the last five years experimenting and perfecting my process and making it standard practice at the companies I’ve worked with, including OVO Energy and Wise.

My goal now is to teach others how to level up their Design System thinking, which has led me to create Redesigning Design Systems, an online resource for hands-on practical Design System guides and advice. Starting with, you guessed it —Practical Guide to Design System components.

Get started now, or read more about it below.

Step 1 — Research

In the research phase — you’ll develop a much more robust understanding of the existing component, including usage, issues and potential opportunities. You’ll also look beyond your product and see how other products and Systems solve similar problems and understand usage and best practices for accessibility and design.

All the while, I was starting this journey with all the right people to get solid buy-in and adoption from the outset.

1.1 Product Audit 1.2 Kickoff 1.3 Research 1.4 Research sync

Step 2 — Design

In the design phase, you’ll explore multiple different applications of the component in your product and find avenues to align and improve your product experience. Not only this but you’ll be humbled by feedback from your peers and user experience testing. Finally, you’ll get everyone aligned in your team before pressing on.

2.1 Exploration 2.2 Design crit 2.3 User testing 2.4 Design Alignment

Step 3 — Build

By the build phase, your Developers should have been on the journey with you from the beginning, but you’ll be working even closer with them to ensure all aspects of your proposed design are documented and tested.

In parallel, you’ll look at creating your component in Figma (or another design tool) whilst keeping parity with the other platforms.

3.1 Spec doc 3.2 Spec walkthrough 3.3 Design QA 3.4 Figma build

Step 4 — Release

Finally, we’ll look at putting together rock-solid usage documentation, the different types of releases, when you should use them, and how to monitor and improve your component in the long term.

4.1 Documentation 4.2 Release 4.3 Metrics

Do you need to do every step?

Yes and no. I like to think of this guide as a choose-your-own-adventure book (how great were they!). Not all Systems and components will be the same, and you might already have a rock-solid process. Even if you find one thing helpful in this guide, I’ve done my job!

My only advice is to stick to the phases in order — imagine conducting an audit after the build to find a massive flaw in your design?! Sadly, I think many Product Designers have experienced Nightmare at some point in their careers.

What will you get out of doing this?

An accessible and well-thought-through component
Research and justification behind design decisions
Foolproof usage documentation
Aligned cross-platform build
Buy-in from your team and external stakeholders = aka guaranteed adoption
A healthy, adequately maintained system

Well, what are you waiting for? Get started