Design Systems: Types of Content You Need
Overview of survey results about design system content and structure
A couple of weeks ago we looked at different popular approaches to structure a design system. After that it was time to take a deeper look at the content and functionalities within a design system. Our goal was to find out which information and content types people find the most useful within a design system and how we should prioritize them.
Conducting the survey to gain insights
Therefore, we created a short survey and shared it in different channels (Slack, Linkedin, Twitter, etc.). Overall, we got 57 responses. That doesn’t seem a lot, but it’s enough to get some basic insights.
Our survey contained three main questions and an optional open question for suggestions. In this article we will look at the results of the main questions in detail to see what we can learn from our participants.
Q1: What is your role within your organization?
We started with a basic and simple question — but with a lot of impact. When we looked at the answers of the following questions for each role (i.e. only the answers of “UX Designer” or “FE Developers”) we were able to see different interests.
But for a real-life design system it is important to provide the most important information for different target groups at the same time. Therefore, we will only look at the aggregated results.
The majority of our answers came from UX Designers (42%), followed by UI Designer (21%) and FE Developer (15%). Others were for example Consultants, Product Designer or Scrum Masters.
Q2: The 3 most important items for the homepage
Here we asked our participants to choose up to three items that they would like to see on the homepage of a design system.
These were the items that most participants want to see on the first page of a design system:
- Information about how to use the Design System (65%)
- Downloads (56%)
- Last viewed components (38%)
- All components (38%)
The most selected answer was a little surprise for me personally (I didn’t expect it being so important). That’s why it’s good to ask your users and what they want and not to implement what you think they want.
And if you take a deeper look at the last two items, it probably makes sense to either show the “Last viewed” or “All components” — but not both at the same page, especially the more components you have.
And some of the lesser selected items could be shown as well, i.e. “Links to related systems” or “FAQ”, since they don’t necessarily take up a lot of space on the homepage.
The “Other” answers contained some good suggestions (summarized here):
- My favorite components (bookmarked components)
- New components
- Changes (updated components)
I’m sure if we would have put these items in our pre-defined list of this question, much more participants would have selected them. But as a UX Researcher, you should always be aware of this kind of effect.
Q3: The 4 most important items for a component detail page
At last we asked our participants to choose the four most important items that they would like to see on a component detail page — the heart of a design system.
The big winners of this question were “Live preview” (61%) and “States preview” (56%). Ideally, these two functions can be shown in the same component (not as separated ones). The “Description text” (49%) is also very important to explain what this component should be used for etc. Additionally, you should show all “Variations of the component” (45%) — if there any.
Then you should show some role specific content, such as “Code” (26%) or “Design information” (38%). Remember: Most of our participants neither were UI Designers nor FE Developers, but those 2 items still got that many votes.
And finally, it also seems to be a good idea to show some “Dos & Don’ts” (47%) for each component.
Conclusion
Of course, our survey is not the one and only truth about what users of design systems want. Your users might be very different, but it gives a good impression of some general preferences.
You can add other additional contents or functionalities to your design system . But you should ask your users before (or shortly after) you implemented these to validate your assumption).
Our next step will be setting up a prototype based on the findings of our survey and other research. After that we will be testing our tool with users to validate our assumptions.
