Role
I was lead UX on the product. I led workshops, managed stakeholders, wireframed and prototyped interfaces, defined user flows, and created designs aligned with design systems.
Challenges
When I joined the product development team, Internet in the Car had Version 1 already launched. The product proved itself to be viable - it worked, although there were problems with user experience too. Sometimes, onboarding was too cumbersome, consisting of fragmented journeys between car interfaces, web experiences, and provider requirements, adding up to extra effort for users looking for internet access in their cars. Scaleability was another problem – each new market or manufacturer could create a new unique journey experience, which is not ideal for the product that was supposed to develop across many regions.
I joined the team to help develop the subsequent two versions, extending product capabilities with the added benefit of a streamlined experience.
Solution
When I started the role, it was clear there were challenges ahead. The platform in question was derived from the existing legacy M2M portal that suffered from multiple issues - instability, dated look and feel, low operational speed, and lack of freshness and accuracy of the data shown.
Meanwhile, the product strategy was clear: reduce the workload on our agents, provide fresher data, and move to cloud-based infrastructure where possible. In other words, this project was not a simple design overhaul. It needed to be a product overhaul, rethinking how things operate, and how to deliver them effectively.
Another challenge, one that cannot be underestimated, was scale. Unlike a simple dashboard project with some nice happy journeys, the product in question was an enterprise-grade product with many features and requirements.
Discovery and alignment
In this case, discovery entailed learning about a working product that was currently deployed, analyzing its performance, and finding opportunities for improvement. Aligning with stakeholders, however, was essential in this case to reach a common understanding of what was wrong with the current product and how we could fix it. Many of the workshops I conducted addressed questions of how to navigate the service for different use cases. In many cases, people working in product, engineering, and business understood their slices of the journey experience differently while for the driver, everything was very clear – "internet in the car".
Sketching and user flows
In the initial stages, it paid off to focus less on the UI and more on what the experience entails. I sketched out user journeys and user flows, making it possible to talk about activation, onboarding, switching providers, and management of accounts in terms of actions performed rather than visuals of the process. User flows have proven especially helpful in this case - not only did they show what happened during each journey, but also who does what and when. Most importantly, user flows revealed how experience differs from one market or provider to another or for particular use cases. This allowed us to discuss and agree on user flows, which were then used by everybody - developers, testers, product managers, and stakeholders.
Prototyping
It is hard to emphasise how much prototyping helped in developing the product further. Clickable prototypes created in Figma helped reveal how journey flows should evolve in particular cases and helped us explain our reasoning when discussing potential changes with stakeholders. It was very helpful to demonstrate how users moved from the car interface to a particular web portal, performed actions there, switched to other web pages or portals, and then returned back to the car's dashboard interface. Prototyping helped us find inconsistencies in the journeys and remove unnecessary friction in the process.
Multi-language and multi-provider thinking
The product is aimed at many different countries, so there was a requirement for the experience to work well in a different environment. It means that the product needs to adapt to translation while remaining simple, intuitive, and consistent.
Moreover, since different providers are used in different regions, we need to design experiences that are robust enough to account for such variations in the logic. Finally, we also needed to consider different requirements of various car manufacturers. All in all, it meant a great deal of work to design a product capable of supporting many providers with various regional differences while being accessible and simple for the end-user regardless of their country.
Moreover, since different providers are used in different regions, we need to design experiences that are robust enough to account for such variations in the logic. Finally, we also needed to consider different requirements of various car manufacturers. All in all, it meant a great deal of work to design a product capable of supporting many providers with various regional differences while being accessible and simple for the end-user regardless of their country.
User testing
User testing helped us validate concepts for many different use cases – especially when it comes to onboarding and providers. Service logic is not transparent to users, which is why it is crucial to see where they might encounter a difficulty, hesitate, or expect something completely different from what they are offered. We conducted task-based tests and walk-throughs to analyse user performance for such use cases. Pairing user flows and clickable prototypes with testing sessions was especially helpful – when the prototype allows demonstrating an entire journey, it is easier to observe user behaviour and evaluate performance.
Design system contribution
Once it becomes clear how particular patterns work for onboarding, selection, confirmation, and account management, we can incorporate them into the design system, allowing other team members to benefit. By creating reusable patterns, we save a lot of time and increase productivity, thus making our work more efficient.
Outcome
It's impossible for me to cite hard numbers here. However, I can safely say that the efforts of my team and me contributed to fewer defects, faster handoff and implementation, better task completion rate, and higher functional capability of the journey features.
Apart from improving the product itself, the project also helped transform the way the team works – increasing collaboration, improving communication practices, developing design systems mindset, and becoming better at decision-making.
For me, this was a great example of how product design leadership is supposed to look like. It was not just about making the screens pretty. It was about creating a condition for success of a product and its development over time.
Reflection
Reflecting upon the project after the fact, there are two things I would definitely do differently.
First of all, I would focus more on quality. Working on a complex product in a highly technical domain makes it tempting to neglect quality to save development time. However, in an enterprise environment, quality is always important.
Secondly, I would spend more time working with our engineers. The closer designers and engineers work in such platforms, the better product-related decisions can be made.
