a new responsive site, with the intention of turning the whole web experience into a mobile-ﬁrst 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.
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’
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
- - - - - - - - - - - - - = 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.
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.
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 ﬁnding 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 ﬁrst. Giving what they want, they may stay longer on the site.
(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?
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...
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 modiﬁed and embedded in other pages.
the right sort of design. At the guardian we say "energy on the right things". We had to start sacriﬁcing 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.
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 ﬁgure 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.
- - - - - 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.