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.

Practical Guide to Design System components

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.

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.

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.

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.

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.