Case Study: Coles Magazine App
Getting the audience of Australia’s most read print magazine more engaged with its digital offering (and measuring it)
Summary
There’s a lot someone can do with a piece of paper, there’s also a lot that can’t be done with a piece of paper. You can’t copy and paste it, you can’t search it, you can’t change it after it’s printed and most importantly, you can only barely measure its successes or failures— it’s a common problem for print media, but how do you solve it? In 2013, Coles magazine emerged as one of the most widely read magazines in Australia but ways to measure its engagement was becoming a problem worth solving.
The digital version of the app was already established using Oomph, a platform that specialises in print to digital transformation, and so the decision was to customise the tablet app to help increase and measure engagement.
User-centred design process
As far as the business needs were concerned, the question was simple. What are users engaging with and why? Areas of engagement were split into these categories to be able to compare the metrics between them:
- Are users engaging with content to increase productivity?
- Are users engaging with the content because it’s personal?
- Are users engaging with the content because it’s local?
- Are users engaging with content using methods of discovery?
- Are users engaging with content because it’s current (updating live)?
The question for us then became “how can we maintain a user-centred design and meet the business needs?” We sought ways to simultaneously increase the likelihood of engagement and the ability to measure it, all whilst keeping the users needs at the forefront of each stage.
To do this, first thing was first: Learn
What does the user expect?
A great place to start meeting the user needs wasn’t to think of ways to re-invent the wheel, but rather to understand what the users expected (the mental model) from the some of the most popular features in food apps.
Competitive Audit
To do this, a competitive audit was pulled together to find these features and what standards were shared between them.
Experience Mapping
Along with having an understanding of the mental models within food apps, the journey that surrounded the experience before, during and after any interaction needed to be accounted for. By running internal stakeholder workshops a hybrid ecosystem and customer journey map was produced. This helped to keep empathy for the user at the front of our collective mind but also, it was a tool to explore new ideas that were not yet available in the competition.
Top Insights
- No one was helping users with cooking events (Christmas, Mother’s Day, Easter, etc).
- Shopping lists, personalised collections and online content were popular features that shared a standard experience across the board.
- The interactions outside of the app were complex with vast variation between users.
Drawing from all insights, a roadmap of features was taking shape. Against every business need, a set of features was attached to each.
Productivity: Shopping list, Meal planner and Calendar
Personalisation: Notes, Social sharing and Favourites
Discoverability: Search Content and Search Recipe
Live Updates: Download recipe and Download Issues
Localisation: Store Locator
Now onto step two: Build
Sketching out bad ideas and refining requirements
To use the Meal Planner feature as an example, we realised it was essentially a combination of scheduler and a set of recipe content.
Problem: both concepts used in the Meal Planner had strong pre-exisiting mental models however, when they were combined, there was no such standard to be relied on. What could we create that the user could feel confident learning for the first time?
Sketching helped to visualise ideas for the whole team to review but more importantly, it quickly revealed bad ideas and false assumptions as well as highlighting additional functional and content requirements.
The worst ideas
- Calendar function turns out to be useless when meal plans are based on seasonal events.
- Trying to manipulate a schedule with buttons is clumsy, needs gesture control.
- Timeline and card designs didn’t show enough at a glance to get a good idea of the plan.
The additional Requirements
- Ability to add square recipe thumbnails to the database
- Ability to truncate recipe titles that are too long
- Ability to visually distinguish between prep and cook times
How can users traverse between content and tool?
Sketching also surfaced the project’s most challenging question:
How can we expect users to move between consuming content and using the tools?
Problem: People were already using and enjoying the digital version of the magazine the way it was so migrating the user base to a new experience was not an option. How were we to forge new tools to the app that would be intuitive for the user?
Super Nav User Flow
To do this we needed a portal in which a user could connect any part of the page’s content to any of the available tools. Essentially, we needed to fulfil this user story:
As a Mother with young children, I want the ingredients of a ‘Feed your Family’ recipe on my shopping list so that when I go shopping I can pick up what I need.
It was complicated in the way that it was connecting many types of information to many possible destinations in which not all connections where compatible. To flesh out what path the user would need to take to complete any given task, a user flow diagram was drawn up. Again, this was a tool to keep us on the same page and make any points of friction in user experience obvious.
How can we get a grip on the workload?
Another problem we faced was getting a birds eye view of the project, there was a lot to be built and it was difficult to see where effort needed to be directed as well as the relationship between features and content. A somewhat uncommon IA tool known as an Application Map was developed to help us point out and talk to complicated problems.
Sounds good, but what will it actually look like?
At this point the information architecture had been set, but what hadn’t been solidified was how the user would actually interface with this information?
Problem: Keeping to a user-centred design approach, the aim was to reduce the cognitive load where possible. How would we do this? In this case it meant that all the new features shared the same generic screen design, just with the content being contextual to the task:
Modal > Collection View > Feature
Continuing with the same example, the below are the wireframes for the Meal Planner showing the three shared screen types.
Visual design and The iOS 7 bombshell
When it came time to sort out high fidelity mock ups, there was an issue that threatened us to re-think our approach. The developer release of iOS 7 came out and it was a big leap from the look of iOS 6.
As it came to be known, skeuomorphic vs. flat
Problem: At the time it was a big deal. All food apps up until this point were heavily doused in faux canvas, chalkboard and wood graphics. It was a widely accepted design trend that was peaking in its execution. So, do we take up the opportunity to be an early adopter of the new system default, or stick with what’s been popular so far?
We had already begun designs in the skeuomorphic style and there was both internal and external pressure to keep moving forward with it. To help make the decision, a selection of screens were developed to be able compare both styles.
Going with the iOS 7 design language meant that the original designs needed to be scrapped. Not something all designers particularly enjoy, but in the end, the benefits of being compliant were more compelling for the user than not e.g. having navigation buttons that users would be familiar with from using them in other apps.
Ship it!
Prototyping, iterating, innovating… the bars on the Burndown chart were getting smaller and smaller. We had our first release of the iOS 7 version of the app with the following major updates to the app.
Super Nav Modal: Tapping the share button on recipe pages allowed users to share content, add notes, add calendar events, as well as add recipes to any of the inbuilt tools.
Personal Collections: Users could save recipes from the magazine as meal plans, shopping lists, or favourites and organise them into their own collections. The tiles for each type of collection were made to look slightly different to subtly distinguish them from each other.
Meal Planner: The meal planner helped users manage their cooking. When a recipe from the magazine is added to the meal planner, prep and cook times are automatically added to a timeline which slide left, right, up and down to customise.
Shopping List: Shopping lists let users build a list of ingredients from any recipe which can be sorted alphabetically or by each individual recipe. Each shopping list can also be shared via email for better access on mobile.
Store Locator: Users can search their area by suburb or postcode to see the stores closest to them. When a store is selected, the store details and a link to get directions are shown.
It’s was now out in the wild, time for step three: Measure…
How to tell users about the update?
If people had already given up on reading release notes like “Bug fixes”, they certainly wouldn’t be reading them now iOS 7 had introduced automatic updates.
Problem: If users aren’t reading release notes, how will they know what updates have been added to the app or how to use them?
There was at least one other place we knew users were looking at, it was the magazine content itself. Specifically, by looking at our analytics, we could see that the page right after the cover was a spot that almost everyone visited. Slipped between the cover and contents a series of videos guides for each new feature was added.
What was driving engagement?
After collecting data over the first month, we could report back to Coles that users were engaging mostly through the favourites, a feature that allowed users to create personalised collections of content. Closely following that, users were also engaging in the area of productivity by using the meal planner.
Before ditching or investing in any features, we’d need to understand why people were using (or not using) certain tools by conducting some qualitative research.
Why was it driving engagement?
Using flurry to analyse the performance after the iOS 7 release was dropped, there were some very encouraging numbers compared to the previous month:
- Active Devices: 7.8% increase
- Sessions: 68.5% increase
- Average time per device: 83.57% increase
- Session length over 30min: 37.36% increase
Problem: However, by looking at the numbers alone, we didn’t really know why these increases were happening. What was really driving more engagement towards the app?
AppStore Reviews
The Appstore reviews were a great way to pool feedback from users as feedback could be order by most favourable and most critical.
One strange part that was noted about using the AppStore for feedback is the strategy some users would employ to get their feedback heard. One user dropped this 1 star gem:
The user seems pleased with the app, but might figure it’s more likely that he’ll be seen if he left a low rating—which it was! This being said, it also might indicate that the overall rating is not something to lean on with confidence.
Support Tickets
Zendesk was built right into the app and provided a wealth of user feedback like being able to print your collections, editing shopping list items, and multiplying serving amounts. More importantly however, it gave us the insight as to why users were engaged?
The answer wasn’t something that we anticipated but turned out to be vital to our approach moving forward. So, what was driving the engagement? The answer: Curtis Stone.
Conclusion
People told us that they loved having Curtis inspired collections, Meal plans and shopping lists to share with their friends and family. The invaluable (and somewhat obvious) lesson learned in hindsight was this.
If you’re going to build new features, you better have content with something that your demographic loves to fill those features up with usage.
Credits
- Commercials — Zachary King
- Project Management — Lisa Walton
- Software Development — Rob Keniger, Tom Adams and Bradly Swart
- Co-designers — Celia Lucas
- Platform — Oomph
My contributions
Research and strategy
Ecosystem Map, Competitive Audit, Stakeholder Interviews, Stakeholder workshops, and User flows
User Experience
Sketching, Wireframing, Iconography and Pattern Library, Prototyping, Heuristic Analysis, User research and Onboarding.
