The value of a design system is being able to build better products faster by making design reusable.
According to Katie Sylor-Miller, a senior software engineer on the design systems team at Etsy, a system can be understood as a combination of two concepts: components and standards.
In the Design Systems Handbook, she explains that component-based development reduces technical overhead by making code reusable, while standards govern the purpose, style, and usage of the components.
The Handbook is a comprehensive look at how to create a system that’s flexible, maintainable, stable, scalable, and successful in the long-term. This post is going to focus on just one of those characteristics: stability.
What is stability?
When talking about design systems, stability is primarily a technical issue.
It comes into play after you’ve established your standards for color, shape, type, icons, space, motion, and coded reusable components adhering to these standards.
Stability is knowing that when a developer drops one of these components into the context of a new page, application, or feature, it will appear as intended—and it won’t break the layout or cause an interface to otherwise go haywire.
Unfortunately, stability isn’t something you can achieve and cross off the to-do list. As the technologies driving front-ends change and, as your design system evolves, you’ll need to test the stability of your components at regular intervals.
A better way to test stability
Because platforms and interfaces iterate so quickly, regularly testing the stability of pages, applications, and features could easily be a full-time job. Fortunately, there’s a better way.
The documentation in your design system should include example code for the different states of each component, so test those fixtures instead of your complex UI.
Checking the stability of your design system components will narrow the scope of your testing and streamline the process. It not only will boost confidence in your UI, but also in your site-wide, front-end code.
“Stability is knowing that when a developer drops one of these components into the context of a new page, application, or feature, it will appear as intended”
This confidence will also help encourage adoption of the design system, because users know they can upgrade or change their UI without it breaking in unexpected ways.
Four types of stability testing
Generally speaking, there are four types of tests used to test the stability of design systems:
1. Unit testing
2. Functional testing
Functional testing runs examples of your code, or “fixtures,” in a virtual, “headless” browser, which are then tested by simulating user actions and checking the new state of the browser for the expected results. Functional testing frameworks include:
3. Visual regression testing
Visual regression testing helps catch unintended visual changes to component styles. Testing frameworks typically take screenshots of your fixtures both before and after changes. Then an algorithm compares them to detect visual differences. Open-source frameworks for this testing include:
Popular paid services include:
Check out Kevin Lamping’s resource Visual Regression Testing for additional information and options.
4. Automated accessibility testing
Automated accessibility testing ensures that your components are optimized for users with disabilities, slow Internet speeds, or old computers. Furthermore, good accessibility:
- Improves the experience for all users
- Is important for SEO
- Keeps your corganization from big-money lawsuits.
- Reduce the distance between your documentation and code. By co-locating documentation and code, it’s more likely that you’ll remember to update the documentation when a component changes.
- Give yourself reminders. Adding a pre-commit hook to your design system repository can remind contributors when their code adjustments don’t contain documentation updates.
- Automate your documentation. If and when you do decide to create a full-featured documentation website, use automation to simplify the process. Github lists a boatload of options.
and to avoid lawsuits. Options for running automated a11y audits are:
Find on the tools and processes that work best for your testing needs will take some doing. But it’s an investment that will pay dividends — saving you lots of time and anxiety over the long haul.
A few thoughts on documentation
In order to have up-to-date code examples for stability testing, it’s necessary that you have disciplined processes for maintaining documentation.
Katie Sylor-Miller goes into documentation at length in the Design System Handbook, but you can skim the takeaways below to determine whether or not you’re up to speed with her main recommendations.
It’s important to keep in mind that stability testing isn’t an all-or-nothing endeavor. In an ideal world, you’d have a rock-solid process and timeline for testing. But in the real world, it’s more likely that your testing regimen will always be evolving.
If you’re just getting started with stability testing, bite off a reasonable size chunk. Choose a single platform to try out and set some deadlines to keep things moving forward.
There’s much more detailed information in the Design Systems Handbook.