Written in collaboration with Penny Allen, user experience researcher on the Guardian mobile team.
Over a year ago, we started a journey to create a new Guardian native app on Android and iOS for both smartphones and tablets. This app was a new starting point on how we present our content across native platforms but also supposed to be a relevant update to our current app users – amongst our most loyal and engaged readers.
This journey was shaped by various challenges, but the biggest one by far was being able to meet the needs of our two main users: our content creators and our content consumers. This is not necessarily a new challenge as all products inherently acknowledge these two types of users. The creator has a set of needs and preferences which they want to communicate and provide to the consumer. On the other hand, the consumer has expectations on how the product will work and what they will use it for.
For many products, the content creator’s job is done once the product is finished, with their needs and preferences expressed in product characteristics, content and features. Products that change their content regularly are often an exception to this rule as the product allows the content creators to take a participative role even after the product is released. All the different Guardian products (print, web or native apps) are great examples of this as our content creators – the editorial team in the UK, US and Australia– publish new content on an minute-by-minute basis to be consumed by our content consumers – the readers.
A new Guardian app would be defined as much by its functionality and features as by the different stories it carries and their presentation. This unique challenge meant that going forward we had to make decisions by balancing their impact on both these users and the relationship between them.
In trying to achieve this important balance between both users needs we undertook various different processes, but found that the most valuable ones were often those that answered simple and focused questions.
What are we trying to build?
Original, innovative and memorable products (like Flipboard, Medium or FiftyThree’s Paper) often started with one great idea or unique insight that drew a clear vision of what the product could be. We wanted to start this project with a clear view of what was ahead of us, what shape the new app could take and what would be the readers’ reactions and expectations to these new ideas. To do this, we decided to start the project with a round of conceptual work to explore and validate different ideas internally and with readers.
The conceptual work started by tasking Code & Theory, an external digital agency, to produce three high-fidelity prototypes that explored extreme concepts of what a news app could be. Each prototype was focused on a different characteristic: a news feed structure, a heavy social integration and a story-led structure.
When testing the three prototypes with users, it became clear that the heavy social and story-led concepts alienated many users who couldn’t relate to the prominent execution of these features in the prototypes. The news feed prototype proved to be a more familiar concept but also exposed very different expectations readers had around the frequency of news, how the stories should be organised in the feed and even how they defined reading completion (the feeling of becoming sufficiently up-to-date with the news, each time they used the app).
With this, we realised that instead of focusing too much on a single functional feature, we would have to create a more balanced app that could work for the majority of our readers. We also learned a lot about our readers’ relationship with the Guardian – especially around how much they value the quality of our content and unique editorial voice.
We decided to move forward using the news feed structure as a starting point but also with a bigger awareness of readers’ expectations of the Guardian’s editorial choices.
How will it be different?
Riding on the wave of excitement from the conceptual work, the next step was one of restraint where we had to ask in more detail what would make this app unique and what features would support that.
Building on top of the news feed structure prototype, we explored this concept a bit further. We devised three different takes on the concept: a timeline-based feed, a personalised briefing feed and a collapsing feed.
The timeline-based feed prototype received very negative feedback because presenting stories by time didn’t accurately reflect their editorial importance. The personalised briefing feed concept, which provided only a selection of the 10 most relevant stories to that reader, made readers feel they were missing out on news due to the low number of stories and the high level of personalisation. The collapsing feed concept seemed to be too complex as the main interactions for collapsing and expanding the feed were generally overlooked and didn’t improve the experience.
The tests showed there were problems with some of the concept features and mechanisms, mainly because they disrupted or didn’t enhance the perception of the Guardian’s editorial choices. The consistent feedback from these prototypes and from the conceptual work prototypes showed the team that the Guardian’s assignment of varying importance to different stories was our unique differentiating area.
Focusing the app concept around the Guardian’s editorial voice felt the right way to move forward as it responded to the readers’ feedback and opened a strong channel for the participation of the editorial team.
Our previous app utilised a list-based presentation, which limited the editorial team to convey story importance mainly through the selection and order of the stories. What is actually going on behind the scenes is a more considerate and complex process of curation. The rich layouts of the printed newspaper give readers many clues about the importance of each story relative to the others. While we had no intention of replicating the newspaper on a digital device, we wanted to find ways to give readers more visual clues about the relevance of each story. We took forward an idea from the initial conceptual work where individual stories were represented as cards on front pages, but expanded the idea so each card could have different sizes that reflect the editorial importance of the story and rich styles that express the story content type (e.g. an article, a liveblog, a video).
This concept proved to be a good way forward as it provided our editorial team with an increased level of expression in the app. This focusing exercise was very important to ensure we were moving in a well defined route that brought something new to the table to both the readers and the editorial team.
Is it working in the real world?
Fast tracking into the future, we had the start of a functional app with new features being planned and scoped to be built. To provide guidance throughout the development process, we ran a beta study with thousands of users from various countries over an extended period of time. For the first few months we ran an invitation-only programme using a basic version of the app and closer to release added a beta branch to the Android app that was open to all .
Releasing the basic version of the app at the beginning of the project felt like a bold move as this version still had many features missing, but our concept was so different from the previous app that receiving feedback was fundamental.
The beta study spanned several months and in this time readers were able to use the app and provide us with feedback through mobile surveys at varying intervals and through a community group on Google+ whilst analytics data was also being tracked. Having spent quite a considerable amount of time researching the app in our in-house testing lab, we had almost forgotten the importance of how the apps are used in the real world. These two data sets allowed us to evaluate and understand how our readers’ reactions evolved. Some issues shifted and changed over time (e.g. the reactions to the new navigation model) whilst other issues stayed consistent from day one (e.g. the speed to perform a basic task).
A crucial discovery in this beta study was an issue with the density of news, something we gained no clear indication of when testing early versions of the app in the lab. Throughout the study, users expressed it was harder for them to gain an overview of the news as less stories were being displayed on the screen at any one time, mainly on smartphones. Moving from the list-based layout of the previous app to the new card-based layout created some problems to the core experience of the app, but there was also plenty of positive feedback on the new layout as readers felt it was visually appealing and displayed the stories in a much richer format. To understand how to best move forward, we brought beta study users into the lab who had problems with the low density of the new layout. We used this session to identify the various facets of the problem plus gather initial impressions on solutions we had been working on.
The beta study allowed us to deeply involve readers in the development process and to use their feedback to identify and improve the areas of the app where changes were most necessary before the initial release.
Can we make it better?
If the Guardian editorial voice was central to the app, the app features that complimented it had to enhance the overall experience for the reader, specifically features that were being carried from the previous app, like saving stories for later and search.
One approach which proved very beneficial was to iteratively test the key app features, enhancing them progressively with ever more detailed feedback, starting with broad feature concepts and later optimising individual feature characteristics.
The Home screen personalisation feature is a great example of this iterative testing approach. We knew from our analytics data that personalisation was an important feature to readers. Around 50% of them had customised the Home screens of the previous application with their favourite sections.
Starting with this insight we tested various personalisation concepts with readers, which explored different mechanisms for personalising the Home screen and the navigation. Based on the readers’ feedback we built a simple prototype of the strongest concept, which focused on personalising the Home screen using a consistent add/remove call-to-action available throughout the application, and tested it to refine the usability of the feature.
All the feedback up to this point allowed us to start implementing the feature in a basic form into the app. The beta study then played an important role in this iterative process as throughout the study we received feedback on how the personalisation feature was working. The users highlighted in the study that some areas of the personalisation mechanism were creating more problems to them. We tested the feature again with these users focusing now on very specific details of the feature implementation like the icons and states of the personalisation calls-to-action.
This repeated validation process was very beneficial as it provided answers with the right level of fidelity at the right stage of the project. When we started we simply needed to know if the editorial team and the readers found a specific feature valuable, whilst towards the end of the project we looked for more focused feedback to optimise the feature.
To arrive at this new app we had to embark in a long journey of trial and error, experimenting with multiple concepts, asking difficult questions, being focused about what would make this app unique and developing in the open with thousands of readers.
Building products that matter, that make a difference and have a real impact on people’s lives, is a hard task to accomplish. Creating a strong vehicle for the Guardian’s editorial voice was our starting point to a new Guardian app, which we hope will make a difference to an ever growing audience that seeks quality independent journalism.