Design Systems, Oversimplified: The When (5 of 5)
This is a 5-part series to explain the who, what, when, where, and why about design systems in its most simplest form. Once you understand the nuts and bolts of a design system, you’ll appreciate its deeper nuances more and might even want to build your own.
The Oversimplified When
Let’s take a look at what we’ve covered so far:
- Who: Developer and Designers (the dev product team)
- What: Standards
- Where: A design system management tool
- When: After you’ve got usable components (see below)
- Why: Faster Shipping
The “when” seems simple enough. When should you build a design system? Well, don’t build a design system if you haven’t done any user research or usability testing. You’ll only end up with a standardized mess of components, patterns, and guidelines. If you don’t have one yet, start with a brand style guide. Then continue investing into your simple system by adding the pieces previously discussed. The goal is transition from a style guide to a functioning UI that developers can literally copy and paste vs. looking at a beautiful printed, PDF or high-fidelity protoyped, version of the product. This also explains the “where”. Your design system will be in a design system management tool (like Storybook or Invision DSM) or an interface design tool that can house your libraries (like Figma or Sketch).
You’re probably wondering, “What about the how?! How do I implement a design system?” Well, that’s a little less simple and will probably require its own Oversimplified series. But for now, here’s where you’d start: Gain buy-in from your product team and stakeholders.
You’ll need more than this series to create a design system that’s custom-tailored for your existing and new products. The good news is you now have a reference point to start asking the right questions which will help you to dive deeper into the world of design systems. Happy building!
