What Should be Consistent?
For the past few months we have been working on our Canopy product design system or “style guide” or “component library” or “design language” or whatever the kids call it these days, but it has just never felt right.
The goal of any good design system thinger is consistency and it seems pretty easy to define:
an agreement, harmony, or compatibility, especially correspondence or uniformity among the parts of a complex thing.
We need a consistently designed and built product for sure, we need this uniformity in our designs and a particular harmony across every aspect of our app, but creating a design system artifact was where it started to feel not exactly good for us.
What we really needed was the create the beginnings of our own, Canopy GLUE team.
After sitting down with other designers and developers, it became clear that before we go to far down this wandering road we needed to define for ourselves what we actually needed to be consistent. We not only need to know what needs to be built but we also need to give everyone on our product and dev teams something to align on. Here’s what we came up with.
We need consistent…
- Brand
- Look and feels
- Behaviors
- Motion/animation
- Interactions
- Content management
- States/views
- Name/terminology/nomenclature
- API standards
- Accessibility
Bam! Now we have the real concepts we need to worry about instead of guessing as to what will be consistent. It’s super easy to get caught in the trap of consistency and begin to homogenize your app thinking that the same, repeatable UI components are the answer to the consistency problem.
Chasing UI components are not the answer, the answer is alignment of consistent values AND components. The only way to define those values and components is to break down what should be consistent.
