THE CONTEXT & OBJECTIVES

Project Janus got it’s name from the god of ending and new beginnings; this project would try to retain Racing Post’s long earned respect in the racing world, while throwing out the old ways of thinking and doing that were holding them back.

Racing Post aim was to create a B2C product that is the aggregator of all Horse Racing & Sports Better needs which would drive growth across 5 customer and 2 technology goals. The first customer facing product to be released as it is the top revenue generator and the best platform to reach a larger swathe of audience was to be the app. 

On top of the overall objectives, we in the product team, also agreed we needed to make the new product meet some basic levels of accessibility, especially since our current core audience skewed older. And that we needed to consider growth audience on top of core, which brought some “uncomfortable” thinking into a company that assumed most of their monetisable audience was similar to themselves.

THE PROCESS

Starting involved getting agreement on strategy, outcomes, and larger processes. This was the main part of my role on this initiative. My team was still growing, and I was still working with the business at large to change their views on the importance of design and qualitative research; to realise the importance of user input. Trust was still being built on all sides, and at that point the team was still working in an adhoc manner (a hybrid mix of kanban and agile with mixed results). My role was working with the project owners (the Director of Racing, the CTO, CPO and the Editor in Chief) to agree on what good user metrics looked like alongside business metrics and budgets / timelines. This also included getting agreement on that processes would have to change and if they didn’t want to project held up, each of them would have to agree to ways to be involved that honoured all of the objectives, not just their domain.

I worked closely with the Head of B2C Product and the CTO to map out how to approach breaking up the work for such a huge project. We worked with the business owners to help solidify and define overall project objectives and success measures (KPIs) and worked with our Data Intelligence Unit (analytics team) to review current metrics to meet or beat in pursuit of those KPIs. From a design POV, dev was building this platform in REACT, which meant we only had to design the app experience once and we had to consider at a feature and design level which elements would crossover on the common layer with web. As we (product and design) agreed to work in design sprints, we started mapping out the year, the ceremonies and how to brief the sprints.

Then the design sprint workshops… Where post-its went to die. We were dealing with massive features or journeys in every design sprint (definitely not ideal, but the only way to get through the work with such an under resourced product and design team). But, as part of the sprint process, I worked with the research team on how to get customer insights prior to a feature being briefed, and how to run moderated validation testing that anyone in the company could watch, especially key stakeholders. This research layer fundamentally changed how the business worked with design and research, truly hammering home we possessed a ridiculous amount of knowledge about our users.

For the beta release, because we were building the apps on a new tech platform, we could not do a phased release of features – we had to do one big-bang release. As the Android platform had the least revenue impact of our platforms, we started with a “blind” release to 500, 1000, 10,000 users in a forced app update and set up in-app surveys to gage what was working, what was not OK with users and then followed up with qualitative interviews with users about the more egregious issues they were finding with the app. This went on for 4 months as we added more features, corrected journeys and mined the analytics for how the app usage was delivering on the KPIs vs the current app. This process allowed us to be more confident with the iOS beta launch, our money maker platform.

And, of course, the design system and development process.

Racing Post had been through a rebrand the year before, but the full execution of the rebranded assets and design direction was put on hold for this project. Also, the relationship between design and the devs was very siloed – the devs were based in Bulgaria and Racing Post had lost their in-house tech leads, which created a tough atmosphere for the devs to be involved in the early stages of briefing and design development (this was pre-lockdown to start). Through this project, the designers got to start from scratch with the look-and-feel and the design system. And through this work and how the project was being run, it organically created the opportunity to collaborate closely with development yielding better ways working, doing design handover and documentation (thanks, Figma!), and ultimately, through some pain, get the coded assets and designed assets naming conventions aligned.

The result – a new, cleaner, more consistent, better branded interface and more speed efficiency for the devs with the new design kit, along with more collaborative involvement earlier on in the feature design cycle. 

• Highlighting breaking news, video and audio content
• Visually indicating which content needed a subscription
• Dynamic data modules integrated into related articles
• Differentiation between editorial feature content vs tipping and analysis