The Fast and Slow of Design
Move fast, break things. Fail forward. Fail fast. Always be shipping.
These idioms are all around us in the tech industry. Establishing themselves in small, garage-band startups, they are now deeply entrenched in working cultures of even the most traditional publicly listed companies.
Working fast is alluring for every board-room executive. Especially if, over the course of months, speed (and failure) results in faster product releases, more revenue, bigger and faster growth. Capitalism, right? However, I'm of the opinion that speed – and those arbitrary deadlines – create an unhealthy balance that can eventually lead to the demise of the company. Moving fast and breaking things tends to be at the expense of paying attention to slower, subtle, more stable, 'boring' aspects of a system.
So what happens when we focus on the entire system? How can we create sustainable, balanced design systems that serve our companies and products for the long term?
The Fast and Slow
My family and I moved into our current house about six years ago. At the time, we were living in a modern semi-detached house that we'd spent about ten years making our own. We knew we wanted to move into something older and a bit more characterful. A place we could grow old in. After a year or so, we happened upon the house; a charming farm workers cottage on the edge of town. Having a look around it the next day, we instantly fell for it. It was perfect. Sort of. Just like all old houses, we knew there was some work to do.
Amongst many, many things that required some attention this fireplace was one of them. The house was cold – yes, the central heating was one of those things requiring work – so we needed fires in the winter. Fitting new log burning stoves required enlarging the fireplaces, and in the case of this one, opening up ones that had been blocked up.
The day before this photograph was taken, Dai – our Welsh stonemason – called me at work and asked me not to come home for a while. That sounded ominous. In their wisdom, the builders who had blocked this chimney had thrown the rubble down it. He managed to dislodge about three tonnes of rubble that came down in a small explosion in our living room. We could taste the resultant dust for weeks. This is just one example, over the past six years, where this house has surprised us. When you start peeling back the layers, you start to see what a building is made from. What its story is.
In his book, 'How Buildings Learn', Stewart Brand has a useful concept to explain this.
He describes a building having layers that age at different speeds. These 'shearing layers' are very apparent in my house!
In his follow-up book, The Clock of the Long Now, he expands this concept and applies it to our world.
On the top layer there is rapid change. On the bottom, change happens at a glacial pace. It's this combination of everything, from seconds at the top, to millennia at the bottom, that give resilience to the system. As he says in this talk:
'The fast parts learn, the slow parts remember'
A key concept to this is that each layer has to respect the pace of another. There are examples of when this has gone wrong in the past in society:
Regime change in Iraq – removal of governance in a system – has resulted in change to all layers. The system collapsed and we are still feeling the effects of this today and into the foreseeable future.
In 2008, as so wonderfully documented in the film 'The Big Short', the housing market in the US failed. The cause was complex, but central to it was the failure of the CDO – the not-so-wonderfully-titled 'Collateralized debt obligation' – and the sub-prime mortgage market. The collapse of both put modern global civilisation on the brink. A decade later, we look set to make the same mistake.
The part of this diagram I like the most is that it forces you to think in time instead of other ways of organising things. As this relates to design, time – or rather longevity – is not generally a consideration. Like much of our lives, modern design gravitates to those upper layers of commerce and fashion. We get paid well to make desirable things that people consume. Once we're done with one thing, we move onto the next.
But how can we apply this thinking to design? How can structure design organisations and systems based on time rather than resources or products?
Why is this hard?
I'm currently just a few months into the job, but already it's clear EMBL (the European Molecular Biology Laboratory) is a special place. Like CERN, and other organisations that provide infrastructure for basic research, the currency of EMBL is science. Not profit. Or shareholder value. But by providing the very best environment for groundbreaking scientific research to happen. And it's precisely this reason that makes design in places like EMBL challenging.
Perched on a hill outside Heidelberg in Germany is the headquarters of EMBL. Like its other campuses in Barcelona, Rome, Grenoble, Cambridge, and Hamburg, the Heidelberg campus is a small gathering of laboratories and supporting buildings. It feels more like a university than a multinational organisation; full of students and young scientists embarking on their career. It's a place of energy.
In about 40 years, the demand for data storage will outstrip the supply of silicon. Our need to store data will continue to increase, but we will need to focus the usage of silicon on more critical things such as computer chips. To address this, scientists have been working for a little while to encode digital data in DNA. Turns out there's quite a bit of space available but at the moment it's costly. A few years ago it cost about $13000 per megabyte to encode. Like all things, the price comes down as the technology and methods improve, but even this is palatable where long term storage is considered.
Recently, scientists at ETH Zurich did a study into the stability of DNA data storage. The results showed incredible stability. Data would be stable for ~2000 years at 10C and over a 1,000,000 years at -18C. And the additional benefit of DNA is it's really, really tiny. Last year a new method at Columbia University estimated that DNA has a 215 petabyte: 1 gram storage ratio.
The latest instalment on this 40 year deadline, was last year Nick Goldman of EMBL-EBI encoded an encrypted bitcoin into some DNA and gave away samples at a conference with a simple challenge to the attendees: decode it and you can keep it. Recently, someone did just that..
Why am I telling you all of this? Basic scientific research spans the pace layers. From fast. To slow. The field of scientific research is structured to accommodate this; except for senior staff and scientific research group leaders, EMBL employees are not at EMBL very long. The result is a startup-like culture working fast on problems that span decades. Since working with scientific institutions like CERN, now EMBL, it's also the answer to the question I ask myself almost every day: 'Why is this hard?', and why structuring design systems by time may be more useful.
What's in a system
If we look at the constituent parts of a design system, we might see something like this list:
- Data entry
- Data display
- Markup and style
- Voice and tone
That's quite a lot. And, if you look at a lot of existing design systems and style guides, this stuff tends to be categorised into large groups such as 'Brand', 'Marketing', or 'Product'.
But if you look at a system more holistically, there are many other things:
These large, holistically focussed groups can be layered according to their rate of change:
Remember, rate of change at the top is rapid, at the bottom, things should barely ever change. If we start to map on top of this our items from our lists...
Let's look at each one in turn. Starting at the top with 'Tooling'
Tooling is fashionable. The way we design, build, deploy and update digital products changes as fast as users consume them. This will probably always be the case, and, you know what, that's ok if your system is built to accommodate it. For me, that means ensuring that the means by which the system is distributed and deployed is in step with your organisation's way of doing things. The moment these two things don't match, tooling becomes an issue.
Design patterns are closely linked to product design and user behaviour. As these things change, patterns need to change too. In this layer I'd include the look and feel of design patterns in addition to their code. Admittedly, there is somewhat of a grey area there with tooling – many design patterns are linked to methods of deployment and distribution. According to this model, that isn't a great idea. When tooling – which changes at a different rate – is combined with patterns, it leads to what Stewart Brand calls 'layer turbulence' and often the answer to my question: 'why is this painful?'.
The people in a system are seldom acknowledged as a component of a system. Instead, they are people who act on a system. I think this is a mistake. People take work. In most organisations, the people of a system represent continuity and sometimes the only thing stopping it from being rebuilt and redesigned from external HIPPO (Highest Paid Person's Opinion) influence. How I'd define people would be any real person interacting with the system; the team building it, stakeholders, open source community etc.
As we move down the layers, things become more stable. There are many things in documentation that require stability. Change needs to be more visible and apparent, such as repo commit messages, or 'last updated' footers on website content. Documentation could also include design principles, brand guidelines, or editorial guidelines. For many systems, this represents the lowest layer of stability, but I think we need to go further.
Systems need governance. How else is change managed? A key thing to note here is that the work of governance is managed at a higher level in 'People' as it's faster. This layer is concerned with the process and methods of governance; how a system is governed rather than the act of governance.
Like the foundations of a building, the foundations of a design system should not change. Examples that I would consider foundational are things like the URL of your design system; elements of the brand; the repository; the design system and brand nomenclature.
With all that in mind, let's have a look at those idioms again:
Move fast, break things. Fail forward. Fail fast. Always be shipping.
These phrases drag us to the top layer and keep us there. They prioritise speed over stability. I'm interested in creating sustainable systems with longevity, so I don't think it's an appropriate way of thinking. What might be more appropriate, but probably more boring, is:
Structure for pace. Move at the appropriate speed.
But I guess that doesn't sound as cool.
Note: This article is a rough transcript of the talk I gave at SmashingConf in San Francisco in April 2018.
Design systems and Postel’s law
Postel’s law – or the Robustness principle - states:
Be conservative in what you do, be liberal in what you accept from others (often reworded as “Be conservative in what you send, be liberal in what you accept”). From Wikipedia
Jon Postel was talking about TCP and how implementations should follow this principle. Putting TCP and networks to one side for a minute, you can see how this principle can apply to many systems where there is input and output. Specifically, design systems.
The basic premise of Postel’s law is that what comes into a system can, and invariably, is a mess. Non-Compliant, delivered in a weird way, unconventional.
When thinking about this, I recall some work I did years ago on a ticketing system for a help desk. The single biggest hurdle, in order for the system to be successful was it had to be liberal in what it accepted. Tickets needed to be created from email, phone applications, web applications, voice recognition etc. The hardest part was getting stuff into the system. Only then could a single ticket be created - from various sources, in varying quality of data – in a single useable ticket for use with the large team.
Be liberal in what you accept (from emails, apps, voice, websites) and conservative with what you do (creating a single, well-defined ticket).
I see this same principle being applied to design systems.
Collaborating across an organisation to create a meaningful, impactful design system means you have to be liberal in what you accept from others into the system. Be it code, thoughts, design work, content, or criticism. That input can also come from many different teams, strategy, executives, products, people. You see, it’s a big mess! And the only way, really, to work with a system like this is to be open to all input from wherever it comes, in whatever form takes. To be liberal with what you accept.
This approach does a few things:
- Makes people feel involved, consulted, and listened to. This a good thing.
- Exposes the system to the dirtiest, out-of-date, horrendous use-cases possible. This is also a good thing. Mostly these use-cases are ignored because they are horrible.
- Helps turn a system that is owned, to one that is shared.
- Helps identify themes across an organisation.
- Helps the design system core team operate at a holistic level.
Policing a design system never works in my experience. It never works because people don’t like rigid systems, being told what to do, and will straight up do the opposite. Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.
So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable. It needs to turn the messiness of a liberal input into a defined, purposeful output that people can easily slot into their workflow and use.
Once again, I find myself in a place banging heads with how work happens rather than what the work is. Someone once said to me that ‘design principles are the stars to sail our ship by’. I’m certainly going to be using Postel’s law to sail my particular ship in the months and years ahead.
Design systems in difficult places
This is Manchester. I grew up on the outskirts of Manchester. I have memories like this picture. Black and white. Snowing. Wildlings. It’s grim north of the wall.
But what this picture doesn’t show is the rich visual culture that Manchester had throughout the 80’s and 90’s. All that rain and grim weather makes people creative. It’s no accident most of the best music in the world came from the North West of England.
This is Tony Wilson. Tony was a journalist in Manchester, appearing on Look North West as a roving reporter. I have lasting memories of his wind-swept hair, stood in a gaudy cagoule talking to a farmer on some moor somewhere. He was on telly every evening at teatime when Look North West was an ‘appointment to view’ (as they call it in telly-land) across the region. But as well as being a journalist, Tony was also involved in Factory Records, founding it with Alan Erasmus in 1978. Factory went on to define an era of music in the 80’s and 90’s signing bands such as Joy Division, New Order, and the Happy Mondays. I’m not a big fan of the music, but of the graphic design produced at the time.
This work was everywhere in Manchester. On every street corner. In every record shop. In every music shop. There were posters, fliers, newspapers, TV adverts. The hum of the city became entwined with the output of Factory. And, without really noticing it, started to take on this DNA. It became Manchester’s design system. It’s visual life-blood.
The challenge with any design system is they normally don’t work, don’t get adopted, don’t grow or get used if they are imposed top-down without an awful lot of consultation. Like any language, they have to be adopted by the masses through continued daily use. The tricky thing for us designers is that is rarely how we’re engaged to create these things.
Normally the brief goes something like this:
We’d like you to design us a living style guide (replace with ‘pattern library’, ‘design language’, ‘brand guidelines’, ‘identity’). We’ll then use that to provide consistency to our entire product range – of which we’d like you to help us.
Now, this works in some circumstances if control is maintained by a marketing department or brand manager. But, it’s my experience, that unless design is valued then control is absent. Nobody has the authority to own this. They just have some budget and see a problem that needs addressing, but do not have the money, authority or organisational environment to make this work succeed. So what do you do then?
Well, you just do it anyway. But over the years – taking some inspiration from my home town – I have a few principles…
1. Repeat yourself consistently
Let’s get one thing out of the way first. Meetings are not bullshit. Suggesting that is actually bullshit. Meetings – where people talk and resolve things, plan, decide – are probably the most important thing you can do to get a design system off the ground in a difficult place.
Remember, you have no authority. Your client, or stakeholder, has no authority. You’re doing this for better, holistic good of an organisation that almost everybody there cannot see. So you have to persuade, provide insight and data, and in my experience you have to do it over and over and over again.
2. Establish a mandate
Over the last 10 years i’ve worked on quite a few, large scale design systems. In all of them, there was a distributed technical system that had grown organically. A few CMS’s here and there. PHP, .net, etc etc. It’s not like you could create a bunch of HTML and it would work everywhere. Far, far from it.
And then, editorially, many of the departments of these organisations were creating content without any joined up thinking. It was common for them to have their own budgets to create their own mini projects (yes, with their own CMS) and they’d hire a little design firm to do it.
From a branding perspective, there was normally a small, internal, over-worked branding team who were constantly and consistently putting out fires that the organisational structure creates. Everywhere you look people were degrading the brand.
In my experience, this is the norm. How do you create a design systems that not only gets adopted, but thrives, in this environment? You have to establish a mandate. An editorial, technical and brand mandate. A troika of disciplines working together to establish order.
3. Be where the creator is
In the case of Manchester, the work of Factory was in front of every young designers eyes. Everybody looked up to the work of Peter Saville and created work to replicate it. So, on every street corner, the inspired work appeared. All of a sudden, Manchester’s visual DNA expanded beyond the world of record shops and club night posters, and made it into plumbing brochures, margarine packaging and pub fliers. The bread and butter for jobbing designers in the North West.
This was because the work was accessible and in the places designers where looking for inspiration.
I like to apply the same thinking for the adoption of a design system: be where the creator is. A few examples:
- Provide ready-made templates for design tools. Not just for in-house designers, but so external designers (you know, hired by the small department trying to use their budget before the end of the year) can use them too.
- Provide tools to make things. If you’re building digital things, provide a UI library and maybe prototyping and deployment tools that make consistency easier.
- Be where they are. If an organisation uses Sharepoint, or some other God-awful intranet software, then put your tools where they are and don’t try to force other documentation if it won’t fit.
How do you know you’ve been successful?
I get asked this a lot. How do you know if your work will stick? You’ve spent a year designing a new design system. How do you know it will really hold? I’ve learnt to look out for a few indicators…
- The design system becomes how design is talked about in an organisation. It becomes a shared vocabulary. And not just by other designers, but by management and all levels of an organisation.
- The quality of design (and editorial and technical) becomes self-policing. It’s no longer the responsibility of just one person or team, but ownership becomes distributed. People start to care.
- Design and KPIs. Clear lines get drawn between good design and measurable outcomes.
- Lagging and Leading indicators become more apparent. So you can better predict how those indicators affect quality, brand, product roadmap. In this case, design can help indicate the health of an organisation.
What’s Manchester got to do with all of this?
You may well ask. When I was growing up in Manchester, I never really took much notice of the graphic design around me. It was only when I left – or years later – when I decided to become a designer that this stuff leaked out of me. It was stored somewhere deep inside my brain and with it, I like to think, I absorbed some of that taste. By being part of the Zeitgeist.
What you do now for your client or in-house will have an effect that will be felt years later. You will change how people think about design. Change their relationship with the company they work for. All by consistently using Helvetica, or something. It’s not that hard. Is it?