How We Conduct UX Testing of Design System Components

The drive to create a universal component often leads to its overcomplication. As a result, its use becomes less intuitive, and the work of designers and developers becomes less efficient. That’s why it’s important to find a balance between the versatility of a component and its simplicity.

Let’s take the header as an example. Its main function is navigation, but additional elements depend on user expectations and business requirements. In one product, for instance, the cart is accessed through the header, while in another, it’s accessed via a floating button. The header can also contain notifications, language switching, a dark mode toggle, text, and a logo that may appear on either side.

At first glance, it seems simple: you gather all the possible cases, create props, pass in instances, and convert layers to booleans—and you’ve got a component that functions like a Swiss army knife. Need to add a new feature? Just insert a new auto layout into the component, and it’s done. That’s how we approached things in the past.

How do we test components?

It’s simple: I assemble a team of designers at different levels and give them the task of building a specific case using a component that either raises doubts about its design or needs improvement.

There are no time limits, and the designers have full freedom of action. The most convenient way is to create a playground in Figma so everyone can work simultaneously

Key metrics I focus on:

1. Task completion speed — how quickly the task is fully completed.

2. Number of errors that could lead to the breakdown of the instance.

3. False sense of task completion: cases where a designer thinks they’ve solved the problem but actually made a mistake. This can indicate either designer inattention or component complexity. It’s crucial to ask questions here.

4. Instance swapping, if not provided by slots. I can explain more about slots if you’re interested.

5. What designers say during the process—this feedback is invaluable.

6. How often they ask for help and what specific settings they struggle with.

Here’s no need to moderate this kind of testing, but listening to each designer after they finish is essential. You’ll hear many valuable insights.

For example:

Three out of four designers noted that working with nested child elements is more convenient than toggling settings through a long list in the toolbar.

Three also pointed out the incorrect order of settings in the panel.

All designers agreed that adding a swap component simplifies work significantly but complicates layout settings, which takes too much time.

Comments like these highlight weak points and give a clear direction for future improvements.

Conclusion

1. We need to make changes to the swap component.

2. The header should be restructured, creating a basic framework where the header is divided into three sections. Situational components can be added to these sections, which will belong exclusively to the header and remain unpublished in the design system. This will give us a header builder.

And one more important point:

There’s no need to rush into fixing everything immediately. Remember that the design system is code, and every change affects development. It’s about finding balance: implement improvements in a way that doesn’t slow down other tasks. If a component can temporarily function without updates, delay them—but not for too long.