This week there has been a lot of lively reflection on design systems. Jeremy summed it all up, Andrew added to it. I’m be a little late to the party.

The conclusion one could draw from these posts is a reflection on the feeling current design systems are dehumanising, that they create an environment of assembling web products rather than designing them, and that a poor system is a reflection of a poor culture. Last year, I talked about this in Zurich when I said that many of the adjectives used to describe the benefits of design systems were not the language of design, but that of manufacturing.

These problems are known. In fact, they’ve been known for a long time in other design systems. When I worked on a project for a museum a long time ago, we saw a lot of failure trying to introduce a prescriptive design system across environmental, print, and digital design. It was only when we backed up a little, provided less rules and more guidance, did it start to stick with designers and stakeholders. Why? Because it felt like their system instead of ours.

This problem exists in most design systems I’ve worked on. But it gets worse in systems which drive diverse product or brand portfolios. The more diverse the organisation, the more diverse the system needs to be. Conformity, streamlining, and efficiency will only get you so far before you hit the wall. Before you know it, the system will be blamed for drops in sales, lost leads, lost customers, lower profit, poor morale. In diverse organisations, the benefits of modern design systems can come at a price.

Over two years ago, when my colleagues and I set out to design the system that would drive the huge variety of websites, applications and utilities at EMBL, we quickly hit on that problem, and one that I’ve encountered elsewhere doing similar work: for a diverse set of users and use cases, their exposure to the system – and therefore the brand – should be a continuum from very overt ‘brand voice’ to the merest of whispers.

For broad applications of design systems, it’s this need that bangs heads with a binary approach of developing a single, unifying system. Not all design problems are created equal. In most cases, one design system does not fit all.

What does that mean?

Large scale brand systems do this all the time. Our relationship with brands are through their products or services. The story they tell us along the way underpins their values and the idea of their brand forms. Remember, we are not in control of what our brand means. It’s only customers, users, or audiences who are. They interpret the messages, interfaces, campaigns and products to form their own opinions. The brand dance begins.

EMBL, like other complex organisations, provides many services and research opportunities for the life sciences, teams, researchers, and many more people. Some of those are consumers, some collaborators, and some contributors. All of them have a different relationship with EMBL as a brand. I’ve seen this several times before: at Al Jazeera, the BBC, CERN, and UCL. Large, devolved organisations can benefit from design systems BUT only if the system can adapt to diverse needs and audiences.

Jeremy talks a lot about progressive enhancement. It’s an important concept for web development and one which we should consider in design as well. As I said in my talk in Zurich last year, Otl Aicher called for systems to have ‘Strict grammar to allow free, playful expression’. At EMBL, the strict grammar is applied to the barest of HTML and CSS patterns. We lock in typography, colour, behaviour, interaction design at the most basic level. Everything else is an enhancement related to a product, brand, or application. We’re drawing direct lines between how something looks and behaves to where it lives in the brand architecture and design system.

How do we do this? We make sure the basics work. Typically, that’s the hard work. It’s easy to fork a component and make it your own. It’s a lot harder to make that basic component better and build a community of contribution.

This is the approach we’ve tried at EMBL. In our case, this approach maps directly to the brand architecture we created which is based on a sort of devolved master brand.

–> Campaign: Campaign, event
–> Endorsed: Product, location, initiative, service
–> Master: Master brand

Each builds on the base, the master brand. It’s not entirely familial, because campaigns and events can look very different to the master or endorsed brands and for good reason. But in terms of our design system, the master brand sits on top of an abstracted generic layer. And it’s in this layer where the hard work happens.

–> Campaign/Event
–> Endorsed
–> Master
–> Abstract

The abstracted layer is where the patterns are codified. Where we establish the typographic relationships. Where the basic design tokens live. This is the strict grammar. The expression comes from enhancements at a component level. This where we can turn up the brand dial.

Let’s take the example of a masthead component. It starts out as the most basic of designed components living in the abstracted layer, what we call, the ‘Life sciences framework’. At this stage, for us, there is no brand present. It’s as vanilla as it could be. Black text, blue links, basic layout.

At this level, the masthead could be further enhanced by a few options at a component level. Maybe it could have a compressed or expanded view or something similar. Placing this component in a different brand environment – in our case the EMBL brand environment – it now looks different. The core attributes remain, but the design is enhanced. The same abstracted design pattern as before but enhanced to fit in its brand context. We could enhance that further many times with subtle variations, all the while turning up the brand dial.

Let’s say we have a campaign running for a month and need to build a landing page. We need the masthead component, but not in the master brand form. So, we enhance further to a campaign level. We could think of all of this as CSS Zen Garden but at a micro level. We keep the basic functionality and enhance the style and behaviour to adapt to the component’s new environment for different use cases and audiences.

Here’s how our layers could look:

–> CAMPAIGN - Campaign masthead component: EMBL exception
–> MASTER ENHANCED - Enhanced EMBL masthead component: EMBL framework
–> MASTER - EMBL masthead component: EMBL framework
–> ABSTRACT ENHANCED - Enhanced masthead component: Life sciences framework
–> ABSTRACT - Masthead component: Life sciences framework

This approach has a few added benefits:

  1. We’re linking our design system, via the components and content, to our brand architecture and nomenclature. Words matter. The more we repeat this, the more the organisation begins to understand how the brand architecture is reflected in our design architecture.
  2. By focussing on the experience of the base component, and mapping on visual differences, means we can more easily pivot and apply new styles and directions in the future without forking or harming the foundational component.
  3. We know where the edges are. Each component has a bunch of design variables and foundational elements. Things that can change, and things that shouldn’t. By understanding these we embed guard rails in the component so people can make some quick, good design decisions.
  4. We can also think of these layers in terms of time. Pace layering design systems is something I’ve been thinking about for a while. The base, foundational elements are slow and have all the power. The upper most layers are transient and fashionable.
  5. This helps us prioritise. We spend time on the slower, more powerful layers so it helps us move faster later.

But also a few drawbacks:

  1. It’s a lot more work. Keeping track of component variations, states and probabilities can quickly tie your code into knots. What looks very easy in a Sketch file can turn into CSS soup.
  2. And with that work comes added maintenance and support.
  3. Also documentation is an issue. Whilst designers and developers may be comfortable with the idea of components living on a progressively enhanced design continuum, content creators and stakeholders will be less so. That requires more coaching.
  4. One question that keeps coming up is ‘are we abstracting too early?’, along with ‘do we need this?’, ‘is this too complicated?’. Sometimes the answer to all three of those questions is ‘yes’, and we need to be mindful of introducing freedom and flexibility, even if we scaffold the experience. Every point of deviation from the system is a potential point of degradation of the experience, brand or otherwise.

Design patterns are useful things. Conventions and chunks of content and form are used in designed objects the world over. Things get tricky when they get tied directly to code and are presented as a single, immutable truth. A single point in a brand continuum.

I’m coming around to the idea that the design that lives outside of a system is where the humanity is. The tiny differences. The happy accidents. The snowflakes. It’s this we should be encouraging.