As a design system designer, one of my main daily task is update our component library in Figma. However, depends on how big your company is and how many teams or project files are using your libraries, impact testing could become more and more important when you publish even a simple design update.
What I usually do is conduct an impact test using a mid- to high-fidelity prototype of my potential change. This involves recreating an overridden instance and observing if changes to the master product result in any unintended visual changes or UI bugs.
Why is it important?
Well, you may wonder, why should I do it rather than just update the master comps?
Let’s look at some examples.
Scenario I:
There is a requirement to update Input component in the library to have the default state change text color.
Design system (DS) designer update the color on global Input component and republish the library.
Project designer updates their file and anywhere default Input text color is preserved, the color update will show.
Image: color updates with minimum impact on instances.
Scenario II:
There is a structural change to optimize a global Hero Banner.
DS designer directly change the master Hero Banner, such as, remove image container and start to use the frame fill with an image instead.
Once this is republished, all project files’ overridden images will be gone and all designers using your Hero Banner previously in their files have to either keep skipping the Hero Banner update or update then manually re-apply all the Hero Banner images.
Images: structural changes that can break design file instances.
From the above two examples, you can see that without an impact test, it is a gamble for your DS consumers, esp. on more complex component updates. Of course Scenario II is a bit more extreme and in reality a DS designer may not make that kind of decision at all, but you get the gist.
Other than complexity of update, your team size also matters.
If you are a design team of one, congrats, because the risk is much lower. Take Scenario II as an example again, even though you realized that your design file now has unwanted changes, you can easily go back to the library file, revert the changes, then republish again to fix your broken designs in bulk.
But this won’t be as easy if you have a larger team. When multiple designers are consuming the library and not everyone oversees global component updates, it becomes tricker because the likelihood of confusion is higher. Furthermore, if your team is large enough to have a dedicated design system team using hybrid or democratized design system management models, the risk increases significantly without impact testing. This is because the DS designer and project designer are likely working in separate teams, and as a DS designer, you have less "immediate" feedback on the impacts after publishing. It could take much more effort to communicate the bug back to you, so much to an extend that people would rather stay with an obsolete comp or just detach. Ultimately, your designers’ priority is to deliver their project in time.
Either result is undesirable because when the design to development handoff occurs, using obsolete components in the design could create unnecessary gaps between the design and the production component code. Detached components add even more challenges, such as difficulty in identifying corresponding components in the implementation, as the name of the component may have changed in the detached version. Additionally, if external design agencies are involved in the projects, detached components can introduce more inconsistencies between designs, prolong the design timeline, and require more handoff markup, among other issues.
How to conduct it?
If you are buying my theory so far, the next question is: Karen, how do we conduct impact testing? And here is usually what I do.
Open library analytics (Organization plan only) or use an internal dashboard to identify which repositories or projects are using the components.
Recreate some examples from design files with high usage of the master component in the Figma library update file following your team’s versioning protocol.
Make the desired update on the master comp.
Observe if any unwanted visual changes occur in the copied instances.
If there are no unwanted changes, proceed with the updates as usual.
If there are unwanted changes, investigate what and why things changed on the instance. Then, try to wireframe alternative solutions that can achieve the same update without affecting existing instances. Some typical examples that can cause changes include:
Structural changes, such as adding or removing layers, regrouping or reordering layers.
Changes in auto layout hugging or filling.
Here you have all my tips on impact testing. Happy designing!
