Write it down

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.

Editorial planning with Trello and Zapier

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:

Zapier webhooks fields

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


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


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




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!

Newish blog

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

Defining design principles at EMBL

For a little while, since leaving Monotype, I've been working with the communications team at the European Molecular Biology Laboratory (EMBL) on a holistic corporate design project. It's pretty exciting work.

I'm lucky that the project is being headed by Dan Noyes, who I worked with at CERN, so he and I know how to work together pretty well. There is a fabulous team in place, and we've been tackling some fundamentals of the brand, the strategy to implement the it, all within the context of a complex scientific organisation.

To help keep us arrow straight whilst navigating this problem we defined design principles to do it. Now, I'm sure there are many ways to define principles but here's how I do it and it's really quite simple. I was shown this by Leisa when we defined design principles for the redesign of Drupal 7 years ago. All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.

Throughout the sprint, we defined the following design principles for EMBL:

  1. Make it sustainable

We will create a long-term, sustainable system. Designed for efficiency, re-use, and scale.

Sustainable systems are diverse and productive indefinitely. Being holistically focussed on how EMBL interacts with its audiences internal and external, means we create meaningful, sustainable experiences over the longer term.

  1. Show our work

We will prioritise demonstration over discussion. Through prototyping we will show how these principles and values apply to the work.

We will embrace modern design practices by starting small and iterating quickly. We will avoid big reveals and develop a process of publishing early and often. This requires a change of mindset of the team: to be comfortable with ‘not done yet’; to be satisfied to prioritise function over form; to get the things we make in the hands of our audience so we can understand their needs more quickly.

  1. Keep it simple

We will do the difficult work to keep the things we make simple, approachable, and put the user’s needs first.

EMBL is complex. As are the audiences, services, applications, and communications material that operate within the brand. We will do the hard work to uncover and expose the simplicity of the core.

  1. We are all one organisation

We will cultivate cross-pollination of services, products, ideas, and collaboration.

We will proactively seek out opportunities to collaborate on the design of services across all channels throughout EMBL and invite feedback and new perspectives. We will share and discuss our methods.

  1. Physical, digital, and environmental are in sync

We will ensure a holistic approach for one system for all printed, digital and environmental touch-points.

Design systems across media evolve at different rates. We will ensure systems across all channels are relevant to the media, but also share nomenclature, design patterns, and are built from the same principles. We will think and act as a cross-disciplinary design team.

  1. Pave the cowpath

We will make the design language accessible where people are already working.

Forging a new path is hard. And sometimes a waste of energy. By understanding how the brand is expressed currently, we develop new ways to provide the ingredients of the brand to the people already doing the work, in the place they are doing it. We will invent new ways with which to distribute the brand across a constantly moving, evolving system. We shouldn’t press pause.

  1. Repeat the words we use

Through consistency and repetition, we will create and maintain a design nomenclature that will become part of the EMBL vernacular.

The words we use are important. By repeating these words about EMBLs products and services, they can remind us many times every day what we believe. Changing the words we use can help change the culture of an organisation to be more design and brand aware.

Another important aspect to these is the way they are structured. A design principle is a belief. It's something we promise to do and should be worded as such.

You can read more about the design process on EMBL's communications blog.

⬅ Previous
1 of 101 pages (There are 502 posts)
Next ➡