Marlow Navigation
2025
Transforming Crew Performance Appraisals into a connected operational workflow
End-to-end design across five roles, multiple products and complex operational states.
Overview
One appraisal, five roles and multiple products
I led the end-to-end design of Marlow’s Crew Performance Appraisal experience across five roles and multiple connected products, spanning internal web platforms, mobile experiences and Crew Companion. The workflow moved from questionnaire configuration, to captain assessment, seafarer review, agent input and final operator decision-making.
Because different Product Owners owned different parts of the journey, I also acted as the design bridge across teams, aligning states, terminology, interactions and handoffs so the experience worked as one connected system rather than a series of separate products.
The project required architecting end-to-end behaviors, states, interactions and edge cases across a complex multi-step workflow, while also designing the data-heavy operator experience used to review appraisals and trigger operational actions such as training.
Problem
Operators lacked a clear view of their CPA workload
Operators were responsible for managing multiple Crew Performance Appraisals across the seafarers under their responsibility, often with many appraisals moving through different stages simultaneously.
The existing process made it difficult to quickly understand:
Which CPAs are still open?
Who are they currently waiting for?
Which require my attention?
Which seafarers and vessels do they relate to?
What should I act on next?
Operators also needed to manage the workflow itself — sending reminders for overdue appraisals, completing steps on behalf of another participant, cancelling irrelevant CPAs, creating new ones and eventually reviewing the results to make operational decisions.
Routine follow-up often happened outside the product through email and manual coordination, increasing the effort required to manage the workload.
The challenge was to create a single operational workspace that made a complex, multi-stage CPA process easy to scan, understand and act on.
Research
Turning research into product requirements
Through operator interviews, stakeholder workshops and the service blueprint, I mapped how operators manage CPA workloads, what information they need across multiple seafarers, where they interact with other users, and the edge cases the system needed to support.
The research shaped five areas of the product:
Information hierarchy — separate what operators need to scan across many CPAs from the detail needed for one appraisal.
Workload structure & filtering — organise first by process stage, then show who the CPA is pending with; support filtering around operators’ real daily workflows.
Actions & edge cases — support reminders, completing on behalf, cancellation, creation and exceptional scenarios directly within the workflow.
Role-based access — different operators required different view and edit permissions, affecting both record visibility and available actions.
Scalability — establish a reusable pattern that could later support similar questionnaire → review → decision workflows such as Debriefing and Recruiting.
The key decisions
Two decisions became fundamental to the final design:
1. Structure the workspace around workflow, not database fields
Pending Completion → Pending Operator Review → Archived
with a secondary status showing whether completion was pending with the Captain, Seafarer or Evaluator/Agent.
2. Design a reusable operational model for future products with similar workflow
Stage → Status → Context → Action
The specific data and decisions could change between products, while the underlying pattern remained consistent.
Architecture
Turning the workflow into an operational workspace
From research to product architecture
Using the research and service blueprint, I first defined the overall CPA architecture across the full ecosystem — how the appraisal moved across users, products and downstream business actions.
Only after that did I zoom into the operator architecture, refining how CPAs should be accessed and managed from the operator’s perspective.
Research showed that operators did not approach CPAs in one single way. Their intent depended on the context they were coming from.
This led to three entry points into the same CPA workflow:
1. Task Management
When a CPA reached Operator Review, it appeared in the operator’s daily workload as a task.
2. Appraisals Overview
When the operator wanted to manage the full workload across all seafarers, filter records or monitor progress.
3. Seafarer Profile
When the operator was already looking into an individual seafarer and needed to access historic CPAs, open a specific appraisal or request an ad-hoc CPA.
All three entry points converged into the same CPA review and decision experience.
Designs
Designing the end-to-end operator flows
Once overall CPA architecture was dfined, I then designed the detailed flows behind each entry point, focusing on how operators move from context → review → action.
For Task Management, the emphasis was speed: surface the CPA at the moment operator action is required.
For the Appraisals Overview, the emphasis was workload management: understand volume, stage, status and priorities across many seafarers.
For the Seafarer Profile, the emphasis was context: understand CPA history and initiate a new appraisal while already working within that seafarer’s record.
Defining the table interaction model
The CPA overview was also one of the key use cases we used to define how operator tables should behave across the wider platform.
While designing the CPA table, I worked through recurring interaction patterns such as:
filtering · sorting · column configuration · row actions · status presentation · bulk actions · progressive disclosure · empty/loading states
Instead of treating these as one-off CPA decisions, I used the project to help shape shared table interaction guidelines that could be reused across other products.
This meant the project contributed not only to the CPA experience, but also to the wider design language for data-heavy back-office products.
Designing collaboratively
I refined the solution through weekly sessions with Product, stakeholders, users and Engineering.
I also partnered closely with backend engineers to define where and when data should be fetched, how different operational scopes should be handled, and how to preserve flexibility without compromising the UX.
Ship fast, observe, improve
We followed a ship-fast, iterate-often approach.
Once the core architecture and flows were validated, I prepared the experience for development and worked closely with Engineering to release it quickly.
After launch, I observed operators using the product in their real workflow and used those insights to refine the experience in subsequent sprints.
Research → Architecture → Validate → Ship → Observe → Iterate
This allowed the product to evolve based on real behaviour, while still keeping the underlying architecture stable enough to scale.
