Shortening the goalposts

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

Transcript

1. Shortening the GOALPOSTS Chris Clarke / @mr_mr UX Scotland 2014
2. wtfcontent.com hello
3. Who am I? @mr_mr ux’er @theguardian big into sports
4. (Hopefully) This talk is going to: Intentions Intentions today
5. Intentions show you some cool football things Wow you with amazing football
6. Intentions show you some cool football things live football things Show real examples, not just theory. You can view it all now - live.
7. 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
8. And in 45 minutes or less... Guardian Beta site discovery & development Adapting lean methods So what am I talking about today?
9. 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.
10. 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
11. 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.
12. Next gen web So the next generation of the Guardian website at or ‘next gen web’ You may have heard or refer to as...
13. guardian beta ...the Guardian beta site.
14. 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.
15. You can access the beta site right now, by clicking on the blue ‘beta’ button in the top bar on the current site
16. Coming to a browser near you!
17. 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.
18. OK... So Why football? So why did we do football first?
19. 2nd Football is the second most popular vertical on the current desktop
20. 1st 2nd And at times the most popular on mobile
21. 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.
22. football-trolling.tumblr.com Kickoff So we started in the first weeks of January
23. Panic! we had big ambitions..
24. Panic panic! ..and not a huge amount of time.. January February March
25. Panic panic! ..and we had a small team UX DES PM DEV QA So we needed to get off on the right foot!
26. Part 1 January February Part one covers the discovery and research phase, we needed to know where we were going.
27. 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’
28. 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
29. 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
30. So what did we learn? From all that research, what did we learn?
31. 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.
32. 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.
33. 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.
34. 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.
35. 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.
36. 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.
37. 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.
38. Sketch time So we went straight into rapid sketching over 2 weeks. 1 week where anything would be possible. All about generating ideas.
39. And then a second week of reality checks and scaling back into something malleable.
40. Code alert! html wireframes I then went straight into the browser using Codekit and Sass to create a set of modular html wireframes.
41. 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
42. 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.
43. Part 2 February End of March April Part 2 was all about the development and implementation of designs and ideas
44. 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.
45. Plan number 1 update each page, one at a time
46. 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?
47. Tag pages yeah that’s not loads is it, should be easy!
48. Look at an existing page Highlight what needs to be added in build Build it <..> <..>
49. Good plan?
50. Not really....
51. What was going wrong? Thinking too big Boiling the ocean? Boiling all the oceans Small team in big team boots
52. What was going wrong? Thinking too big working too Slow Working through treacle In 3 weeks we released once
53. Plan number 2 modular framework
54. 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...
55. 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.
56. Football front page Front page table
57. Embedded element Embedded table in article
58. DEV DES Design and build in unison Back and forth and everyone got their say
59. close...r This was much closer to the final outcome
60. Problem? Better working flow Better flow and output More streamlined
61. 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
62. Plan number 3 minimal continuous delivery Spoiler alert And then the 3rd plan: continuous delivery Spoiler alert: it won
63. 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.
64. 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
65. “ 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
66. 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.
67. 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.
68. 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
69. 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
70. 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.
71. Editor tools - ability to place data on front pages Embed player cards in live blogs.
72. 1 day 8 days spread over 3 weeks 4 days Spread out player cards into multiple little releases Worked with editors and iterated
73. such WIN So when we realised we couldn’t get everything done, and relaxed We got more done.
74. Brad Frost - Atomic design Atoms Molecules Organisms Templates Pages Brad Frost Atomic design concept Resonates with the football but...
75. Templates Pages Atomic design - Guardian style Atoms Molecules Organisms ...Guardian football really backwards to this result.
76. football-trolling.tumblr.com How did we get like this? How did we end up so quick?
77. 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.
78. 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
79. 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
80. 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!
81. Made some great work
82. Made some great work
83. Made some great work
84. Made some great work
85. World cup wall-chart!
86. Player card in situ
87. Current visible .com data Vs beta data
88. 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
89. Some examples of where we were planning to take the player cards, but just ran out of time.
90. what we couldn’t do More data detail Personal focus Bespoke designs
91. Part 3 full time End of April
92. football-trolling.tumblr.com takeaways
93. 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.
94. 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.
95. 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
96. 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.
97. we thought small 3 Happened by design
98. 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.
99. “ 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.
100. thanks! @mr_mr theguardian.com/football?view=mobile