There are two distinct levels of usefulness of design systems.
As an idea: Static picture
Design ideation thrives on quick drawing tools. You start on paper and end in digital design tools like sketch and figma.
These tools are great for designing a design system. They are also great for building static prototypes. However they do little in the way of speeding up the delivery of real products. They also do not convey the full picture as we cover next.
True validation: Real components
Unless you get to design systems as components that you can use, there will be many unknowns overlooked by the design system.
Even considering a date input leaves open questions on how the keyboard is handled, validation is triggered, do out of range errors only popup on blur, do we prevent invalid keystrokes altogether, what happens on small screens etc. If this static design is your single source of truth, you will have multiple versions of the truth implemented by different teams.
This has led Frontend leaders to suggest that the term “Design System” is really something that should be used for something that comes with a real code implementation.
Beyond the fact that only an implementation can truly highlight the gaps in a design system, there are other reasons to consider an implementation vital to the definition of a design system. When dealing with external agencies, handing over static image assets is generally not considered a valid design system and will generally lead to code that will be difficult (if not impossible) to ingest back into the organisation. Finally having a working component system is a vital part of being considered in the general league of open design system collections.
If you enjoyed this story, leave a clap. Working with code components from a designer and product owner perspective hasn’t always been the easiest, I’m actively developing a tool to help, spread the word 🌹.
