Design system myths

How to finish an idea after blurting out “As if…”

…the homepage should be the optimized baseline reference of the system’s visual language at all times.

…if 100% of potential adopters aren’t using 100% of the systems features, it’s failing.

…the design system should be completely federated with no “central maintainers.”

…the design system should be wholly made by a central team with no outside contributions.

…the design system failed because it’s no longer supported (even though it created three years of serious efficiencies across a period of redesign)

…since there’s more than one design system at our company, we are broken and should immediately consolidate all of them.

…design systems for marketing orgs owning .com are totally the same and always as effective and maturely maintained as design systems for product orgs.

…our first order of business of our new design system should be automating Figma component production from React because didn’t Airbnb dabble in that four years ago?

…now that we have a design system, any component built by any team should be made, documented, and maintained there.

…the main reason we should be publish design system docs outside VPN for the world to see is because we exist so many other organizations will emulate us (and, well, altruistic sharing).

…our design system should include everything bootstrap has including a carousel we don’t use now but might need someday. (Credit: Jina Anne)

…the fastest way to scale the design system is through contributions. (Credit: Amy Hupe, Mark Steinruck)