What is it?
Ongoing monitoring and maintenance of your component.
Why do we do it?
Without metrics in our System, we have no idea how it performs or how we can improve it.
We can better support product teams with necessary component improvements by having metrics.
Ensure product teams are using your component in the intended way.
Identify any gaps you may have missed in creating your component or documentation.
Most importantly, you can evolve and improve your component for users and build strong system adoption.
How do we do it?
Measuring quantitative and qualitative data is essential when looking at metrics. While Designers or Developers might be implementing your system and saying they like it, they might still be customising or detaching components. By measuring these instances and building a stronger understanding, you can improve your system and create better adoption.
Quantitative
Quantitative data is the what; it tells you exactly how people are using or not using your component. It’s essential to follow up any quantitive data with qualitative by speaking with product teams when numbers spike. This will give you valuable insight into the why.
It would be best to gather this data cross-platform to measure it against design and build.
While there are many things you can monitor, the two main ones are —
Insertions
How many teams/repos are using it, then how many times it’s being inserted into projects.
Watch for ongoing growth on this. If you find that it’s plateauing or there is low adoption, it’s worth investigating to understand why.
Detachments
This helps us understand if our base component isn’t performing as it needs for our teams.
If you can investigate what’s being changed to the component post-detaching, it’ll make it a lot easier to understand why teams aren’t using your component as intended so that you can re-review.
Qualitative
Qualitative data is the why; it explains why the component isn’t being used as intended.
Product teams will likely start making changes to components based on their metrics, whether conversion or UX-focused. This information is gold, as it gives direct end-user insights into your components’ performance. Gathering qualitative data allows you to get this information more freely, allowing you to make meaningful changes to your components.
You can gather this information through —
- Support requests
- In office hours, or through your channels or directly to your team members
- A quarterly survey
- Directly speaking, teams or team members.
Rinse and repeat
This entire design process is cyclical. Your insights should drive your objectives to continuous improvement and adoption.
Based on these insights, you can and should go back and redo the process or a smaller subset when required.
Handy links
Outcomes
- Stats on how your components are performing
- Adoption metrics and the ability to measure the performance of your System
- A healthy system that is constantly evolving with your product
