For many subscribers, the homepage is the place to catch up with the world multiple times a day. In order to find the best combination of editorial voice and visitors’ reading behaviour, the page has undergone regular experimentation and change, ever since its initial launch. We developed a modular design that is able to integrate new ideas quickly, keeping the homepage flexible and current.
I’m part of a dedicated team tasked with improving the overall reading experience and building new storytelling components. Working closely with the newsroom, we find solutions that fit into their process and help them to tell their stories in the best way possible.
As part of the engagement team, we run a series of experiments to improve how readers discover content and move between stories. We focus on specific user journeys to understand when, why and how the user arrives on the page, in order to present them with useful content in the best possible way.
I helped create an experimental story format for an article on the impact of Uber. The reader is invited to take the role of an Uber driver as part of an interactive game, helping them to understand the decision-making process and its costs. I worked on the gameplay concept and initial prototypes, run user testing session and supported the UI design. The game was a great success with more than 216k unique users, a completion rate of 70%, and it became 'Product of the Day' on Product Hunt.
I’m currently responsible for the interaction design on an experiment to create automatic audio versions of all FT.com articles. The goal is to learn if and how our readers engage with audio through a mix of qualitative interviews, onsite feedback and quantitative data.
We designed a set of components and visual language to improve live reporting. Reporting live combines a complex editorial process with different publishing tools, enabling a story to develop in every direction. We set out to connect these formerly fragmented pieces, allowing for a flexible development of the story — whether over hours or weeks.
I helped to define the interaction and design language of video across ft.com and improve the existing video hub to enable seamless consumption.
How we work
I’m part of various multidisciplinary teams that work autonomously on problems and solutions. Our work is user-centred and data-informed with a focus on shipping quickly to learn from actual users. Our process includes Kanban and Lean elements but we aren’t dogmatic about it. Instead, we often follow the steps below, either simultaneously or sequentially, in a way that best fits the problem.
Understanding the user journey and defining the problem
The FT has an excellent customer-research team, whose insights often form the foundation of our work. Together with the product owner, I articulate our initial questions and hypothesis, scan existing insight and refine these into a tangible journey and product vision. This helps us to understand the problem and where it’s located.
Discovering potential solutions
Together with the team and stakeholders, I will run an initial ideation session. We collect a set of ideas and decide as a team which one to explore further, with prototyping and testing. This session helps to hear everyone's perspective and get a shared understanding of the direction and scale of a possible solution.
In parallel, we discuss the best ways to understand the problems with our research teams. This could be an additional data report, qualitative user research or surveys hosted on the site or sent by email.
Design, prototyping and testing to validate our hypothesis
Depending on the complexity of the solution, I either prototype in Marvel, Keynote or Framer, or our developers build a codebase prototype to be rolled out for a small percentage of our users. The usability is tested fortnightly with a group of readers that we invite to the FT.
Defining the UI specification and adding it to our pattern library
Once a solution looks promising, and we are shipping it to a larger group of readers, we refine the UI and interaction design in Sketch or Framer, and use Principle for animations. The handover is done with Zeplin or directly in the browser.
Finally, the new components are added to our internal style guide and to Origami, our white-label component library, used internally across multiple sites and applications.
Revisions and further iterations
Once it has been shipped, our new feature is closely monitored. We use these insights to find out whether the solution has solved the intended problem, and what needs to be improved or changed for the next iteration.