Your Sketch library is not a design system

You can write words explaining how to properly use a toaster, draw pictures of toasters, and even create more efficient ways to draw pictures of toasters. But at the end of the day, if you don’t have a functioning toaster, all that effort is for naught.

In my design system workshops at design conferences, I’ll ask attendees where they are in their design system journey. Most hands go up when I ask them if their organization has a design system in place. However, when I ask to see them, a lot of attendees will show me a Sketch library or a style guide website with plenty of screenshots and prose, but lacking in living, breathing UI components.

This may sound obvious, but it’s important to understand that you can’t build working software out of screenshots and Sketch files. It’s not that static design tools and documentation aren’t important (they are!), but they can’t create functioning UI components that can be used to build real software applications. Static design files, pattern documentation, guidelines, and the rest of the all help tell the story of how your organization designs and builds products, but recognize that at the heart of any great design system is a reusable set of UI components that product teams can reach for to build actual software. 

So what’s a team to do to make sure you’re prioritizing building real functioning UI components?

• Make sure you have frontend designers on your design system team. If you don’t have any or enough, hire some. There are tons of frontend designers out there hankering to build clean, beautiful modular, reusable frontend code.
• Establish a pattern-driven, cross-disciplinary workflow that emphasizes getting into the browser early and iteration over frontend code. Rather than designers only staying within the comfortable walls of their static design tools, encourage pairing with developers to ensure the design vision makes its way into the actual code that will be deployed to real products.
• Early on in your design system initiative, discuss the methods you’ll use to deploy your UI components into product codebases, then quickly trial that workflow using a single component (“OK, here’s our design system’s button component, how do we get this to show up on our homepage?”)
• Understand the friction between creating functioning UI components that use specific technologies (such as React, Angular, Twig, et al) and create a design system that’s bigger than any one technology implementation.
• Make sure that the living, breathing patterns and code are displayed alongside any design documentation and screenshots in your style guide storefront.

Don’t get me wrong, I think it’s fantastic that tools like Sketch, InVision Studio, Adobe XD, Figma, and others are finally recognizing the importance of creating reusable UI components, and sharing those between team members. I’m even more excited about the many efforts to backfill living components into static design tools so designers can create screens that accurately represent how those screens will look in the browser. There is real value in using static design tools to work with a design system, but be sure to keep your eye on the prize: creating a beautiful, flexible, reusable collection of frontend components that can be used to build real software. Now get out there and build some toasters.

Update: if you’re hot and bothered over this post, you can read my follow up post here.