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
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.
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
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.
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.
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.
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.
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’
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
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
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.
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.
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.
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.
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
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?
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...
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.
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
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.
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
“ 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
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.
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.
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
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
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.
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.
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
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
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!
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.
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.
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.
“ 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.
mrmr1
uxevents
tajima_kaho
isaikaori
uxaustralia
ajstarks
morganepeng
hansolo21
visional_engineering_and_design
bryan
eileencodes
maltzj
chriscoyier
yeseniaperezcruz
michaelherold
smashingmag
colly
philhawksworth
gr2m
cherdarchuk
bluesmoon