$30 off During Our Annual Pro Sale. View Details »

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
Tweet

More Decks by Chris J Clarke

Other Decks in Design

Transcript

  1. Shortening the
    GOALPOSTS
    Chris Clarke / @mr_mr
    UX Scotland 2014

    View Slide

  2. wtfcontent.com
    hello

    View Slide

  3. Who am I?
    @mr_mr
    ux’er @theguardian
    big into sports

    View Slide

  4. (Hopefully) This
    talk is going to:
    Intentions
    Intentions today

    View Slide

  5. Intentions
    show you some cool football things
    Wow you with amazing football

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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.

    View Slide

  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

    View Slide

  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.

    View Slide

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

    View Slide

  13. guardian beta
    ...the Guardian beta site.

    View Slide

  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.

    View Slide

  15. You can access the beta site right now, by clicking on the blue ‘beta’ button in the top bar on the current site

    View Slide

  16. Coming to a browser near you!

    View Slide

  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.

    View Slide

  18. OK...
    So Why football?
    So why did we do football first?

    View Slide

  19. 2nd
    Football is the second most popular vertical on the current desktop

    View Slide

  20. 1st
    2nd
    And at times the most popular on mobile

    View Slide

  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.

    View Slide

  22. football-trolling.tumblr.com
    Kickoff
    So we started in the first weeks of January

    View Slide

  23. Panic!
    we had big
    ambitions..

    View Slide

  24. Panic panic!
    ..and not a huge
    amount of time..
    January February March

    View Slide

  25. Panic panic!
    ..and we had a small team
    UX
    DES
    PM
    DEV
    QA
    So we needed to get off on the right foot!

    View Slide

  26. Part 1
    January February
    Part one covers the discovery and research phase, we needed to know where we were going.

    View Slide

  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’

    View Slide

  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

    View Slide

  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

    View Slide

  30. So
    what did we learn?
    From all that research, what did we learn?

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  38. Sketch time
    So we went straight into rapid sketching over 2 weeks. 1 week where anything would be possible.
    All about generating ideas.

    View Slide

  39. And then a second week of reality checks and scaling back into something malleable.

    View Slide

  40. Code alert!
    html wireframes
    I then went straight into the browser using Codekit and Sass to create a set of modular html wireframes.

    View Slide

  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

    View Slide

  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.

    View Slide

  43. Part 2
    February End of March April
    Part 2 was all about the development and implementation of designs and ideas

    View Slide

  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.

    View Slide

  45. Plan number 1
    update each page,
    one at a time

    View Slide

  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?

    View Slide

  47. Tag pages
    yeah that’s not loads is it, should be easy!

    View Slide

  48. Look at an
    existing page
    Highlight what needs to
    be added in build
    Build it
    <..>
    <..>

    View Slide

  49. Good plan?

    View Slide

  50. Not really....

    View Slide

  51. What was going wrong?
    Thinking too big
    Boiling the ocean?
    Boiling all the oceans
    Small team in big team boots

    View Slide

  52. What was going wrong?
    Thinking too big
    working too Slow
    Working through treacle
    In 3 weeks we released once

    View Slide

  53. Plan number 2
    modular
    framework

    View Slide

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

    View Slide

  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.

    View Slide

  56. Football front page
    Front page table

    View Slide

  57. Embedded element
    Embedded table in article

    View Slide

  58. DEV DES
    Design and build in unison
    Back and forth and everyone got their say

    View Slide

  59. close...r
    This was much closer to the final outcome

    View Slide

  60. Problem?
    Better working flow
    Better flow and output
    More streamlined

    View Slide

  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

    View Slide

  62. Plan number 3
    minimal continuous
    delivery
    Spoiler alert
    And then the 3rd plan: continuous delivery
    Spoiler alert: it won

    View Slide

  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.

    View Slide

  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

    View Slide


  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  71. Editor tools - ability to place data on front pages
    Embed player cards in live blogs.

    View Slide

  72. 1 day 8 days
    spread over 3 weeks
    4 days
    Spread out player cards into multiple little releases
    Worked with editors and iterated

    View Slide

  73. such WIN
    So when we realised we couldn’t get everything done, and relaxed
    We got more done.

    View Slide

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

    View Slide

  75. Templates
    Pages
    Atomic design - Guardian style
    Atoms
    Molecules
    Organisms
    ...Guardian football really backwards to this result.

    View Slide

  76. football-trolling.tumblr.com
    How did we get like this?
    How did we end up so quick?

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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!

    View Slide

  81. Made some great work

    View Slide

  82. Made some great work

    View Slide

  83. Made some great work

    View Slide

  84. Made some great work

    View Slide

  85. World cup wall-chart!

    View Slide

  86. Player card in situ

    View Slide

  87. Current visible .com data
    Vs beta data

    View Slide

  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

    View Slide

  89. Some examples of where we were planning to take the player cards, but just ran out of time.

    View Slide

  90. what we couldn’t do
    More data detail Personal focus Bespoke designs

    View Slide

  91. Part 3
    full time
    End of April

    View Slide

  92. football-trolling.tumblr.com
    takeaways

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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.

    View Slide

  97. we thought small
    3
    Happened by design

    View Slide

  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.

    View Slide


  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.

    View Slide

  100. thanks!
    @mr_mr
    theguardian.com/football?view=mobile

    View Slide