In Formula 1 Racing and UX Design, knowing the WHY and HOW is essential
Share
Building a digital experience is a high-speed race.
Alfonso de la Nuez, co-founder and co-CEO of UserZoom, discusses the value of knowing the WHYs and HOWs in product UX Design, using a recent example from Ferrari’s ‘big data fail’ from the opening race of this year’s Formula 1.
To put the following article into context, here’s Alfonso’s video introduction…
Like millions of auto racing fans, I watched the 2019 Formula 1 debut in beautiful Melbourne, Australia a couple of weeks ago. As usual, there were super high expectations for every team, especially for the top ones like Mercedes and Ferrari.
Mercedes has dominated the F1 world for the last five years, winning both team and drivers’ championships. For Ferrari, on the other hand, it’s been a very tough decade and they haven’t won a title since 2007. Needless to say, the opening race was very important for Scuderia Ferrari. Well, it didn’t go that well. They just had no competitive pace. Worse yet, they didn’t know why. And it’s something that happened towards the end of the race that inspired me to write this article.
Sebastian Vettel, Ferrari’s main driver, found himself lagging quite far behind the leader of the race, Valeri Botas, who drives (you guessed it!) for Mercedes. After trying everything he could, he used the car radio to communicate with the engineering team and asked something that really caught my attention: “Why are we so slow?”
A pretty embarrassing moment. Given the vast amount of data (see figure below) these teams are able to collect, plus all the pre-season preparation, car testing, analysis, and of course huge budgets available to Scuderia Ferrari, when the driver asked the simplest question there was still no explanation available.
Infographic by Forbes
To be fair, it is a pretty complicated business, I can assure you. Shaving off just 0.1 seconds per lap may cost the team hundreds of hours of work and millions of dollars. It actually reminds me of the similarities with multi-million dollar budget digital properties, such as any one of today’s complex and highly interactive websites, corporate intranets, mobile apps, etc. Trying to increase conversion rates is very complicated. Designing great apps is very tough business.
Surely the Product Managers and/or owners of these properties are able to collect large amounts of data through web traffic analytics tools (such as Google Analytics or Adobe Analytics), they collect thousands of comments from actual visitors feedback, measure NPS, they certainly spent lots of time and effort to build and release the product and have dedicated million-dollar budgets available.
Yet… when it comes to nailing the reasons why things may not work as well as they should and why the ROI is not quite there, often it’s really hard to come up with the right answers. Also, when it’s time to optimize the design and invest some more budget, there’s not a whole lot of clarity or confidence around prioritization in the product roadmap.
This is because, like in the F1 example, most of the data (big data) is focused on WHAT is happening, not on the WHY or HOW. For this, they need to conduct user research. Specifically, qualitative research.
The F1 team members (engineers, race driver and aerodynamics designers) need to sit down and discuss in detail how the end user of the product (the driver) feels about the car setup, tire selection, as well as the pit stop strategy.
The makers of the car need to combine data collected from the many sensors they add to the car, plus have a deep and detailed conversation with the driver in order to make the best decisions. Those conversations happen on a very frequent basis -pretty much every practice and every race. Then once some decisions and adjustments are made, they need to observe the driver at action again and see the differences.
Can you imagine F1 engineers and designers making million-dollar decisions based solely on the data provided by the sensors (or the ‘WHAT’ data)? That would be pretty incomplete and extremely risky.
I see the resemblance to the design of a digital product: Instead of a race car, we have a mobile app, or a website. Instead of car sensors, we have a tag in the code to track aggregate traffic data. Instead of a race driver, we have the end user. Instead of races, we have design sprints.
Also like in F1 racing, there’s a very important part of the decision-making process that can only come from frequently engaging with the end user. In F1, obviously the driver is extremely important to the success of the team. In digital product design, the quality of the end user’s experience is also crucial, often determining the difference between overall success or failure.
There was a time when both F1 teams and PMs had a really hard time figuring out the WHYs and HOWs of user behavior. It was expensive, time-consuming, limited to certain geographic locations, etc. But today thanks to lean UX research methodologies, focused on quick decision-making which uses online sourcing of testers and UX insights platforms, many of these challenges and limitations are eliminated and the right decisions can be made cost-effectively and quickly.
Lean UX research has automated the process in so many ways, simplifying the setup of the study and the collection of data, enabling scale and speed in UX testing. So much so, that in a time where UX is such a valuable, competitive advantage, one wonders why any team would make decisions without it.
Knowing the WHYs and HOWs is absolutely essential to great product UX Design. When the team wonders, “Why are we so slow?” we should be able to make educated, user insight-based decisions and provide answers quickly. Like in F1, building a digital experience is a high-speed race. You’d better derisk the journey with solid and continuous user research all along the way.
