Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Shortening the goalposts

Shortening the goalposts

How Guardian football web team adopted lean methadologies to release quickly and often

Chris J Clarke

June 21, 2014

More Decks by Chris J Clarke

Other Decks in Design


  1. Intentions show you some cool football things live football things

    Show real examples, not just theory. You can view it all now - live.
  2. Intentions show you some cool football things live football things

    insight into our process Insight into a process which worked so well we’re weaving it into other teams in the department
  3. And in 45 minutes or less... Guardian Beta site discovery

    & development Adapting lean methods So what am I talking about today?
  4. And in 45 minutes or less... Guardian Beta site discovery

    & development Adapting lean methods I’m going to talk a little bit about our new beta site and why we’re doing it.
  5. And in 45 minutes or less... Guardian Beta site discovery

    & development Adapting lean methods And then I’m going to talk about football discovery and development iteration
  6. And in 45 minutes or less... Guardian Beta site discovery

    & development Adapting lean methods How we managed to make lean methodology work for us, and go a bit further.
  7. Next gen web So the next generation of the Guardian

    website at or ‘next gen web’ You may have heard or refer to as...
  8. Around eighteen months ago the Guardian set out to create

    a new responsive site, with the intention of turning the whole web experience into a mobile-first website. This started off with a mobile only part and will culminate in the desktop site. It’s not the guardian desktop site that you know if you went there right now.
  9. You can access the beta site right now, by clicking

    on the blue ‘beta’ button in the top bar on the current site
  10. http://www.flickr.com/photos/brad_frost/7387823392 many device So why were we doing it? We

    were breaching 100m unique browsers and soon to break 50% barrier of mobile device visits We needed to keep up with this shift.
  11. 1st 2nd And some event called the world cup was

    coming up in June, our traffic would inflate and lots would be visiting via mobile. So a new experience was in order.
  12. Panic panic! ..and we had a small team UX DES

    PM DEV QA So we needed to get off on the right foot!
  13. Part 1 January February Part one covers the discovery and

    research phase, we needed to know where we were going.
  14. Needed to generate a Friday-Monday habit ( live days )

    BBC was associated with speed, Guardian with detail and length Friday Monday Users would come for the match reports. defining (some of) the strengths & weaknesses Users came to us for detail - match reports, analysis From our focus group, BBC was considered fast but robotic, Guardian more human but longer, harder to just scan. So we were struggling at properly capturing the ‘Friday to Monday LIVE experience’
  15. Workshop with our sports editors - these guys had mountains

    of experience and we wanted to tap into that immediately. We ran a diary study over a weekend in March, as it’s important to get user insight without the constraints of a lab. And all the football pages already existed in skeleton form, so we could measure to see where interesting things were occurring
  16. Came out with 4 personas User into data (expert) User

    into their team only (our focus for football) A casual and a snacker These helped us shape our work and focus recruiting for lab sessions
  17. 1 Sports api P W L D Pts - -

    - - - - - - - - - - - - - = Premier League table We pay for a 3rd party sports API, and it didn’t show. As a result our pages weren’t showing simple information quickly and easily on our beta offering.
  18. 1 Tell stories with data Our competitors were just showing

    stats, we wanted to tell stories. We wanted more. We wanted to expand on the basics and bring knowledge to users without much thought.
  19. 2 Speed Users thought we were slow. Now when I

    mean slow it wasn’t to do with getting the score the quickest. It was about way-finding.
  20. Better signposting 2 So we needed to improve out signposting

    to useful football content and data. Football is a fairly predictable thing. Matches happen at the time each week for a majority of the year, having a site which consistently displays data in the same place for years, will be considered faster.
  21. 3 Mobile Mobile - A big focus for us. Growing

    user base on mobile and tablet, soon to overtake desktop, and popular with football at the weekend.
  22. Always mobile up front 3 #1 Mobile was first but

    if we slipped at any point an created desktop designs, it was always in our minds. Always up front.
  23. What’s happening with my team? What’s happening to the teams

    that would affect my team’s position? The league my team is in, in general Live blog User 3pm 6:30pm onwards Desires Level of interest Users would lose interest quickly after finding their team info Users would ’snack’ on football live blogs during a match Mainly on their phones while out of the house. Users were looking for basic info first. Giving what they want, they may stay longer on the site.
  24. Sketch time So we went straight into rapid sketching over

    2 weeks. 1 week where anything would be possible. All about generating ideas.
  25. Code alert! html wireframes I then went straight into the

    browser using Codekit and Sass to create a set of modular html wireframes.
  26. Why html? But doing prototypes over wireframes meant: I got

    into the browser faster It was Interactive I made quicker iterations And provided realistic solutions for multiple devices
  27. Design And we kicked off page and element design at

    the same time with the visual designer, so a good amount of setup in the first few weeks.
  28. Part 2 February End of March April Part 2 was

    all about the development and implementation of designs and ideas
  29. Enter the development team So we all sat down and

    talked through everything we’d sketched and designed Came up with a plan of action.
  30. Front pages Match pages Match preview Match During Match after

    (report) Data pages Tables Fixtures Live scores Results So as I said we started with a skeleton version of each of the base pages we needed. How about we start looking at each one of those and update as we go, page by page?
  31. Look at an existing page Highlight what needs to be

    added in build Build it <..> <..>
  32. What was going wrong? Thinking too big Boiling the ocean?

    Boiling all the oceans Small team in big team boots
  33. What was going wrong? Thinking too big working too Slow

    Working through treacle In 3 weeks we released once
  34. Modular framework match preview Fixture element Table element match report

    And so on... During the sketching we discussed the idea that everything to be built in separation, so individual elements could be added to pages and releases could be quick. But this was early on so we didn’t get too far into this until later on...
  35. Stand alone page element Right-hand column on article So some

    of our larger pages had a lot of improvements we wanted to make, we took the same modular approach as I did with the prototypes and the design and separated out the content. A block which sat on it’s own page could then be modified and embedded in other pages.
  36. Problem? Better working flow Still not quick enough But we

    could still do better At this point remember we still only had a few weeks left And we only released once in 2 weeks
  37. Plan number 3 minimal continuous delivery Spoiler alert And then

    the 3rd plan: continuous delivery Spoiler alert: it won
  38. Lets talk about Energy on the right things Or. Doing

    the right sort of design. At the guardian we say "energy on the right things". We had to start sacrificing things to make sure we were releasing fast. Being small gave us focus, this focus made us less precious. Get work live. Nothing had to be perfect, because things rarely are. And that’s OK.
  39. unknowns So we delayed complex build parts, detailed design Which

    meant we could take lots of little risks, release faster and see what worked And make weekly releases of multiple features
  40. “ Laura Klein It’s as if they had a car

    without any brakes, and they’re worried about building the perfect cup holder Quote boiled down to: Focus on what needs to work first Not what looks best
  41. 1 to 2 weeks Badges were an unknown 1.5 days

    Everything existed in part, easy to manipulate Example: Designed parts had to take a hit, our API was patchy with badges and would take us too long to figure out. There was big unknown and it would hinder us from releasing, so we dropped it. We did put it in, but at that point the live score was visible and that’s whats important.
  42. Two weeks later we put badges on the page. Users

    didn’t even notice. They were too interested with the live score, but that didn’t stop us form doing it anyway. Gave us perspective on designing the right things.
  43. 2 days Complex but much easier to implement 1 week

    Possession doughnut of doom These are our match stats Donut was too complex for a fast release, so we removed it and released it and added it in later
  44. 2 0 2 0 Stats Match stats live at the

    bottom of alive blog A lot of scrolling to see supporting content So we truncated our mobile live blogs to bring stats into view within a few scrolls on mobile
  45. Today’s Stats PL table P W D L PTS -

    - - - - - P W D L PTS - - - - - - P W D L PTS - - - - - - P W D L PTS - - - - - - 2 0 weeks Stats 2 0 days Stats Today’s matches --- v --- --- v --- --- v --- --- v --- --- v --- --- v --- 2 0 days Today’s Stats PL table P W D L PTS - - - - - - P W D L PTS - - - - - - P W D L PTS - - - - - - P W D L PTS - - - - - - 2 0 days We started with one accordion Built more over the coming weeks. Data showed we cut the time on page in half. And users were spending that time elsewhere.
  46. Editor tools - ability to place data on front pages

    Embed player cards in live blogs.
  47. 1 day 8 days spread over 3 weeks 4 days

    Spread out player cards into multiple little releases Worked with editors and iterated
  48. such WIN So when we realised we couldn’t get everything

    done, and relaxed We got more done.
  49. Brad Frost - Atomic design Atoms Molecules Organisms Templates Pages

    Brad Frost Atomic design concept Resonates with the football but...
  50. Templates Pages Atomic design - Guardian style Atoms Molecules Organisms

    ...Guardian football really backwards to this result.
  51. Small team UX DES PM DEV QA Being small, worked

    small. Being small we could only do so much. Weekly releases of multiple features No planning sessions Sat in a line, our meetings involved turning to either side.
  52. Self imposed deadlines we had a tight deadline, we had

    to act fast. We added self imposed deadlines Once a week we released things 80% was our criteria for release
  53. We were honest With each other With our managers With

    what we could achieve So we were honest No egos - everyone had an input Straight with managers, everyone knew the plan And we knew what we could do
  54. LIVE People are using them in a quicker and more

    efficient way On our match pages, Time on page was down, but as a result users were spending that time elsewhere. 45% 42% what worked!
  55. what didn’t work to plan Bugs More discovery We made

    a lot of bugs, and a lot had to be handed over to other teams Not enough discovery
  56. Some examples of where we were planning to take the

    player cards, but just ran out of time.
  57. we delayed as many unknowns as we could 1 Didn’t

    hold back release for anything Just enough design in-between development If it worked it went out So we shared work earlier.
  58. we delayed as many unknowns as we could took lots

    of little risks 1 Didn’t hold back release for anything Just enough design in-between development If it worked it went out So we shared work earlier.
  59. we made sure we knew where we we’re going 2

    Discovery and research Need to plan before going headfirst in a solution Figure out the problem
  60. we made sure we knew where we we’re going before

    we started 2 Too often I see teams panic and start working up solutions. Discover the problem first and aim at that.
  61. we thought small And scaled big 3 But we still

    had big ambitions Our small team got to a ridiculous release rate at the end of our team life.
  62. “ Terry Venables And remember If history repeats itself, I

    should think we can expect the same thing again. We did a lot of things that were straightforward, obvious even, but if given the opportunity to do it again I’d approach it exactly the same way.