Your Sketch library is not a design system redux

I wrote a post where I talk about how a set of components living inside static design tools like Sketch isn’t itself a design system. Pardon my clickbait. Perhaps a better title would have been “Your Sketch library is not a(n entire) design system.”

No doubt tools like Sketch are super valuable, and having a set of reusable components inside them helps design teams establish thoughtful and consistent UIs. However, a Sketch library is just one piece of the design system puzzle. A design system also can include other puzzle pieces like:

  • Design principles
  • UX guidelines
  • Development guidelines
  • Coded UI components
  • Component guidelines, usage, and details
  • Page templates
  • User flows
  • Design tools
  • Dev tooling
  • Code repositories
  • Voice and tone guidelines
  • Implementation guides
  • Contribution processes
  • Team structure
  • Resources (internal and external)
  • Other guidelines/resources/tools/process

Collectively, those design system ingredients come together to tell the story of how your organization designs and builds products. Any one of those ingredients — even your living, breathing collection of UI components — can’t tell the whole story by itself. It’s the totality of those ingredients working together and influencing one another that leads to a successful design system.

Some people interpreted my post as “visual design doesn’t matter”. Of course visual design matters. And visual design tools are critical for exploring and establishing thoughtful, impactful, beautiful designs. But I’ll reiterate the point that ultimately all that static design work gets translated into code and implemented in working software.

In my talks I’ll ask the audience “how many designers have ever been ashamed to include a link to your project’s live site in your portfolio?” It’s good for a laugh, and plenty of hands go up.

It’s a shame to see a ton of hard work go into static designs only to see all that thinking, detail, and nuance get washed away when it’s translated into code. An architect’s research, drawings, and models are all critical to a building project’s success, but it’s at the construction site where the project comes to life. The architect and the builder need to closely collaborate and communicate in order to ensure the architect’s vision is manifested in the completed structure. And so it goes in software design. I’ve written at length about how important it is for designers and developers to collaborate and communicate in order to ensure the design team’s vision makes it way into finished products.

By prioritizing living UI components that have visual design, ux, accessibility, performance, and frontend best practices baked right into them, the working software that consumes those components will exhibit all those best practices. Hooray!