Building design freedom into design systems
A design system needs flexibility more than anything else.
That may seem like an obvious statement given that the prime reason for creating a design system is to efficiently and consistently render multiple differing products to solve multiple differing needs. Enabling products to spin up quickly with minimal UX and dev effort whilst maintaining experience, brand expression and engineering standards. Achieving this efficiency and consistency means inflexibility will be both necessary and advantageous, right?
We aim to create a fixed set of componentry that will be deployed time and again and is fit to solve any unforeseen user needs. Whilst also freeing design teams to concentrate creativity where it’s needed rather than reinventing the wheel time and again.
In designing a system, we aim to refine to the one perfect pattern for each component. The more considered a pattern becomes the more the ideal design is consolidated. For example, when factors such as priorities around accessibility, touch and responsive are added, the room for flexibility within finished components diminishes. The scope of ranges in size, colour and contrast narrows. This simultaneously refines the design and confines the scope for variety in deployment.
It’s also important to remember that designing components for a design system isn’t the same as design components for an individual product. We’re designing against anticipated rather than known user needs. Therefore the standards we set ourselves become much more important.
A good example of purifying but narrowing a design system is the question of whether to take in iOS and Android patterns or to render a single set of components across native and web. An argument for the latter is that the more consistency in UI the better. You could argue that users are familiar with patterns on their chosen devices but they were almost always web users first with an equal or greater familiarity with web patterns. They may also use multiple devices across their journey (their office laptop, mobile on their commute, tablet in front of the TV that evening). If that argument holds then the set of components a system uses is consolidated further.
So, all the ‘face value’ benefits of any design system then tend to point towards inflexibility. A design system really fulfils it’s purpose when asked to do its job at scale in multiple products for multiple audiences using the same fixed, inflexible design language. But in so doing a well consolidated system is in danger of creating a suite of products that look and feel identical. ‘The attack of the clones’ as a colleague once called it.
That said, the patterns we create are used throughout our products in any number of combinations and combine to answer myriad different user needs. That, by definition, is flexibility, right? And if your organisation only has a hand full of products doing similar things then that’s fine.
It’s when users journey through a number of your products and perhaps also switch products (and contexts) at points in their journeys that this attack of the clones becomes particularly acute. It’s easy to loose your way if products aren’t clearly delineated. We also know users may switch devices, physical environments and mind sets and also use unrelated products and perform unrelated tasks during their journey through our services.
Designers as well as users can also be effected. Perceived inflexibility can be a source of frustration for design teams as they try to design for different requirements from the task focused to the brand experience lead. The need to flex the user’s experience across a range of products can feel restricted.
For this reason, motivating teams to design using systems can sometimes be tough. After all they are being asked to design within a seemingly rigid construct. It may seem as if they are merely generating layouts and the room to design with freedom has already gone. Design teams may also think in rigid ways about a design system. For example, designers may ask questions like which type spec in the stack is the H1 and which the H2 rather than using the stack with freedom.
Getting design teams to see past this can be tricky. To overcome this, I use this analogy: A room full of people each have an identical, fixed set of Lego bricks (we all love Lego, right?) in a variety of shapes and sizes. Each set has a small proportion of bricks in your brands primary colour, larger proportions of each of the brands supporting colours and the largest proportion in a base colour. The group each make something out of their bricks and the variety of what they make will be vast. Not just ‘what’ they make but the scale and interpretation of it will differ wildly and each will have a character of its own. They each use the same ingredients but each according to their own ideas and stand point.
How does that translate into the creation and use of a design system? How can we harness all the benefits of consistency and efficiency that design systems offer whilst maintaining design flexibility?
For me the framing we use to hold components together is the key — at the atomic level of the design system. The inter related hierarchies of scale within elements such as the type stack, colour palette, use of space, etc. The Lego bricks are the components in a design system. How they come together is the framing.
These hierarchies, a type stack for example, will have small, medium and large levels and by default you might match large in one hierarchy to large in the others. But put that concept in terms of a human user’s experience and you could imagine a volume control that moves from quite to loud instead of from small to large. A quite experience or a loud one.
Imagine you have a volume control on each of these hierarchies that you can turn up and down according to the tone of the touch point you’re designing. As you turn the volume up, the visual language moves up the hierarchy from economical and concise to dynamic and extrovert. Turn up the volume and white space might open out and contrast might increase.
The key to flexibility is to allow design teams to independently move the volume control for each hierarchy independently to produce a variety of experience tones. Match loud in one hierarchy to quiet in another to produce contrast and drama, loud with loud for bold expressions and quiet with quiet for precision.
If we put forth a family of hierarchies for framing components and allow the flexibility for design teams to mix and match volume levels within each, we harness the flexibility to truly escape the attack of the clones.