Usability testing of design system components and patterns

Question

This is my first post here, and what I am searching for has not been found yet, so I must be very innovative (jokes aside). I have gotten a mission at my current company from the C-level to test through all of the components and patterns of our design system. This is everything from input components, badges, tables, cards, panels, etc. Our design system is structured based on atomic design.

I am however not familiar with testing on specific components alone. I have always done it through scenarios and cases where we have whole layouts with components that will support our users in their work. Is there any way of performing smaller usability tests without specific cases?

Here's what I was thinking:

1. I could test each component against certain criteria;
2. I could perform 5-second tests (identify how each component is perceived after 5 seconds);
3. The break-it-method, where users and test participants try to find errors and problems in the functionality and usability;
4. Test participants will compare our components one by one with those of Material Design or Lightning;
5. Evaluate the components through CBUQ (Component-Based Usability Questionnaire);
6. Have small tasks for each component to see how easy they are to use and navigate, e.g. Task1 - enter data, Task2 - remove entered data, Task3 - Navigate using keyboard etc.

Are any of these ideas good? Are there any others? Please help! Any input is valuable! :)

Answer 1

Since design systems are the building blocks for building out the offering of an organization, a good test of whether they work well does not necessarily mean testing them individually with users.

1. For example, design components can help to bake accessibility into the platform. Thus one usability test of the design system would be to rate it and check if it is meeting the W3C guidelines: https://www.w3.org/standards/webdesign/

2. Another usability testing method is to go through tickets/ bugs in your company repo. and identify which bugs are related to component library/ design system and then carry that feedback back to the designer or make changes if you are the designer as well.

Answer 2

If you think about the equivalent in coding, where a snippet of code can be reviewed, a module of code can be unit tested, and a program can be integration tested, and finally a suite of applications can be system tested, it is possible to apply the same concept to UI design.

You should test a component for its atomicity (since it is based on Atomic Design), and perhaps for the fluency and usability of its micro-interactions (and micro-copy). Then you can test a component for its combination with other components (either as a molecule or as part of a design pattern).

Depending on the depth and breadth of your design system, you may choose to do this manually as a expert review/test, or you can apply some of the more advanced concepts of data-driven testing whereby you match the analytics available showing potential friction in a page or component's usage and try to break it down to where the issue might be.

I would however consider what the actual objective of this test/review is by clarifying it with the person who is asking for this, because in a typical continuous integration/continuous delivery way of working, you are always undergoing this process. Also, if you need to provide an output for this task, then you should make sure that what you report on meets the expectation.

Answer 3

The best way to test these components is where they are intended to be interacted with. Create tasks for testing participants to interact with for specific components. For example, to test your input components, have a