Welcome to the start of your component journey!
Whether you’re reskinning an existing UI kit, building a new System, or levelling up your current System, this guide is for you.
What is a component?
A component is a reusable interface element, like a text input or a button. They’re the building blocks of our product experiences that make them come to life.
In Design Systems, a component typically includes a cross-platform build (including design) and implementation and usage documentation.
Why should you use this guide?
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, here is 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.
And no, your System isn’t going to fail if you don’t follow this guide, but I can guarantee that it will make it a hell of a lot better, trust me.
So, let’s get into it!
What we’ll cover
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 starting this journey with all the right people to get solid buy-in and adoption from the outset.
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.
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.
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 I need to do every step?
Yes and no. I like to think of this guide as a bit of 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 this Nightmare at some point in their career.
What will you get out of this process?
- 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