Creating a Research-Backed Design System

The challenge had been issued: we had less than one year to create a design system robust enough to use on our new university website — which we would be redesigning at the same time as building the design system.

Where to start? With research of course.

Auditing Components

The first major effort in both of these projects was auditing components. We looked at both websites within our own university and at components on peer institution’s websites and in existing component design systems.

For this exercise, I visited dozens of sites looking for repeated patterns and taking screenshots of examples. Examples I liked, examples I hated, examples that I thought might lead to good discussion.

Ultimately, I used these categories to organize my component audit.

Getting Initial Feedback From the Team

After collecting hundreds upon hundreds of screenshots, it was time to share with the team! I printed out all of the screenshots and glued them on dozens of large poster boards. Each component type had its own poster board (or section on a poster board) so we could easily compare different variations of similar components.

Then came the fun part! 

We reserved the largest conference room we had available and taped all of the poster boards to the wall. Every wall was covered in components!

Every web team member who wanted to participate (even those not on the project team) were invited to a two hour workshop. The first half of the time was spent as quiet “gallery time.” Each person was given a sheet of circular stickers and told they could place as many stickers as they wanted on components. Component variations that they really liked would get green circles, variations they hated got pink, and variations that were conversation-inspiring got yellow circles. By keeping this time dedicated to silent review, everyone was able to review components and solidify their own thoughts before entering into dialogue with the rest of the team.

After about an hour of people going around the room placing dots, we moved on to a moderated discussion about each component type. The project owner led conversations by going down my list of components one by one. She facilitated conversations about each type of component and we looked for themes of what we thought worked well and what we identified as issues to avoid when we were designing our own components. While the team discussed, I took down notes for the designers to reference later.

This was a very helpful way to get baseline feedback from the whole team. We all had different perspectives based on our past experience at the university and our specializations within the world of web. Through this exercise, our designers were able to pair the team’s feedback with the university’s brand guide to create the first versions of the components that would become our design system.

How to Conduct an Initial Component Review

1. Audit your existing site(s) and competitor sites for common components or patterns. Take screenshots of examples — both good and bad. These examples are to help spark discussion! Grouping examples into like components will also make these discussions easier as you will be comparing “apples to apples” as it were.
2. Display your component screenshots for review by your team. If your team is all in one physical space, you can print out screenshots and tape them to poster boards to hang up like we did. If you’re looking for a hybrid or remote friendly approach, using a tool like FigJam can accommodate the same type of activity. The wider range of experience you can invite, the better. For example, developers will be able to bring a different perspective based on implementation and accessibility. You may even find value in bringing in someone not on your team at all with no expertise in any area of web to see what resonates with them.
3. Silently have your team vote on good, bad and interesting components. Using physical or digital stickers, have each team member silently review components and vote. The silent part is important — it encourages independent thinking instead of letting a conversation be dominated by the loudest (or highest paid) voice in the room.
4. Discuss each component group with your team and take notes. Using a moderator, discuss each component group. Start with the examples that were marked as good and ask your team what they liked about those examples. For those that were marked as bad, ask your team what they disliked about those examples. If any were tagged as “interesting”, invite the person who tagged them what ideas that component variation sparked. Take vigorous notes as the team discusses each component and themes emerge.
5. Go over notes with your project’s design team. While they (hopefully) participated in the discussion, this will give them the opportunity to review all of the feedback again. With any luck, they will have gained insight as to what design direction to go in and be inspired to start brainstorming components.