So that's it, you're finally getting started with your design system, and it’s exciting! You've probably convinced your boss, conducted an audit, or started building a team to begin, and now, you’re wondering where to start. Should I start with the buttons? The forms? The navigation? Everything? Well, let’s get you on the right track.
Perceptual patterns VS functional patterns
First, you need to make a clear distinction between what I like to call perceptual patterns and functional patterns.
Your perceptual patterns are everything about your brand that is not interactive: colors, fonts, icons, illustrations, shadows, spacing… You can also call it your “styles” or “foundations” if that sounds better to you.
Your functional patterns are everything that your user can interact with: buttons, checkbox, inputs, header, cards… You can also literally call it “components”.
It is essential to know the difference between these patterns because when it comes to prioritizing your components, these are about your components and not your perceptual patterns/styles/foundations. So, if you haven’t, I strongly suggest you have your perceptual patterns finalized before starting work on your functional patterns. Your team needs to understand how the brand works before going any further.
Now you are ready to start prioritizing your components, here’s a helpful workshop that’s easy to implement within any organization. This workshop aims to have a shared understanding of which components are the most important, so your teams can start working on them. What you need to do before this workshop is to define the main components of your system, so you don’t need to search for them, and have a working baseline.
Here is some essential information for this workshop:
Invite all the “makers” of your design system: designers and developers, but also product managers, content specialists, UX researchers, and anyone else who will actively contribute to the system. Just keep in mind that the more you are, the messier it might be. As a rule of thumb, you should try and keep your workshop to fewer than 8 people. If you would like to invite more, hold multiple workshops.
Allow 2h to be comfortable. Any shorter, and you will be rushing. Any longer, and you’ll probably lose steam by the end of the workshop, and boredom will creep in.
This workshop works fine both online and offline. You’ll need sticky notes, a component list, the matrix, a wall and/or a whiteboard.
- If you’re doing it offline, prepare the workshop by printing your components list or writing all the components on sticky notes and displaying them on a wall so everyone can clearly see the components.
- If you’re doing it online, it works pretty much the same by preparing the components list on a virtual whiteboard or virtual sticky notes. Try to gather all the “basic” components (buttons, forms, navigation…) but also the specific ones for your business and needs (do you have particular tables, cards, maps, players…?).
Don’t hesitate to ask participants to add more components if they notice any missing ones.
This is the cornerstone of this workshop.
You have two criteria to play with:
- How often the component is used in projects
- How much it costs to develop
Obviously, the simpler and the cheaper a component is, the higher priority this component will be.
The matrix will be represented like this: the most used and easy to develop at the bottom left corner and the rarest and most difficult to develop at the top right corner.
Before starting, you may need to define what “simple” and “difficult” mean for developers. Feel free to quantify if that helps. For example, “simple” could be less than 2 days of work and has little ambiguity or complexity, and “difficult” requires 1 week of work, or has a high level of complexity. It’s up to you to define your definition of what is “simple” and “difficult”.
You can start by asking everyone to rate the simplicity and the frequency of each component by using their fingers as a scale and then, discussing if there are major discrepancies. Once you manage to find an understanding, place the component on the matrix so everyone can visualize it.
If you participate in this workshop in large numbers, you may want to start by making small groups fill the matrix on their own and then presenting the result to the other groups. Then, display every matrix next to each other and use a new matrix everyone will fill together. The goal is to agree on each component and place it on the final matrix, trying to understand the differences between each group.
At the end of the workshop, you should have components distributed in your P1, P2, and P3. Obviously, all the components in your P1 have to be developed first.
From my experience, people may tend to put everything in P1. Here are two suggestions for this issue:
- Ask people to dot vote on the top 3 or 5 highest priority components.
- Another option would be to define at the beginning that you can’t have more than 10 components in P1 when they’re filling the matrix.
Congratulations! You succeeded in organizing your components, and you now have a clear and shared vision of what you and your team need to work on. I strongly recommend you display your prioritized components in a Trello board, Notion, Jira, or whatever project management tool you use, and share it. It’s a backlog you just built, and it’s essential to give people visibility of this.
Next is making this visible to people. Share your roadmap in your documentation. For example, in zeroheight, you can embed a Trello and a lot of other tools to share your backlog/roadmap.
This workshop is excellent when you start with your design system, but you can run it regularly, and you probably should. It is well suited to Agile methodologies, but you can also have regular meetings with your team to check if the priorities are still the same and if you need to update this backlog.
Also, we made this Figjam with the prioritization matrix to get started. Feel free to use it!