Over the years, I’ve worked with team leaders who want to test a design system by using it to build the design system documentation site. This is the act of dogfooding: using your own product or services. It’s practicing what you preach. While the stories of the origin for this term range from people actually eating dog food to prove its value to celebrities simply advocating for a product, extreme cases are often noteworthy.
One such story describes the product called SawStop. The product is meant to keep woodworkers from losing their fingers on table saws. The inventor was so confident in his product, he demonstrated the solution by putting his own finger in the path of a spinning saw blade. A story like this is a powerful method to sell a product or service. It shows how much a person should trust your product because you are using the product out in the open for everyone to see.
It’s this mentality that makes it seem that the best practice should be to use the pieces of your design system to help support everything in the ecosystem for an organization. After all, how different could the buttons be? The idea of a global design system that supports everyone could start inside our organizations, right?
A case against
Most digital products are productivity software, not reference sites. The chart below categorizes industries that have public design systems collected by The Design System Guide, Design Systems Directory, Design Systems One, and Design Systems Surf, counted once per organization and grouped by industry.
xychart-beta horizontal
title "Public design systems by industry"
x-axis ["Government", "Financial services", "Developer tools", "UI libraries", "Consumer internet", "Retail & e-commerce", "Travel & transport", "Education", "Media & entertainment", "Productivity & collaboration", "Marketing & sales", "Enterprise software", "Data & analytics", "Automotive", "Website building & CMS", "Telecommunications", "Energy & industrial", "HR & payroll", "Healthcare", "Agencies & IT services", "Real estate & construction", "Hardware & electronics", "Customer support", "Nonprofit", "Design tools", "Accounting & tax", "Sports & fitness", "Identity & security"]
y-axis "Organizations" 0 --> 41
bar [36, 34, 27, 26, 20, 18, 15, 15, 13, 12, 9, 9, 8, 8, 7, 7, 7, 6, 6, 6, 6, 5, 4, 4, 3, 3, 3, 1]
Of these industries, government is the least likely to be considered productivity. This isn’t a tongue-in-cheek jab. Government websites are often large webs of reference material and don’t normally have UI elements we’d see in the other industries. This makes government the best candidate for using the system to document the system.
While government occupies the largest bar of the graph above (36 examples, ~11%), the remaining industries combined in this sample overtake government by a significant margin (282 examples, ~89%). This is the point: the elements and patterns that make up an effective documentation site are not the same elements that make up a productivity site. This means our desire to use the system to document the system is often misplaced.
Even the categories above that are themselves UI libraries do not commonly consist of the elements expected to support documentation sites. UI libraries are often built to support productivity sites. Some of these libraries may have gone further to support their own documentation needs in the library, noticing the gaps in dogfooding their product. But the chart above shows what these libraries should be optimizing for: productivity experiences.
The concept of using the wrong tool or pattern for the job, even if it looks correct on the surface, I’ll coin as dogpoisoning: the opposite of dogfooding. If your design system is not equipped to support large navigational patterns of documentation, then you might be shoehorning your existing resource to fit an experience that it’s not meant for. The navigational hierarchy needed to support wading through components and tokens is not the same structure needed for a customer to review their digital footprint in a dashboard.
As a product
If you consider your design system a product, you should be developing the site to help the users it is designed for. Just like a real product designer! The users of the design system are most likely not the users of the end product. This outlines some of the challenges design system maintainers face in having two kinds of users: the people who need the pieces to build and the people who interact with the experiences made from those pieces. It’s easy to simplify this as having two groups of users, but each of those groups often has different needs.
This is why I often recommend existing documentation solutions over rolling your own from your design system. The products dedicated to helping organize your resources for your teams have been especially designed for this purpose. My system is a heavily modified Storybook for example. Only if you have the resources to maintain a custom documentation site separately from the organization’s design system itself should you consider going down this path. Even then, those resources may not exist forever.
It is hard enough to keep up with requests from your peers. Trying to make your system work in a way it wasn’t designed to work may be a larger headache that you can avoid by using products and services designed to solve the problem, instead of making your system fit.
A system of dogfood
So the question is, can we appropriately dogfood a design system? I believe the answer is yes, and it comes down to the work we should be doing.
A mature design system responds to the needs of the organization. If we create something meant for our teams to use, we should be involved with how it gets integrated with those teams. Dogfooding for design systems is taking the component you’ve built and going the extra mile to integrate it into the products where appropriate. The teams outside of the system don’t often have the time to veer off into migrations, so taking the time to launch what you’ve developed for the team in their product will ultimately make a better resource for everyone. This avoids the stone tablet mentality: throwing things over the fence and expecting adoption.
That is, if we should be building components ourselves at all.