Team Set-Up

This was one of the largest teams that I’ve ever worked in, we had a lot of different departments and stakeholders to work with. The core team (blue cards) were the people I worked with day to day but in order to get this over the line we needed a lot of communication between people that sat outside of our departments

Considerations | New to “New Product Development”

The core editors and many of the team had never worked on launching a new product before. This meant that I was the only team remember with any real previous experience doing so, this push me to create Miro boards and documentation explain processes, how teams should work in order to bring people in more. Some also had no understanding of what a product designer did, so I create further graphics to visualise the process for everyone so they could contribute

Consideration | Design & Desirability Council

The FT had many design departments with differing levels of responsibilities. Some helped create data visualisations for print, marketing assets and others worked on the website and so on. This meant that several design departments within Editorial, Product and Brand all needed to be synced up. This pushed me to create a rolling meeting to share ideas and get buy-in throughout the project.

Product design far more than visuals, value choices were split between product, editorial and design which meant that desirability choices also had their own separate meeting

Back into Discovery…

During the approval of Behind the news concept, I personally believed we didn’t have enough understanding of our target user base and what their needs were.

This pushed me to better understand the segment of information available to use, also gain an awareness of how people consume news on digital platforms and see what options we had create a great reading experience

Research Goal

Methodologies

Reviewing strategies

We had some early signals from the Editorial team on how they wanted to curate stories. Some of their choices made sense on paper but weren’t tested in context with our readers. Additionally, our Product team was hoping to differentiate this product from the FT’s other offerings.

The Editorial team also wanted to select chosen stories by an editor each day / week. This meant that whatever content delivery mechanism we built would need to cater for this

What’s great about FT’s Journalism?

This publication has many different standards that are held and taken quite seriously internally. There’s many documents showing both how and why this is done. The FT has also won many awards for its solid reporting

• Company is held accountable for misinformation

• List of all corrections and claims that were reported falsely exist within the public domain

• Editors are held to account for keeping sources conditional and protected

• All stories are double sourced

• Integrity , accuracy and authority are key to FT

Understanding the Brand

To better understand the rational behind the brand, choices made and what was available across different platforms, I initiated conversations with a range of stakeholders within the company.

I spoke with the head of Editorial design, who looked after print and a range different brand deliverables. The typography and colour systems in particular were quite important across each delivery channel. I also spoke with Design Systems team lead to understand what was available and what wasn’t. Due to the FT being a publication, the brand guidelines are much more built out than most companies and there was differing rules depending on content type and platform

• Spoke with Head of Editorial Design

• Spoke with Design Systems

• System(s) attempt to fit across the portfolio

• 3 typefaces, 1 had never been used in digital before

• Lots of imagery styles and colour applications

• A strong tone of voice - probably not up for debate

• Unique application of story teasers

Types of Reporting

Looking at the types of reporting and article presentation was needed in order to understand what the reading experience could be. The FT has many types of stories but I wanted to better understand the difference in coverage between analysis pieces and everything else (Behind the news looked like it was going to cater to that type)

• 5 types of stories have be a blend of different types

• Reporting from over 40 countries

• Range of topics and reporting types

• Stories can have a mix of tags

• FT stance is to be on slower but informative side

• Editorial view stories in multiple buckets (9 of them to be exact)

• “Slow News”, “Special News” & “Intense News” looked like the main buckets that Behind the news would cover

Story presentation (UX Audit)

I analysed a range of stories and how they were presented on a web format. The components that were live and how they changed depending on factors like “length”, “Interactive Data” and style of writing was very informing. While the website had a lot of legacy components and a uniform structure, it was interesting how many variations existed.

• Reading experience of the pages were pretty different

• All stories are for web grids and layouts

• Unclear of rationale even among brand / editorial with certain elements

• Stories contained ads and many variations of visual type styles

• Stories included; feedback section, comments, topic tags adding, sharing functions, newsletter prompts, large footers, print options, multiple saving functionalities etc

Reading habits

Probably the best part of this discovery for me was the backlog of user research and product analytics showing how readers interact and consume reading experiences across web and mobile.

• Top level jobs to be done across the portfolio of subscriptions

• Some universal core behaviours on how people can consume news

• Scanning / Hunting and Getting up to speed where the 3 mindsets most readers had that affected time of stay

• The analysis pieces where better consumed before 11AM

Behaviours & thoughts of Trialists

Reading sentiment among it’s core readership and people who have trialed the FT and failed to convert gave us a lot of reference points in both user sessions and also behaviours observed within the product

Journey Mapping

Attempted to better emphasise with a new user of this product that doesn’t yet exist. Journey mapped someone downloading an app and someone discovering a newsletter to better understand potential blockers. More clear what decisions a user might have to make before committing to a newsletter or mobile app

Some potential issues

• Multiple Apps from the FT within Appstore

• Discovering a newsletter or signing up for one can be very distracting

• Potential friction for sign up / login

Competitor Analysis (Content / Value)

Looked at some of the more modern newspapers and looked at what they offered and how they presented themselves in terms of offering and value slices. Many publications have aspects in common such as white backgrounds, clear subscription buttons, search functions but differed on many levels regarding content types, primary actions, core sectioning of the product and what their best content was (including how it was presented) The New Yorker for instance has a clear push for showing you it’s print front cover despite it not being needed within an app. Access levels of news and how many free articles are given, what is given without needing to sign up is also very different.

Competitor Analysis (Design)

Studying the pure design of some popular reading apps (not only news app per se) was useful in understand how companies have attempted to show reading content with differing elements.

• A lot of news app still use web views and aren’t native (For Apps)

• Top level navigation structures range quite massively

• The IA’s for article teasers differed a lot from 2 to 6 different elements

• Desktop based news articles showed a lot more content at once but also had far more opitions to change it’s layout

• Lots of flexibility on home screens for native comments but not for web

FT’s current app

Having a quick audit on FT’s current live iOS app and chatting to members of that team helped us understand some of editorials needs over the years better including common user problems that they’ve had to fix

• App had the highest traffic among print and website but had lower time of reads

• App used Webview technology

• An overall a product built with legacy code and many constraints

• iOS and Android with tablet support

• Navigation issues and inconstant interaction design

• Doesn’t support paying or creating accounts

• Some features like Search and Markets data were under developed and left

Tech Landscape

While the product didn’t inherently have a chosen form just yet, the technical innovation team did work on several innovations that shouldn’t be discounted. The CMS that editorial used was very developed and had much functionally that could be pulled from across mobile or web. The team had also worked on a native app and created the foundation for a more streamlined and future facing codebase. The app itself only had a few features on it and was only available within TestFlight.

• Internal CMS was likely to stay the same for MVP

• Native app was in TestFlight, was partially functional

• Devs had built some basic logic and could loading images and text

• No IA, many aspects of article features (Data diz, video etc) still missing

Expert Interviews

Speaking with a range of people working within design roles and data / research roles taught us a lot about the history of previous decisions as well as things that were attempted. Among many insights that live on a Miro board some of the key takeaways from myself were the following

• Lots of silo-ing, company size and head of level relationships

• Multiple instances of builds being pulled due to concern from brand or editorial

• Many examples of invisible stakeholders

• Research teams (technically 4) don’t sync all to often

• Lots of rules, not too much documentation

• Research repository of user insights on notion

• Many dashboard for user performance but editorial but there own data insight team

Key Insights

Areas of opportunity for visual differentiation, native interactions, streamlining article pages, creating minimal reading experiences, working closer with wider team

• Large untapped user behaviour that isn’t design for

• Native apps not done before

• Some level of freedom within the brand

• Competitor landscape - good journalism =/= good product

• Story categories comm’d differently internal vs external

• Journalism integrity trumps every other decision

Creating opportunity statements

Some key questions had started to build up around enhancing value or trying to prevent some user problems, turning some of our key learnings into opportunity statements meant that we could bring others in.

The “Enhancing'“ Workshop

I turned all learnings into hybrid research playback and ideation type workshop was centred around enhancing value and learning from. Invited people from around the business that normally don’t interact with each other, this was actually much harder to organise than it sounds. For some people this was their first workshop so a lot of coaching would be needed

Workshop Goal

• Team alignment

• Better show our opportunities to the wider team

How it went

• Lots of contributions from the engineering team

• We got quite a lot of examples of things that didn’t go to plan in the past

• Gained a range of loose ideas and problems to avoid going into a delivery phase

Clustering & Theming

After the workshop I spent some time thinking over its themes and clustering further problems and opportunities together

• Many un-actioned behaviours for the main app and website

• Inconsistent interactions / patterns / visual treatment was an issue

• Fallout of post agile waterfall and non holistic thinking was inplay for some older products

Key Takeaways

Creating a “reminder” sheet with key problems, issues, delighters and product value drivers really helped in keeping the team focused on what to do next.

• Some key problems and issues to note of when designing the app

• Defending the reading experience of some of the problems were going to be key to making the product feel less scattered

Delivery Plan of Mobile App

At this stage it was settled that an app was likely the best way forward for what the value prop was shaping to be, including what the team was geared up to be able to excite at speed. It would also be an opportunity to move the FT into the future and make bigger bets, using our learnings we created a clear roadmap which still had space for discovery

Why an Internal Launch?

Launching internal was critical due to this being the first product the FT was planning on launching in both a customer facing manner and utilising its journalism. The company has 2000+ people working in over 40 countries so we had a lot of feedback (Mainly from product / design / engineering) but also some from journalists which was great

Feedback Received

After launch we got a range of feedback to address, while most of it was bug related we did receive comments regarding value prop and app execution. Journalist cared a lot about how parts of the app were “Word”, big debates around “Bookmarks Vs Saved” for instance

• Many, many bugs found

• Date changes to home screen

• Lots of copy tweaks

• Article page type formatting

• Article page UX edge cases

Design Brief | Paying for a Subscription

This was by far one of the most challenging parts of the product to design for due to how many different departments needed to be synced up, the FT also had a history of not making the best choices regarding customer facing ways to subscribe digitally

Key Questions

• What product value should we communicate to the user?

• Should we leverage in-app payments?

• How and when should the paywall trigger?

Considerations

• 4 Week Period

• Lots of tech concerns - Not done In-App payments before

• Pricing of the product TBD

• Histroy of discontent with the main website paywall

• Heavy collaboration factor

Process

The end to end process for generating the marketing messaging, creating the paywall, figuring out subscription level access and design all journeys took a large amount of effort and required a lot of testing, research and internal meetings. There was also a soft deadline to get this done due to the hard launch coming up

Hopes / Fears exercise

To kick this project off I ran a mini hopes and fears exercise, this was quite important due to mismanagement in the past for FT’s main subscription pages. By getting commercial, marketing, editorial, research, product, technology all in a room at the beginning of the design phase we were able to effectively map out core concerns and create principles to make sure that goals could be effectively measured

Paywall Research

The behind the news concept aimed at an “Object Deep Diver” type market demographic. This could be served by the FT without needing to create extra journalism or hire additional staff. The aim for the product was to penetrate this market skewing to younger and less business oriented readers. Subscription cost was leaning on the lower end which was a more gut feeling from the team due it likely being able to drive more business returns. The “Trial” options on current subscription was a big entry driver for the FT due to it being quite cheap so having a susbcription that was cheap was something the team was keen on

What’s free, What’s paid

A rather large set of decisions that needed to be made before effective design could beginning was figuring out value offering and when / how it should trigger a subscription. Departments had different ideas on what the product’s pricing should be and how long trial period could last. I went back to the team and gave the group 5 options for what was feasible and what friction it might cause for the reader

Key Decisions made

• Free for 1 month

• 1 free article a day after this period

• No login / sign up required (To reduce friction)

How should we speak about the product

Joint with user research and marketing we did a little exercise on different ways we speak about the product and its value prop. We wanted to focus in on user value / benefit over seeing features which was a common misstep from other paywalls in the news space.

What’s feasible?

I spent a lot of time with engineering to understand what they had to manage, not all journeys and user access levels were easy to manage for. Biggest learning for me was that AppStore Connect didn’t allow some aspects of trialing that marketing were wanting to do, so this required me to feedback a lot of this back in terms of it’s pricing plan. Reader access levels and what should happen to someone if they already bought a subscription to the main FT and log into the Edit, what happens? Engineering were quite concerned about UX cases like this

Iteration (3x)

The design phase then began with a range of team feedback and user testing. This process took the same amount of length as designing the home screen. While we did a lot of extra research the validation and team syncing was big driver in this stream of work

• [Design Exploration] Created Multiple Concepts

• [Design Critique ] Design Critique

• [Iterate] Change design a lot and narrow down to 1 Concept

• [User Testing] for design

• [Iterate] Make a wave of changes based on concpet

• [Team Critique] Get further feedback from marketing, product etc

• [Delivery] Make final changes

User Testing (Second wave)

After testing what I felt was the first good design with users, we learnt that it didn’t perform well at all. Large amount of work was needed in order to correct the direction. Some things did work like low friction to finding the paywall, price was clear and most information people understood even if they didn’t understand how it linked to value

Key Problems

• Product value was not made clear

• Participants are spending too much time trying to understand what The Edit is

• Splitting copy into 3 cards confuses users into reading it as "3 features"

• Confusion around Restore Purchase

• Tray might not be Apple approved

• Confirm details copy isn't clear

Final design for the paywall

After the last round of user testing I changed the design of the paywall massively, having different patterns, interactions and a stronger focus on letting marketing sell the product a bit more. Design overall is far more scannable, more context to what the screen is was also added

• 2 extra rounds of team feedback

• A large range of iteration based off that last wave of user testing

Subscription Access

Due to the Edit borrowing a lot of the CMS and backend from the technical innovation, this meant that subscription were tied to the larger backend that house all other subscriptions. This meant that this subscription lived within a universe of all other FT digital access tiers, so The Edit needed to have logic that accounted for that. Myself and engineering state down and mapped everything out in order for me to go away and design all UX cases

All Subscription Journeys

After designing the paywall and all stakeholders were happy, I started to design each and all journeys based off engineering constraints

Design Council | Illustration

I created an illustration style for this product, little graphics with occasional colour just helped to lift the light pink colour theming of the product. App needed graphical assets to bring to life some pages. I did worked with visual editor to agree on a style that editorial were comfortable with

Design Council | Brand Logo

I had created some exploration for them to look over, they felt strongly that the wordmark should be in a certain manner, even moving the typeface to be symmetrical. Iconography was very simple but it did technically break conversion, we explored a bit but brand didn’t want to stray to far from the FT brand letters