Gathering feedback on your design system

Luke Murphy
Luke Murphy
  • Updated

Design systems are unique products in that they serve vastly different audiences at the same time. Each kind of user has different needs and experiences from the other. When we think about these user types, we can generally classify them as internal or external.

You may have heard of design systems described as products that serve products, this is what makes designing them more complex than a typical experience. Regardless, it is important to treat it like you would with anything else you're designing and follow standard processes, which includes gathering feedback at all stages from start to finish. I'll take you through some methods for attaining both qualitative and quantitative insights.

Know Your Stakeholders

The first step in building anything is identifying who you're building it for. As mentioned internal and external users are the two most common consumers of a design system.


Internal are folks who will be working with the design system to create features and products. Think designers, developers, product managers, and anyone involved in research & development. The design system serves their day-to-day needs so that they can do their jobs seamlessly.  If there's ever a case where they need to request a new component or additional support, they should know what the process looks like and how to move forward.

As your team and products scale, so will your design system naturally. It's important to get a pulse on how the teams are managing the current state of your design system to gain insight into what's working well and what can be improved. This will provide you with the knowledge on how to move things forward and what needs to be prioritized in your design system's roadmap. Given that design systems are living products, gathering feedback needs to be done on an ongoing basis that makes sense for where you are in your journey to scaling your design system.

Here are some methods you can use to gather feedback internally:


These can be tailored for specific roles such as product designers and engineers or sent as a general intake for everyone who interacts with the design system. Getting more granular helps to hone in on department-specific research, so it's encouraged to send out both general and detailed surveys. Some things you'd want to uncover can mostly be tied to processes and governance, which are extremely important in connecting the system to the teams that use it.

Create a slack channel

Having a place where anyone can drop in to ask questions or share resources helps to build a community around your design system. I've seen adoption rates increase and ambiguity decrease just from having open conversations anyone can partake in. Many are too afraid to ask questions or try to assume they know the answer in order not to waste anyone's time, but this helps to reduce these instances from happening. People can make suggestions or ask for help from peers or design system owners. Plus you never know how many design systems nerds are hidden in the shadows.

Focus groups

This is the beauty of having internal stakeholders, regardless if you're a B2B demo-only product or a full consumer-facing app, you will likely have folks in the building that are more than willing to participate in these kinds of feedback sessions. You can dive into specifics here, and one benefit is that participants empower one another in a group setting. Don't forget to compensate them even though they're your colleagues! Pizza and drinks usually does the trick.


Those who are interested can participate in a design system-focused hackathon that can help boost creativity in exploring new components or iterations. This can also give you a sense of what the team sees as lacking in the current state of your design system, but let's be real, hackathons are just fun.


These are kinds of users that are outside of your company and are typically your end-users. They consume your design system in the form of a greater context, think of it as your design system is the cogs that makes up the engine that they're using.

Chances are these folks aren't caught up in components or spacing values, they're just trying to get from A to B seamlessly in your app. It's not intuitive to ask these kinds of users design system-specific questions as they won't remember minor interactions or smaller elements so it's best to keep it high level. Uncovering design system-related issues involves digging into their broader experiences and then drilling down to uncover if they're experiencing issues related to poor planning, badly designed components, or lack of basic UX principles.

Here are some methods you can use to gather feedback externally:

Heatmaps and Recordings

Looking back on users navigating your app can show you every minor hiccup they encountered. The benefit here is that most tools (Hotjar is a great example) allow you to set up events so that you're not watching every single user interaction waiting for something to happen. Unmoderated sessions allow users to move freely and innately without feeling like a guineapig, while giving you a look into a common workflow.

Leveraging Customer Success and Support

When working with teams that interact with customers regularly you get the best of both worlds; the experiences of customers and the knowledge of someone that works within the internal team. You can let them know that you're looking for design system related insights and they can help point you in the direction to either the data or the right customers that have relevant experiences. Keep in mind that these people are not the customer and that you may still need to go to the source.

Monitoring bugs

I've seen a ton of bugs related to poorly built components, places where accessibility was forgotten, or general inconsistencies. No product is perfect and here is where you can catch slip-ups or low-hanging fruit. Ensure that engineers and product folks have design eyes on every relevant ticket so that you can triage appropriately.

Feedback sessions

As mentioned already, asking your end-users about your design system directly isn't the way to go. A useful method for leveraging interviews is to collaborate with another team working on a feature. Ask them for 5-10 minutes at the end of the session where you can focus on anything design system related. For example, say you have a team working on building version 2 of a chat feature. You can observe your team interviewing the user on the general usability, and afterward question them around things like accessibility, ease of use, delight, etc. It's best to have a loose template of questions so that you aren't scrambling for time.

There's No One Size Fits All

Design systems are tailor made for your product and company, so there isn't one deal workflow or process to follow. As any designer knows, gathering feedback is an integral way to figure out where anything you design can be made better for the folks you use it.

Was this article helpful?