Designing for the 1%: Superyacht Infotainment Reimagined
You might wonder, what exactly is an infotainment system? Think of the screen in your Tesla that displays navigation, battery info, etc. Now, imagine that for a superyacht. That’s YachtEye.
During my second year in SuperYacht Times as a solo UX/UI designer, I had the unique opportunity to help breathe new life into YachtEye, an onboard infotainment system software the company acquired in 2020.
What went wrong with the old system?
The TV interface, dating back to 2009, was overdue for a radical redesign to meet today’s standards. Limited to a TV UI, it was too static and failed to deliver relevant information to guests when needed. On top of that, crew members had their patience tested daily by the old desktop-only CMS.
Who is YachtEye for?
The starting point of this project was already a big obstacle: understanding our two main, mostly inaccessible, users.
On one side, we have guests — 30m+ yacht owners or vacationers — looking to enjoy a private luxury experience. They want information and entertainment at their fingertips.
On the other side, there is the crew, working over 10 hours a day, to ensure guests are happy. They need tools that are quick and easy to use because they have enough on their plates.
How can you empathise with busy users?
To start understanding their world, I took an unconventional approach. Following my colleagues’ advice, I binge-watched some Below Deck episodes. Fast-forwarding through the drama, I got a first grasp of the onboard experience.
After that, I gathered some colleagues who regularly interacted with the target users. Together, we filled out a proto-personas template, establishing a foundational set of needs and pain points to address with the new system.
Defining the New YachtEye
1. Prioritising Features
As the project advanced, the stakeholders’ wishlist of features kept growing. To maintain an agile approach, I organized a prioritisation meeting.
Using a matrix, we identified the quick wins that could be addressed in an MVP, leaving complex and ad-hoc features for future releases.
2. Eliminating the CMS
One key decision that was made early on, was to opt for a CMS-free approach. Granting edit access directly within the main UI offers several advantages: it minimises errors, provides instant feedback on changes, and offers a more intuitive interaction for non-tech-savvy crew members.
Check out my blog post on this topic:
3. Ecosystem Mapping
As the project gained definition, it became evident that we were dealing with a complex ecosystem. Motivated by insights from Designing Multi-device Experiences, I initiated the process of ecosystem mapping.
After creating a custom template for triangulating features, users, and devices, I met with stakeholders to fill it in together.
Sentiment
With a clear vision, it was time to understand the sentiment around it.
After defining a stylistic approach, I teamed up with my colleague Ivo who expertly animated the first teaser of the new YachtEye unveiled at the Monaco Yacht Show.
The video was met with great enthusiasm, prompting us to move forward into the design phase.
Designing the TV UI
The initial futuristic concepts were not usable, and the UI was too complex for an MVP.
We needed a solution with reusable, standardised components that offered dynamism and remote-friendliness. After several iterations, I adopted a common F-shape pattern to display a dynamic feed and supporting graphics based on the yacht’s state.
Key learnings:
- “Make it bigger”: Small, low-contrast fonts hindered readability, especially for distant viewing.
- Icon visibility: Icons, like fonts, lose functionality when they appear similar from a distance.
- Simplicity: Applying Occam’s razor principle, I made space for larger elements, reducing information density, which also helps with short attention spans.
- Standardisation: Inconsistent feed cards can confuse users and slow down implementation. I avoided new layouts unless strictly necessary.
- Affordances: Considering that TVs might also be touch screens, users misinterpreted the itinerary progress bar as a slider, leading to frustration.
This is the first version compared to the latest ready for development:
(Each card on the feed leads to the related feature screen, but I’ll keep this part challenges focused.)
Testing the App
I refined the initial iOS mobile app wireframe through brainstorming sessions with stakeholders and internal testing. My focus was making sure each flow was the most efficient for the crew.
Designed with Crew, for the Crew
At this point, Riejanneke, a former chief stewardess, joined the project. Finally working alongside a potential YachtEye user, I collaborated closely with her, validating all assumptions against her insider knowledge of onboard life.
Thanks to her industry contacts, we started testing the Figma prototype with captains, pursers, stewardesses, etc.
I meticulously organised their feedback on a Notion board, MoSCoW-prioritizing it with developers to identify quick wins.
“Testers Availability Bias”
With sudden and easy access to the crew, what could go wrong? Well, we unintentionally developed a bias towards addressing their needs over those of the guests. That’s how I learned the importance of maintaining a balanced perspective when designing for multiple user groups.
The Cost of Skipping Initial User Interviews
In hindsight, conducting initial interviews with the crew could have better-aligned assumptions with actual needs, potentially saving time and focusing on the right features from the beginning.
Design Handoff
Organising the design system was also challenging due to the variety of devices, light and dark modes, and multiple features.
Since the developers were new to Figma, we collaborated closely to streamline our collaboration.
Strategies included:
- Standardised component naming.
- Established a common vocabulary.
- Added descriptions and Figma annotations for clarity on interactions and other useful info.
- Defined three border-radius values and their applications.
- Utilised one typeface in two weights.
- Implemented an 8px base grid for all devices.
Conclusion
In wrapping up our journey with YachtEye, I have learned valuable lessons in flexibility and bias awareness. Our approach, initially guided by a clear vision, remained open to adjustments as we gained insights and feedback. This adaptability ensures that the final product continues to evolve based on user needs.
Disclaimer: The views expressed are solely those of the author and this is a simplified version for storytelling purposes. They do not necessarily reflect the official position of any other company, organization, or individual mentioned.
