CASE STUDY — RESEARCH TO LAUNCH · 2023 - 2024 · MULTI-TENANT ENTERPRISE SAAS
Performance monitoring and decision support for Mediterranean Shipping Company (MSC) — 650+ vessels, compliance reporting cut from 7 days to 2
A comprehensive documentation from research to launch. Read in full or in parts, depending on your time.
Confidential — Some information in this case study has been omitted or modified to comply with my NDA.
650+
Vessels Onboarded
7 → 2 Days
Compliance Reporting
450+
Active Users
My Role
Lead Product Designer
Year
2023 – 2024
Industry
Maritime SaaS
Timeline
6 Months
Team & collaboration
Who I worked with and how
01
Lead Product Designer (Me)
End-to-end design ownership. Research · UX · UI
02
Product Manager: Sigrid (Norway)
Feature prioritisation · Sprint planning · Stakeholder alignment
03
VP of Maritime: Anders (Norway)
Strategic direction · Feature design reviews every sprint
04
Solution Architect: Bappaditya (Bangalore)
Technical feasibility · Data architecture decisions
05
Technical Lead: Prabhu (Bangalore)
Component behaviour · API constraints · Handoff
Introduction
Why featured
About me
I am Devendar, a Senior Product Designer at Kongsberg Digital (now rebranded as Falkor), Bangalore. I joined Kongsberg Digital in April 2021.
Why this case study?
This is a case study of a launched product, I have started designing in year 2023. A comprehensive documentation that covers majority of my design work and design decisions taken for this product. The field research was conducted across 3 countries, with 13 user interviews and 13 contextual inquiry sessions with vessel operators, and a product that today runs with 650+ vessels worldwide."
Outcome and Impact / TL;DR
I led design for Vessel Performance Merchant from research to launch, 2023 to 2024, a new SaaS product built for MSC's fleet of 500+ merchant vessels. I ran 13 user interviews and 13 contextual inquiry sessions across Geneva, Oslo, and Gothenburg, and I turned three findings from that research into the product's core features.
I designed and shipped the MVP in 6 months, from kickoff in July 2023 to pilot launch in January 2024, and the product reached full scale by April 2024. Today it runs on 650+ vessels with 450+ active users, and it cut monthly compliance reporting from 7 to 10 days down to under 2 days per vessel.
Background
Context and drivers
Kongsberg Digital and MSC partnership
In 2022, MSC (Mediterranean Shipping Company), the world's largest container shipping line, signed a five-year contract with Kongsberg Digital to digitalise their entire fleet of approximately 500 vessels. Maritime Executive
The agreement had four goals
Collect and contextualise vessel data on cloud from the shore office.
Use performance applications to reduce fuel consumption and optimise voyage.
Enable correct and efficient vessel data reporting to regulatory authorities.
Increase crew safety and welfare through stable connectivity.
Kongsberg Digital offered two products
Vessel Insight, a cloud data infrastructure service that collects and contextualises data sent from a ship to the cloud.
Vessel Performance, an application that gives vessel operators the analytics and insights to reduce fuel consumption and optimise voyage.
Then, why new product?
After more than a year of running on MSC's fleet, the Vessel Performance application was not delivering the results MSC needed. Fuel consumption was not reducing. Voyage optimisation was not improving. The reporting capabilities were limited.
Key Driver 1: The operational problem
Vessel Performance was originally built for offshore vessels. Offshore and merchant segments have distinct differences in terms of operational profiles and optimisation requirements.
Offshore vessels operate in the oil and gas industry on shorter, dynamic voyages. They often need to hold a fixed position at sea for long periods to perform specific operations – also known as dynamic positioning.
Merchant vessels undertake long and stable voyages to transport the world’s cargo, on planned voyages scheduled weeks in advance and depending on the contract, they either follow the same routes repeatedly or work towards the spot market.
The operational differences between the Offshore and Merchant segment are significant enough that a single application cannot serve both well.
Key Driver 2: The regulatory pressure
At the same time, The International Maritime Organization (IMO) enforced "IMO 2023 rules". Calculate Energy Efficiency Existing Ship Index (EEXI) and establishing an annual Carbon Intensity Indicator (CII) rating.
EEXI and CII was additional compliance along with MRV, DCS reporting. The non-compliance faces heavy penalties.
Kongsberg Digital saw the strategic opportunity, and MSC's direct request for a purpose-built merchant performance solution accelerated the decision to build Vessel Performance Merchant from scratch.
The Case for Research
Influence and alignemnts
Kick-off
In July 2023, Product Manager, Performance Applications, conducted first presentation about merchant shipping customer feedback, frustration and a 19 point wish-list for new Vessel Performance Merchant.
I have been appointed to lead this new product design initiative. The first task for me was to study customer feedback. I have spent time in desk research to understand why new product (explained above).
The goal when we started
A Vessel Performance Merchant application to enable vessel operators view vessel’s high frequency sensor data, vessel’s historic data analytics and enables download compliance reports.
I was not convinced
The wish-list had 19 performance indicators for merchant vessels. It came from MSC's management, compiled into a shared Excel sheet.
The wish-list had not come directly from the people who would use the product every day. It came from MSC's management. I felt it was shaped more by business ambitions than by what vessel operators actually needed.
The overall business goals were clear. But how both companies can successfully achieve these goals and ambitions was unclear at this stage.
I knew what skipping user research at this stage would cost:
Misreading user needs as business needs.
Product decisions built on assumptions.
Ambiguity that would follow the team all the way to launch.
If the product failed to meet customer expectations, the cost of that failure would far exceed the cost of doing the research right.
This was the moment I decided to push back.
First attempt to convince product leadership for research
My first step was to present a design strategy to the VP Maritime and the Product Manager. I made the case for conducting user research before any design work began.
Product leadership told me to work with an alternative — interview customer success managers instead and gather requirements through them.
I did not think that was enough. Customer success managers know what customers complain about. They do not know what vessel operators do at their desk every day.
I was not able to influence product decisions, but I had a Plan B.
Individual interviews takes time, so I decided to run a quick discovery workshop instead to move faster and collect first set of data.
Discovery Workshop 1
I facilitated a structured discovery workshop with nine participants. The group included customer success managers, growth managers, and a product manager from three shipping companies. The session ran for 180 minutes on a remote whiteboard.
I asked every participant two questions. What frustrations and pain points are you hearing from customers in your weekly meetings? What are the important performance requirements for merchant vessels that the existing application is not meeting?
After the session I extracted the transcript, clustered the information, and prepared a report. The findings were full of performance indicator requests and feature wishlists. There was very little about what vessel operators actually needed to do their job.
The output confirmed my concern. The discovery workshop had produced KPI focused features, not user needs.
Synthesis from discovery workshop 1 — KPIs and potential feature drivers.
Second attempt to convince product leadership
I went back to product leadership. This time I had data from the workshop to back my argument.
I presented a theme drawn from the findings. There was ambiguity. There were multiple priorities with no clear direction. More than 60% of the product decisions at this stage were assumptions, not rationales.
I made one argument to the VP Maritime and the Product Manager.
The cost of failing to meet customer expectations would be far higher than the cost of investing in field research with real users.
It worked. I got approval to conduct field research in Geneva, Switzerland. Oslo, Norway. and Gothenburg, Sweden.
Preparing for Field Research
The foundation
Research strategy
I applied for a visa and started preparing a research strategy while the Product Manager recruited vessel operators from three shipping companies across three countries.
No. of interviews
13
Method
1:1 Semi-structured
Interview length
60 minutes
User profiles
Vessel Operators, Fleet Energy Efficiency Coordinator, Fleet Energy Efficiency Manager, Fleet Performance Expert
Unser interview session outline
05 min - Intro, Purpose, How KDI will store and handle data
50 min - Interview to discover based on objectives
05 min - Wrap up & share what's next?
User interview objectives
Discover "What are your day to day activities at work?"
Discover "How digitalization can help you to be more efficient at work?"
Discover "What is important to see in a cloud app in terms of performance KPIs of a vessel?"
Discover "Answers to follow-up questions and anything which is not covered."
Contextual inquiry
Conduct contextual inquiry with each user in a normal work setting; vessel operator using Vessel Performance Offshore while sitting in their office. Ask each user to perform set of tasks and record observation.
Discovery workshop 2
Before flying to Geneva, I requested one more session. I conducted a workshop with MSC's management stakeholders; the same people who had originally shared the wishlist and feedback.
The goal was to understand their expectations, business goals, and decision drivers directly. The workshop helped me prepare specific questions and sharpen the research direction before meeting real users for the first time.
Situation → Decision → Opportunity = Early concept wireframe
During the workshop with MSC management made a direct ask. They wanted to see something tangible before the field visit to Geneva.
I saw an opportunity. I created concept wireframes to test with vessel operators during the field research. Three concepts:
A screen to show a vessel's real-time sensor data.
A screen to view historic data analytics for fuel consumption.
A screen to present the data in a reportable format.
This meant I could test these early concepts and record first reactions from real users alongside the interviews.
Research Geneva, Switzerland
User Interviews
Geneva, Switzerland — 4 September to 5 September
On 3 September I travelled to Norway. On 4 September I took an early morning flight to Geneva along with the Product Manager, the Director of Customer Success, and a Customer Success Manager.
Photo: MSC Headquarters · Geneva, Switzerland · September 2023
Day 1: Setting the stage
Before the sessions began, the Director of Customer Success presented to the MSC team to set the stage, define expectations, and explain the goal of the research visit..
Day 1: Contextual inquiry
I facilitated two contextual inquiry sessions. I asked each vessel operator to perform three tasks on the existing Vessel Performance application.
Navigate and find the vessel's fuel consumption from the last five days.
Navigate and find the vessel's location history from the last five days.
Extract fuel consumption and power consumption data into a file and check it for correctness.
I observed how they worked. Where they struggled to find information. How they navigated. And where the terminology in the application did not match the language merchant vessel operators actually use.
Day 1: User interviews
After the contextual inquiry sessions I conducted two user interviews. I prepared diary notes for each session. Midway through the day we agreed that both the Product Manager and I would ask questions during interviews, and record voice with the participant's consent.
Day 1: Dinner and conversation beyond formal interviews
In the evening of Day 1 we had dinner with vessel operators and MSC management. The conversation moved beyond the formal interview setting. We talked about day to day life, what a good day at work looks like, what a bad day at work looks like. That dinner gave us knowledge about users that no interview script would have uncovered.
Day 2: User interview and wireframe presentation
Day 2 was three more interviews. One participant pair requested to be interviewed together as they shared similar technical knowledge. It had minimal impact on the quality of data so I agreed.
Post lunch on Day 2, I facilitated a concept wireframe session. I presented the early concepts to vessel operators one by one and recorded their first reactions. The impression was positive. The concepts were aligning with the needs I had already observed in the contextual inquiry sessions.
Connect CMS Image fields (Image 1–10)
Diary notes from user interviews with 5 participants.
Research Oslo, Gothenburg
User Interviews
Oslo, Norway and Gothenburg, Sweden — 7-8 September
On 7 September I conducted four user interviews and four contextual inquiry sessions with vessel operators at a shipping company in Oslo, Norway.
On 8 September I conducted four more interviews and four contextual inquiry sessions with vessel operators at a shipping company in Gothenburg, Sweden.
By the end of 8 September I had completed 13 user interviews and 13 contextual inquiry sessions across three cities with vessel operators from three shipping companies.
Research Synthesis
Raw data to insights
Synthesis workshop, Oslo, Norway
On 9 September I went to Kongsberg Digital's Oslo office. I facilitated a full day synthesis workshop with the Product Manager and stakeholders.
The goal was to review everything collected across 13 interviews and 13 contextual inquiry sessions. Identify anything crucial that may have been missed. And agree on the next steps before flying back to India.
That was a wrap of the field research. I flew back to Bangalore the same evening.
Synthesis, Bangalore, India
I spent two full days on synthesis. This was an intensive exercise. I worked through multiple rounds — extracting patterns from 13 interview transcripts, clustering diary notes, separating user pain points from domain knowledge, and mapping what vessel operators said against what they actually did during contextual inquiry sessions.
I prepared synthesis boards for each participant, mapping to research objectives.
Interview synthesis board from diary notes. Same prepared for each participant.
Synthesis of user interview data
I then built a consolidated view across all Geneva participants — clustering findings into five categories. Role and responsibilities. Goals and motivation. Potential features and expectations. Pain points. Domain knowledge.
Each round of synthesis was reviewed with the Product Manager to refine the findings and pressure test the conclusions. Nothing was taken forward as a product decision without being traceable back to something a vessel operator said or did during the field research.
Consolidated view
Click on image to zoom.
Synthesis of user interviews data: themes across roles, goals, potential features, pain points, and domain knowledge.
Synthesis of user interviews data: themes across vessel performance KPIs.
Research Insights
Mapping to product
Research data to new opportunity: Three findings that changed the product
Three findings came out of the research that were not in the original plan. None of them were in MSC's wishlist. All three became core features of Vessel Performance Merchant.
Vessel operators were spending 7 to 10 days preparing one monthly compliance report per vessel.
MSC's fleet had 500+ vessels. That meant thousands of person-days every month on manual reporting. Vessel operators were manually filling data into DNV format spreadsheets, verifying figures, and sending reports to regulatory authorities.
The fleet size was growing. These challenges were likely to become more difficult to manage. This finding directly led to the automated monthly report generation feature.
Opportunity — Automated Monthly Report Generation
Vessel operators had no way to passively monitor 500+ vessels without sitting at a screen continuously.
There was no alert system. If a vessel's fuel consumption crossed a threshold, no one was notified. Vessel operators had to actively look at the data to catch anomalies. With a fleet of 500+ vessels this was not sustainable. This finding directly led to the Alarm Management feature.
Opportunity — Alarm Management
Vessel operators on shore had no way to collaborate directly with crew onboard the vessel.
Decisions made on shore could not be communicated back to the vessel in context. There was no shared view between shore office and the ship. This finding directly led to the concept of a vessel onboard application for crew collaboration.
Opportunity — Vessel Onboard Application
Persona
After synthesis I built a persona from the research data. The Fleet Energy Efficiency Coordinator — the primary user of Vessel Performance Merchant. Responsible for monitoring fuel consumption, power, and emissions across a group of vessels. Preparing monthly compliance reports manually for each vessel. Working under regulatory pressure with limited tools.
This persona guided every design decision that followed.
Feature mapping to user needs and business goals
I mapped each research finding to a user need, each user need to a product feature, and each feature to a business objective. Nothing on the feature list was added without a direct line back to something a vessel operator told me during the field research.
Feature — Vessel Sensor Data Current View
User Need
Vessel operators need access to the vessel's high frequency sensor data on cloud, real time.
Business Objective
Continuous monitoring of vessel current state and performance for decision making.
Feature — Vessel Sensor Data Historic View
User Need
Vessel operators need access to vessel data analytics for performance KPI trends over time and valuable insights.
Business Objective
Optimise voyage decision making to maximise profit and crew safety.
Feature — Auto Email Monthly Vessel Performance Report
User Need
Vessel operators need anomaly free vessel data for reporting.
Business Objective
Enable correct and efficient vessel compliance reporting to regulatory authorities to avoid heavy penalties.
Feature — Alarm Management
User Need
Vessel operators need passive monitoring of vessel performance rather than actively looking at the screen.
Business Objective
Utilise vessel operator time efficiently to improve vessel performance and maximise profit.
Feature — Vessel Onboard Application
User Need
Vessel operators need to collaborate with vessel crew for implementing voyage decision making onboard.
Business Objective
Increase crew safety and welfare through stable connectivity.
From research to product decisions
On 13 September I facilitated the first of three workshops with the engineering team in Bangalore. Nine engineers, one solution architect, and the Product Manager. The goal was to present the research findings and answer three questions:
What are we going to build?
How are we going to build it?
For whom are we going to build it?
The outcome of three workshops was a scoped MVP. Five core features. A pilot launch target of January 2024.
Ideation workshop — problem statement, how might we, and potential features identified.
Ideation workshop — Must have MVP features, can wait and future release features.
Ideation workshop — Task flows of Vessel Performance Merchant MVP features
Conflict and Resolution
Design advocacy
The Alarm feature conflict
The engineering team pushed back on including the Alarm Management feature in the MVP. The solution architect and engineering lead felt it was too complex to build in three months and requested it be moved to a later release.
The Product Manager refused. The Alarm Management feature was central to the upselling strategy and crucial to test during the pilot.
I was caught between two sides.
Alarm feature was a primary feature for the upselling strategy — a direct path to selling a second product, the vessel onboard application, to shipping companies who needed their shore teams and onboard crew to act on the same alerts.
The partial win
I suggested a middle path. Park the alarm view feature in the vessel onboard application for Phase 2. Keep the Alarm Management feature in the cloud application for the MVP but detail it fully with all functionality.
Rationale: Alarm management feature require intensive usability testing, and later training users for how to create alarm for each KPIs, how to follow logic and rules while creating alarm, how cloud to onboard collaboration work using 2 different applications. Onboard application can follow after this.
The Product Manager agreed on that condition.
The solution architect and engineering lead were still not convinced.
My suggestion to test feasibility through wireframes.
I suggested a middle path. Build and test a low-fidelity clickable wireframe prototype of the Alarm Management feature first. Let the prototype answer the engineering team's doubts before making the decision.
Everyone agreed to test alarm feature feasibility through wireframes and then decide the scope.
The alarm logic design
I spent a day designing the prototype. The Alarm Management feature allowed vessel operators to create custom alerts for any performance indicator. A vessel operator selects a KPI data point, a comparison operator, and a threshold value.
Multiple conditions can be combined using AND or OR logical operators. If a vessel's fuel consumption crossed a set limit, the system would notify the operator automatically.
The resolution
I facilitated a brainstorming workshop with eight participants. One Product Manager, one solution architect, one engineering lead, two full stack engineers, one backend engineer, and one QA engineer.
The prototype answered their questions, cleared the ambiguity, and resolved the disagreement.
The whole team aligned. The Alarm Management feature was included in the MVP.
High-fidelity UI — Create New Alarm feature
Vessel Performance Merchant - Create New Alarm feature overlay modal.
Wireframing & Prototype
Insights to interface & experience
Wireframe Testing
I began with low-fidelity paper sketches, discussing concepts iteratively with the Product Owner before moving to greyscale wireframes in Figma.
I built a clickable early wireframe prototype and ran three rounds of testing, going back and forth between sketches and Figma until the concepts actually well aligned with real users needs.
Every round changed something; navigation, data density, how we labelled engine states, where the map lived. Nothing stayed where it started.
Designing VPM Main Dashboard - Vessel Sensor Data Current
I designed one feature at a time, starting with the Vessel Sensor Data Current View. I tested wireframes directly with vessel operators — the same people I had interviewed in Geneva, Oslo, and Gothenburg.
Each round of testing produced specific feedback. I documented what changed between each round and why. Nothing moved to the next iteration without a clear reason traced back to a user observation.
Three rounds of testing on the Current View alone before the design was ready to hand to engineering.
Research data to KPI visualization on user interface
Synthesis of user interviews data: themes across vessel performance KPIs.
Low-fidelity wireframe iteration 1
Wireframe iteration 1 user testing results - Vessel Sensor Data Current dashboard
Low-fidelity wireframe iteration 2
Wireframe iteration 2 user testing results - Vessel Sensor Data Current dashboard
Low-fidelity wireframe iteration 3
Wireframe iteration 3 user testing results - Vessel Sensor Data Current dashboard
High-fidelity UI of Vessel Sensor Data Current dashboard
Vessel Performance Merchant - Main Dashboard - Vessel Sensor Data Current.
Constraints and Design Decisions
Feasibility alignments
Constraints and Decisions
Every design decision in Vessel Performance Merchant was made inside real constraints. Data quality issues coming from vessel sensors. Strict maritime compliance report formats. A three month MVP deadline. The need to show all information on one screen without pagination. And no existing icon library that worked for maritime data.
Each constraint had a direct design response.
Constraint
Data quality was inconsistent. Sensor data arriving from vessels had gaps, frozen values, and anomalies.
Design Decision
I annotated data quality directly on the user interface. Vessel operators could see exactly where data was reliable and where it was not.
Constraint
Compliance reports had to follow strict maritime authority formats; MRV and DCS.
Design Decision
I worked with Kongsberg Digital's DNV SME's and designed exportable file format of MRV and DCS reports. DNV is the international maritime classification and certification body.
Constraint
The MVP had to be ready in three months with a pilot launch in January 2024.
Design Decision
I designed the Vessel Sensor Data Current View first and shipped it to engineering immediately. Each feature design was completed and handed over ahead of the development sprint.
Constraint
All information had to be visible on one screen. Vessel operators could not scroll through pages to find data.
Design Decision
I chose data density over simplicity. Every relevant data point on one screen. No hiding information behind extra clicks.
Constraint
The existing icon library had no maritime icons. Generic icons were too small and unrecognisable for vessel data.
Design Decision
I designed custom maritime icons for the application.
Custom maritime icons
Custom maritime icons for Vessel Performance Merchant KPI dashboard.
Launch and Outcome
The success
Product announcement — November 2023
Kongsberg Digital publicly introduced Vessel Performance Merchant in November 2023. Read more on: Vessel Performance Information
Pilot launch and usability testing — January 2024
Vessel Performance Merchant went live with real users in January 2024. The same vessel operators I had interviewed in Geneva, Oslo, and Gothenburg were among the first to use the product and participate in usability testing.
Successful completion three months of usability testing with real users followed before full scale release.
Full scale launch — April 2024
Vessel Performance Merchant launched at full scale in April 2024. The product is listed on the official Kongsberg Maritime product page.
Outcome
650+ vessels onboarded and subscribed. Vessel Performance Merchant became one of Kongsberg Digital's highest performing products in the Vessel Insight SaaS product suite.
Monthly MRV and DCS compliance report generation was reduced from 7 to 10 days to under 2 days per vessel, including verification after receiving the automated email reports.
Today, Vessel Performance Merchant is used by 450+ active users globally including users from world's largest shipping company MSC.
High-fidelity UI — Vessel Sensor Data Historic dashboard
Vessel Performance Merchant - Vessel Sensor Data Historic dashboard
Testimonial
From LinkedIn Recommendations