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.

There's amazing work going on at EMBL. This story recently caught my attention.

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:

• Governance
• Patterns
• Tokens
• Logo
• Typography
• Colours
• Icons
• Content
• Tooling
• Documentation
• People
• Committees
• Infrastructure
• Animation
• Data entry
• Data display
• Layout
• Localisation
• Markup and style
• Messaging
• Search
• Navigation
• Voice and tone
• Accessibility
• Grid
• Image

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

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.

Patterns

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?'.

People

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.

Documentation

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.

Governance

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.

Foundations

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.

This is a post in defence of process. Yes, I know what you're thinking: 'urgh, process is a thing put in place to make up for mediocre teams'; or 'prioritise discussion over documentation'; or 'I get enough red tape in other parts of my life'. You know the response. You've probably said it as many times as I have.

Conversations are cheap

I am the first person in the room to defend the delights of working in a lightweight, agile (lowercase 'a') way. You make stuff faster, generally better, and you build team or product momentum. The real benefits I see are people benefits: a closer-knit team; shared understanding; less things on fire. The wholesale shift to this way of working – outside of slow-rotting corporations, that is – has many benefits. But the cultural distain of the 'P word' is not one them. Process has a place.

The main issue I see time and time again is that conversations are low effort. Not only that, but certain ways of working prioritise them over slower, reflective, considered decision-making. I use one method that works to counter-act this.

'Write it down'

Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That's it. Because writing is high effort. Making sentences is the easy bit, it's the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say 'oh, that thing I asked you to do, I've had a think and it's fine, we don't need to do it'.

This little method isn't about doing less. Well, actually it is. It's about doing less important things instead of important things. It's not about being obstructive. I certainly don't ask someone 'why?' five times (which is a shortcut to being called a smart-arse in my experience). This is about a light-touch way of asking someone to slow down.

Time for reflection

In the UK, medical doctors are required to 'reflect on an aspect of their work' every month. This is time that is monitored as part of their self-development and self-improvement. Doctors are amongst the busiest, pressured people I know and if this wasn't mandated by the British Medical Council, then I'm pretty sure it just wouldn't happen. They have to make time. And we should, too.

We're all running at 100mph. Making things faster and faster. In my own experience, time reflecting on work tends towards sitting in front of screen – like I am now – thinking about the next thing on my todo list, or beating myself up about the latest ball I've dropped. How does that Elbow song go? 'Cramming commitments like cats in a sack'

These days, I welcome being asked to 'write it down'. It gives me permission to take a breath. To pause and reflect on what I'm asking. I'm convinced my heart rate drops a little. You see, in some environments this would be called 'process', or 'red tape'. 'Being asked to write something down is a blocker to my flow'. Those kinds of responses miss the mark. When being asked to 'write something down' it's really shorthand for 'take some time and think about what you're asking'.

Next time someone asks you to do something, try it. I bet 3 times out of 10, they say 'oh it doesn't matter'. You'll have that time back. They'll be a little wiser and have a lower heart rate.

As long as I've been working with editorial teams a content pipeline has been a problem. Knowing the state of a story, its context to those around it, and who has done what, when, is vital in managing a content throughput. Generally, this figures itself out in a busy, noisy, physical environment. But, the more remote a team becomes, the more challenging it is to communicate on the state of stories.

When I joined EMBL a couple of months ago, this was a problem we had. Content status was done weekly, but a continually available overview by the entire team was not. Nor was there a tool or process to push stories around. As I said, my experience is this is not unique to EMBL. Almost every editorial team I've worked with struggles with this.

Dan and I got our heads together and worked on a process that would fit with the existing team and tools. The team here use Trello extensively for planning, so we started there.

The one board to rule them all

It was important we didn't interfere with existing processes using Trello. The team all use Trello in different, interesting ways to collaborate and manage their content; from ideas to final copy. We needed to integrate with that best we could. This is what we settled on:

1. A Pre-production Trello Board

Once a story is ready to go into the workflow. Meaning it is agreed, planned, assigned to a priority etc, then it is added to the pre-production Trello board. This board is organised by story type: features, updates, press releases. Once a story is complete and ready to publish, it is moved into a column 'Move to Production'. Zapier then copies the card, with everything in it, over to the Production board. Once that's done, it moves it to an archive list.

2. A Production Trello Board

The production board is not focussed on collaboration or story type, but arranged as a pipeline of approvals, sign-offs, edits and publishing. Once a story moves through these linear stages then published, Zapier goes in again and moves the card entirely over to the archive board.

Some notes about Zapier

I've used Zapier a bunch of times over the years but never really had the time or focus to work on automation that fits within a team environment. It's great, but it requires some wrangling to work if you move beyond the default app integrations.

Zapier integrates really well with Trello. There are a whole bunch of predefined tasks that you can chain together to do stuff with your Trello boards. For the most part, the challenging thing is working out the sequencing of what you want to do. For our 'move to production' task, this is what we ended up with:

1. Find the Pre-production Trello board
2. Find a list on that board called 'Move to Production'
3. Find cards moved into that list (this is the trigger to run the whole zap)
4. Get information about the card and move it to Production. (In fact, here, I didn't move it but copied it. I wanted a safe-guard in the system so that if something went wrong, there would be a backup)
5. Once it's moved, confirm by then moving the card into the archive list.
6. Once all that's done, check the card has actually moved.
7. Then post to Slack and let everyone know.

The only stage out of all of these that is out of the ordinary is the 'copy' task (number 4). To complete that little task we need to use webhooks in Zapier to POST directly using the Trello api. After a bit of Twitter help Hat-ip @sprawsm, we figured it out. It's probably easier if I just show you in Zapier what the important bits are:

You can see from this image that the web hook field has a bunch of form fields. I'll concentrate on the important ones:

URL

When we create a web hook, we need a URL for the api endpoint. For Trello, this is the one we need: https://api.trello.com/1/cards/key=(your key here)&token=(your token here). You can get the key and token from your Trello settings.

Payload type

Set this as JSON

Data

These are the fields of data you are going to pass to Trello via the api. The content of these fields will be populated from the fields earlier in the Zap. It's important each of these field titles is copied exactly for the task to run. Let's go through each in turn:

1. 'name'. This needs to map to the title of the card to move.
2. 'idCardSource'. This is the ID of the card.
3. 'due'. This is the due date for the card if it has one
4. 'KeepFromSource'. This one is important. It will make sure when the card is copied from one board to another that all the cards contents are retained.
5. 'idList'. This is the ID of the list we want to move the card to.

Wrap request in an array

No

Unflatten

Yes

And that's it. These are all the changes you need to make below the data fields. When it is run, this little task will take the values from the other tasks before it and populate the data fields, it will then post that to the Trello api, and Trello will copy the card into the Backlog list on the production board.

Broader use

After using this for a little while, I realised I'd really like to use this workflow for managing my simple, personal Trello backlog. I have a pretty standard kanban-style backlog/doing/done Trello board for all sorts of stuff. A mix of personal, side-projects, work, thoughts, writing. It's a dumping ground. Every day, though, I may need to pick some cards out and replicate them on the team board or a project board. Now all I do is replicate this task. I've added a couple of additional lists in my Trello board, and I move the cards into them when I want them copied somewhere else. Zapier watches those lists and copies the cards. I'm finding it a useful way for moving cards around and getting work stuff out of my personal board, and into a work board.

A bit of gaffer tape

Whilst this automation works well for the most part, sometimes either Zapier or Trello craps out a little bit. When that happens, it's normally some snafu with the Trello api and the post. That's why the notification is an important part of the process. Using a quick ping into Slack let's me know a couple of things: that the zap is actually working still, and that there is a new card that has been created.

I'm sure there could be technical improvements to make here to make this a bit more robust. But as a scrappy self-serve solution for an editorial team to manage their through-put of stories, so far, so good!

A new year. A new blog design. The first time I've mucked about with my site in ages, actually. But why the renewed interest?

Ever since Statamic released version 2 a little while ago, I've been meaning to rebuild my version 1 site. It was more of an exercise in just learning something new than anything. However, about 18 months ago – maybe longer – I tried and then swiftly gave up. There was just too much of a gap between v1 and 2 that I could bridge at the time. Not enough head space. Turns out, it took something going wrong with my head to finally give me mental space to give it a go over new year this year.

In December, one Sunday, I fell off my road bike. I fractured both my hands, cut my eye and gave myself a nasty concussion. Whilst recuperating turns out that learning and building this new website was just the physiotherapy I needed both for my brain and my fingers. Finding myself with a bit of spare time, when I should've been out on my bike, meant I set to work migrating the old stuff from version 1, and, typically, redesigning in the process.

So, what's new?

I wanted a design refresh. In all honestly, I wanted to use fonts that weren't Monotype fonts! So, I have a bit of a thing for Retina from Frere Jones, after trialing it for a project with Conde Nast over the summer. And what better pairing than Exchange which is a beautiful serif.

From a content perspective, I've also got a new section called reading where I pull in Pinboard links that interest me and others might find interesting. I've also been working on a portfolio. Haven't had one of those for a while. I've done some interesting work over the past ten years and it's nice to document it. For my sake more than anything.

So, what's technically new?

Under the hood, quite a lot. Have a read of the site colophon for a swift introduction. The site now runs on version 2 of Statamic. Which brings with it a whole load of advantages and features. Statamic is built on top of Laravel, so locally, I use the nifty Valet. Keeping with the Laravel theme, I use the excellent Forge service to build and manage a server using a Digital Ocean droplet. I used to use Mediatemple, like, forever, but this setup is absolutely fabulous in comparison. Everything Just Works. The sweetener is that Forge automatically deploys from Github. All I need to do to add content, or make a change to the site is commit the changes to my production branch and that's that.

Now, I know to many of you reading this, all that I've just explained has been doable for a million years and what am I getting so excited about? Well, I think that's certainly the case but it hasn't been until recently that there have been a series of interconnected services available for people who are, yes, still, anxious about using the command line.

CSS wise, I've tried using CSS grid. A few things might be amiss as I continue to work on the layout and I get my head around CSS Grid and its possibilities.

Today is my first day working at the European Molecular Biology Laboratory - EMBL. I'll be leading digital communications and to say I'm excited by the challenge is probably a bit of an understatement.

I've had nearly a year of working on a few bits and pieces of consulting for a few new clients in addition to several two week design sprints for EMBL on their holistic corporate design. It was during these sprints that I got a growing sense of the work that needed to be done.

Back in 2012, I was knee-deep working on redesigning the CERN website. It was, to date, the most fulfilling work of my career. Not because of the result, or the process, or the commitment of the client and their team, but because of the work being done at CERN. It matters. And I have the same feeling now about EMBL. Fundamental scientific research matters. It matters to the human race, to our understanding of the world around us, and how we might overcome some of life's greatest challenges on this planet and beyond. When I first started my design career, I wanted to work for projects that meant something. After ten years of almost exclusively commercial work, I'm thrilled to be getting my teeth stuck into something meaningful..