Shortening the goalposts
Minimal continuous deployment on Guardian Football
Around the middle of January, I moved teams within the Guardian onto our Football product team. We were tasked with creating a new weekend experience while improving some old bug-bears and a responsive design solution.
We had three areas of focus:
- Making strong use of our data: the Guardian pays PA for football-related data and we wanted to make sure we were using it to its full potential.
- Users’ perception of our “liveness”: Users thought we were slow. Slower than the BBC, Sky and all the others. How could we improve this?
- Doing a better job on mobile: A large proportion of our weekend traffic is on mobile, and not all of our relevant content was visible to that traffic. We needed to update this — and fast.
The setup
We held workshops with the sports editors, ran diary studies and sieved through mountains of data, all to get better ideas of what worked, where our users were going, how they were getting there, and how to keep them there.
We spent two weeks sketching up all the ideas we had from those workshops: one week where any idea was possible and then a second week refining those ideas, throwing out the unfeasible ones.
I then created a series of prototypes, to prove our interaction ideas were valid. Using a framework of Codekit and Sass I managed to produce a lot in a very short space of time. Depending on the quality, we even put them in front of users. Otherwise our designer designed the hell out of the prototypes and we would test them in our UX studio.
What we had going for us
There was one thing going for us before we started: we had great tone. Users would cite us over competitors for our analysis. So our match reports were heavily frequented as deep dives for the football fanatics.
We had a lot of quick wins — we started with the basics: tables, fixtures and results. All of these pages already existed, so we had clear aims of how we could improve them.
However…
The honeymoon period was soon over. Once we sat and really looked at what had been built previously, we realised things were going to take longer than we thought. This was all with the added challenge of only having February and March to complete the work.
Three weeks passed. It was taking us too long to create features: we needed to change how we were delivering.
We needed a plan.
Minimal continuous deployment
We took stock again and decided on a key factor: creating basic features meant we weren’t waiting until the design was perfected. We could push partial designs with only key features enabled to see how well they performed. If they improved pages, we could re-visit them in the future with the majority of the basics already built.
In the example above, the option on the left would take a week and a half to produce because of the added complexity of including team badges. The option on the right — without badges — would take a day and a half, improving some of the lack of “liveness” perception with our users in the process.
We pushed live scores on our match pages up, without team badges, the team “form” and many other parts, but, crucially, it was live for everyone to see. If there were bugs to fix or improvements to make, it was easy to implement because we were still making constant improvements.
Before we got to the minimal deployment plan, we released four updates in February. By March we were releasing nearly every day, sometimes twice.
How we changed our way of working
- We were a small team, so we kept the goals small and finished them often. Then we could test faster and learn quicker.
- By working quickly we decided quickly, things flowed better and teams around us wanted to be in the same boat.
- To do this, cut your chunks of work into smaller chunks. Keep going to the minimum. If you can see measured improvement then do the rest of the chunks. If not, you’ve only lost a day or two maximum.
- Communicating frequently about what we were releasing made us feel truly agile.
- Releasing often not only made the team look great internally, but improved pages for our users too.
What’s next?
We’re looking deeper into mobile: a large portion of our football traffic is on mobile and this increases at the weekend. We want to make sure the mobile experience is equal to that of desktop, but not overwhelming.
We’re putting a lot of effort into improving our match pages, we have a lot of rich information that isn’t surfaced and we want to change that. We’re looking into how our users scan our live pages, and how we give them all the content they want - in one instance. One plan is to truncate our minute-by-minute live blogs, bringing a more complete overview of the game, and surfacing supporting content better (match stats, line-ups, etc).
We’re creating a tool for editors to drop elements into their match reports and live blogs as they’re writing.
We’ll also be extending this to player cards, match previews and stats and beyond.
I can see the carrot at the end of the tunnel (Stuart Pearce)
We’re not going to change the world with our updates, but hopefully we’re making bold enough steps to make a difference within the Guardian itself. Roll on continuous deployment from a minimal perspective.
Originally posted on the Guardian Developer Blog
Thanks to Matt Andrews and Jon Hyde for helping out with this.
If you like this post I’d appreciate if you hit recommend or share with a friend! You can also follow me on twitter.
