Recently, we kicked off yet another design system engagement here at projekt202. We have been asked more and more to help large companies create their first output toward a more systematic approach to their software. It is a privilege to be an objective third party for these companies and help consult them on their way to making an artifact that helps unify all of their internal development teams. If you aren’t familiar with design systems, or if you are considering if it is appropriate consideration for your company, check back soon for a link to a talk about what they are and their benefits.
We have started adapting standards for kicking the engagements off, and gathering all the information we need upfront. So below are two of our preferred methods for getting started on a design system.
- Cut-Up Patterns in the Various Interfaces
Brad Frost calls it an Interface Inventory. Nathan Curtis calls it a Component Cut-Up Workshop. No matter the name, it is a great first step to getting the entire team involved and aligned. We have considered trying something that requires less paper, like taking screenshots, but what I will say about physical paper and tape is that the whole team seems to stay more engaged for the whole time, rather than falling into a distraction of checking emails or doing other work on their machines.
You should invite anyone with non-negligible time on the project. In addition, there is a great opportunity at the end of the workshop to pull in executive sponsors to walk through all the data captured on the walls.
It really visualizes the need for consistency and can absolutely drive home the value of the end goal.
Our last Design System engagement consisted of 12 software products, and required that we print out over 1,200 screenshots (so we also put a unique code on the back of each screen shot, like Nathan Curtis recommends, to be able to trace the cut-outs back to their source). It took us a little over five hours to complete the boards with 15 participants.
First, we separated into groups of three to four. Ahead of time, our team had prepared printouts and boards with the following categorized sections:
- Forms and Buttons
- Navigation and Components
- Data Viz and Tables
- Text and Imagery
Each team then spent the day focusing on one board and cutting out their relevant components based on their copies of the screenshots (yes, that meant four copies of each screenshot; sorry, rainforests). They then created subcategories on their board as needed. For example, the text section of the board ended up having subsections for:
- Headings and Titles
- Errors, Success and Info
- Text Links
The teams then simply divided up and starting passing out screenshots to cut up. Afterwards there were great discussions as the teams started to go through and remove any duplicates and began making new subcategories in each section.
If time allows, a great next step to seeing this information in one place would be to have the team begin to align on names for the components. Naming things is hard, and though I may call it a dropdown, you may call it a select input. This is a great time to start aligning on names.
You will notice we aren’t using the Atomic Design analogy here to group components. It is such a great tool with some phenomenal training materials. It may be right for you and worth exploring, especially if you plan to tackle creation of a design system without any outside assistance. We ultimately strayed from it because we had a similar problem that Alla Kholmatova describes, “We used to spend a long time debating whether something is a molecule or an organism. The debates weren’t always productive and we couldn’t afford to continue having them.” Like GE, we also found that opening up the taxonomy to be defined during the engagement gives us some great opportunities to be both tailored and innovative.
Also, there are instances in the past year when we have done engagements with companies that have over 700 pieces of software. Smaller versions of this workshop can be done to convince stakeholders of the need for a design system, or when you have to make adjustments considering the scale of the organizations software suite. We have also done cut-ups using pre-existing style guides in larger, more mature organizations to help us see where we are all currently defining guide rails within the context of our own siloed product teams.
2. Do a Component Checklist
Again, ours was adapted from the worksheet that Nathan Curtis put together. We went a little more granular than he did in his and we also had to create an accompanying keynote presentation to introduce all the components to the attendees. We found it is still best to show an example of what we mean, even though the people in this meeting are mostly delivery folks (FEDs and Designers), product owners, and perhaps brand/marketing.
While participants are being shown what we mean by each of the checkboxes, we asked them to:
- Cross out at least two sections you think are unnecessary or unimportant for your applications.
- Check up to 25 components you feel are most important to include in the first version of the design system.
- Add a star by up to five important components that we should expect to spend extra effort getting right.
The process of giving participants a budget really allows us to create a clearer hierarchy of needs for the system.
Pages 1 and 2 of our Component Checklist; get a version of it here
Matt, one of our designers, arranged the components by order of complexity, moving from left to right. You will notice as well that we have some items that are pre-checked. Pre-checked items are simply things we infer will be part of the system by default and don’t ask participants to waste one of their precious checkmarks on that object.
After they strenuously re-allocate and prioritize at the end of the component demos, we then flip over the worksheet to page 2.
On page 2, section 2, participants are encouraged to check off (separate from their budgeted checks from the front) a series of additional considerations and complexity needs.
Page 2, section 3 allows them to give us guidance on the site that will house all the components once they are developed.
And in section 4, we ask participants to identify and prioritize the products, even though we may know them and perhaps have seen demos at this point. The goal is to help identify candidates that may be ripe for immediate consumption of the design system. Lastly, we ask them to identify any and all people we should be communicating with along the way. These aren’t always stakeholders; it may be someone in brand, a designer whose input is imperative but that isn’t on the project, or even someone in sales that sells the software out as a service to others.
The output of the two workshops directly informs the backlog for the design system. The cut-up gives us visibility on how you are doing things today, the range in which your enterprise does things differently from a functionality perspective, and the level of complexity that the component needs to accommodate. The checklist allows us to weigh necessities next to aspirations, and gives us more of an idea around how much time we will need to devote to delivering each component. Both generate excitement about the engagement, and are a great step to getting the teams aligned on a common goal. It gives a clear trail of bread crumbs into what informed the backlog, gives us a basis for discussing time needed for each component, and even gives us insight into future releases of the system.