Building Editions at The Times

Internal tools never get enough attention.

Building them can be a thankless, unseen task that’s rarely prioritised, as it is not immediately obvious how to tie investment in them back to the bottom line. It can be too easy to jump on the customer-facing speedboat and jet away from them, leaving a wake of stopgaps that can often leave you with tightly coupled intricate workarounds that are enormously difficult to pick apart.

This was the case at The Times for the last four years. While we spent a long time discussing and designing how editions might work on our readers’ screens, we didn’t place any focus on how to make building these experiences manageable for our editors. We quickly shoehorned the process into our generic digital CMS, making it difficult to maintain or build upon, and creating a process for our editors that took much longer than it should have done.

Edition Builder was our solution to this problem, and has been two years in the making. At its heart, it is a simple drag and drop interface that allows you to place and publish stories in our edition. Beneath the surface is a huge amount of user research and UX refinement and, crucially, the foundations for future newsroom tools.

Late last year The Times went live, and this week The Sunday Times joined them, and now all editions from The Times and The Sunday Times are produced on Edition Builder. I’d love to tell you more about the story of how we got here and what it means for the future.

From prototype to production

I’m well known as someone who is not easily impressed, but from day one editions excited me: the idea of publishing fewer stories, of higher quality, in a bundled format was novel. However, the way we produced them irked me. Our editors were fighting with the system to make the most basic changes. The more time went on, the more we wanted to do with editions and the more painful it came to be.

In a break from our day-to-day jobs supporting editorial, Chris Hutchinson (now a Principal Engineer at The Times) and I took some time out with the implicit instruction to build something cool that we thought needed to exist. We only had a week, and we went slightly over schedule, but we knew from the start we wanted to solve our edition curation problem.

The value we were able to provide from our experience understanding the editorial pain-points, being able to theorise a solution, and eventually prototyping it wouldn’t have happened outside of our cross-functional editorial development team. These groups of product and engineering-focused, journalism-obsessed individuals that have sprung up at news orgs all around the world are, in my opinion, some of the most valuable people in the business.

Our team’s dream was to empower the newsroom to do much more with editions, faster and more intuitively than before, but the current monolithic CMS made this more difficult than it should have been.

Edition Builder’s prototype came out of that week, and our demo roadshow made the rounds through the technology and editorial departments. There was ambition to build more. Finally, after a presentation that included way too many Jurassic Park gifs for the seniority of the audience, we got there, and the investment case was signed off.

We formed a team of six engineers, a user-experience designer, and myself, acting as the product manager. As a new team, with a clear purpose, we dived in and (of course) began making mistakes.

It quickly became apparent that some of our assumptions were misplaced, or just wrong. We designed an introduction screen that we thought made it clear which edition was live at any one time: nobody from editorial understood it. We thought that previewing articles was something people did habitually but didn’t really need: it turns out they did. And we thought, most wrongly, that getting articles out of the system, and publishing our eventual output would be the easy bit: publishing functionality alone took six months to build.

Inevitably there are more unknowns than you realise entering a project like this. Our objective was very clear: build a slimmer, faster, more efficient, and more extensible system for editions; and sliced up, the journey ahead looked manageable. But between the cracks were services that hadn’t seen new deployments in months, orphaned systems held together with the code equivalent of a low-budget PVA glue, and teams across the business skittish and burnt from too many lookalike projects gone wrong.

This is mostly why it took just over two years to bring Edition Builder into production. When a single tool is responsible for a disproportionate amount of your output, replacing it becomes a project of either changing what you do with it, or covering off every feature it has.

Making it so that users could open up articles in the original editing system was important. This was the initial paper prototype I threw together.

There was no logical physical analogy that didn’t sound absurdly risky: like shifting your entire printing press all at once to another that has identical output, but also looks and works completely differently.

Getting editorial users on side was a crucial part of this project from the start. Over time we probably ended up building a few small features that weren’t needed (and we are now in the process of gradually removing), but the goodwill gained from these relatively small features greatly outweighed the development cost.

That established trust was important to move forward with some bigger work items without consulting users every step of the way, whilst working more closely with them on items we knew they cared about. It meant we slowly built up a relationship where we felt aligned in the combined goal of transforming this workflow to make a better product, rather than being forced to replicate every step for a feeling of safety and familiarity.

Ultimately this all paid off. Even though it took a little longer than expected, and the team working on it changed in its entirety when we hit a particularly sticky deployment issue towards the end. Some of our heaviest editorial users have given us rave reviews: it is “far faster”, the time savings “impressive” and the rollout “exemplary”.

In our prototype, we worked out a time saving of approximately 5x on doing some basic actions. Edition Builder in production is in some cases 50–100x faster than the previous workflow to perform the same task. We really should hold everything used this regularly to the same standards.

With that I’d like to thank the people on the team that brought us to where we are now: Himesh Ladva, Tom Chambers, Elliot Davies, Cassie Best, Leah Haskoylu, Chris Hutchinson, James Fuller, Geoff Ford, Chris Jordan, Stefano Berdusco, Jack Stevens, Tom Hoad and Adele Kufour.👏

I’d also like to thank everyone in the newsroom that worked with us to help develop the tool and get it into production, including Wes Rock, Gary Mitchell, Abhi Ahluwalia, George Lindsay-Watson, David Rankin, Sadie Gray, Hannah Rock, Hannah Scott, and Michael Brear.

Read part two here, and learn the lessons we learned putting this system together.

And, enjoy last weekend’s The Sunday Times; the first Sunday edition made with Edition Builder. 🎉