Having the Right Discussion
Much of the discussion I see around Design Systems is technical. What’s the best tooling? Component change process? How do components impact design flats? What’s good component criteria? How do we handle CSS in components?
None of these are bad questions—they’re all foundational to the establishment of a well-functioning system. But there’s a lot of very important questions missing. Ones that have a far better chance of driving the success of your system.
Without thinking through the product aspects of your system, you can easily create a beautiful, technical tour de force that no one uses. Designers don’t know where to get the right icons. Hex values magically change across design flats. Developers add CSS to augment components. Every request becomes a new component prop. The system becomes bloated, unstable, and ultimately just as helpful as writing the custom code it was meant to replace.
A system no one uses isn’t a system at all.
Bringing Balance to Your System
Enter, product thinking for systems!
The three-legged stool concept is a prevalent way of looking at the necessary and interdependent relationships between a company’s Product, Design, and Development teams. A company without one of the legs will be out of balance and lack core insights. It won’t think of the whole picture clearly. Systems are no different. Surprise!
At The Scenery, we like to think of it like this:
Design—What does the system look like?
Development—How is the system built?
Product—How does the system work?
Most teams aren’t totally missing product thinking—it’s probably just being taken care of in some small way by other parts of the team, or a very thorough team member. How do you know if your system is missing anything big?
Not to fear—here’s a checklist of some of the product-oriented questions you should be asking of your system:
- How will people in the organization use it?
- How will we store and share system artifacts?
- How will we keep components up to date?
- How can we maintain a single source of truth?
- How can we share component status and guidelines?
- How big should the system be and what should it include?
- How will the system scale into the future?
- How is it shared with other teams across our organization?
If you have some answers to these questions, great! You’re on the right path. If not then I might suggest taking some time to ponder them. It might just save you a great deal of pain later on (trust us, we know from experience, and if our NDAs let us we’ll share those too).