The business problem was we had aging subscriber base and slow growth in younger subscriber number. This problem was accentuated by the decline in advertising revenue in publishing, which made The Economist rely more heavily on revenue from subscription than we had been in the past.
Objective
We set out to create a new product to attract new subscribers
Role
Lead UX, Product coach, Workshop facilitator
Process
Discovery workshop
We started with a week-long discovery workshop in NY, attended by the Product Owner, Scrum Master, Lead Architect and facilitated by me.
The Product Owner started with a draft of an opportunity assessment, putting on paper the assumptions on persona, market size, business and end-user’s problem, value proposition, competitive landscape, our differentiator (why we’re in a good place to do succeed), the urgency and some preliminary plan on how we can move forward.
Then as a team, we did activities to bring out what we know/assume and create alignment with the other team members. We worked together on proto-persona, empathy map, storyboarding.
After that, we reviewed customer support data and survey data to start validating some of our assumptions about our persona and the problem they have.
We ended the week with a hypothesis statement for the product. We assumed that incorporating features that would help readers form the habit of reading The Economist would be the solution.
User Research
To validate few more assumptions on our persona that we identified with, we ran a survey. We recruited participants using an ad on our existing app. We also used the survey to recruit and filter people to interview.
As soon as we got our survey result back, we started scheduling the interviews then run the interviews the following 2 weeks.
The interviews were conducted via Google Hangout. We chose Google Hangout because it allows us to see the interviewees’ facial expression, mimicking in-person setting, which would’ve required a lot more effort and time to schedule.
Google Hangout also allows us to record the session, giving us the ability to engage stakeholders and developers in different locations (we were in NYC, some of the team members were in London and developers were in Slovakia).
Out of this, we refined our persona and hypothesis and started to move to the solution space. We decided to run a Google Venture-style Design Sprint.
Design Sprint
We managed to get key stakeholders from various functions (Editorial, Circulation Marketing, Advertising, Tech) to dedicate 2 days to be part of the Design Sprint in London.
We started on Day 1 by sharing what we had learned about the persona and problem up to that point. We identified key characteristics and values (trusted, finighable, high-quality journalism, progressive, etc.) that differentiate The Economist from other publications. We used this list to guide us as we ideate.
To end the day, we worked together on mapping out the user journey, then settle on couple parts to work on for the next day.
On day 2, we got busy with tons of sketching and some paper prototyping. We broke the participants into 2 teams, each addressing 2 problems. They did individual sketches, then a couple rounds of presentation and critique within their team, then combine the best ideas into one winning solution. They presented the solution as a storyboard (series of screens) to each other.
We ended up with a product idea that presented a limited set of stories from our weekly edition in cards. The users can swipe left or right (Tinder style) to personalize the set based on his interest. This would help our recommendation engine to personalize the reading experience for them. We also incorporated features to help form the reading habit (i.e. reward, progress, trigger)
For the rest of the week, the UX team along with the Product Owner worked together to prototype the solution and prepare for the usability testing, which we had scheduled for the following week.
Here’s the deck that I created to structure our time together:
Usability Study
We ran the usability tests in our New York office. We used an InVision prototype for the test. Between sessions, we get together to share our observation by doing affinity mapping. This allowed us to identify patterns and quick improvements that we could do for the next day.
Once we were confident that our solution was free of major usability defect, we worked with the dev team to build it, then released it to a small number of invite-only users. These are people we interviewed, those who tested our prototype and some survey respondents.
We monitored the user’s behavior using AppSee for session recording and mix panel for measuring the effectiveness of various flows (i.e. onboarding).
After few rounds of iterations, we discovered that our solution could work for existing readers, but we were having trouble getting traction attracting new users.
We went on to try acquiring new users using paid channels (Facebook and LinkedIn) and a landing page describing our product, with disappointing results.
Result
Out of this project, we ended up incorporating some of the features into existing products (i.e. Espresso and the existing app).
We also avoided investing more into a developing and releasing a product that the market didn’t want.
Additionally, the process of developing this product gave us the opportunity to engage various stakeholders (including the Chief Digital Officer and Chief Technology Officer) in a complete user-centered product development process based-on Lean methodology.
More Pictures and Artifacts
