Marlow Navigation
2024
Allotments — digitising a manual financial workflow
Designing a mobile allotments experience that gave seafarers more control over how they send and track money, while removing multiple manual handoffs behind the scenes.
Overview
Allotments are how seafarers allocate part of their salary to beneficiaries, most commonly family members.
Previously, the process was highly manual. A seafarer completed a form and gave it to the captain. The captain collected allotments from the crew, scanned them and sent them to Marlow by email. An operator then reviewed and forwarded them to the financial team, who processed each request manually.
We brought this process into Crew Companion, allowing seafarers to manage their allotments directly from the app and send requests into the financial workflow without relying on the captain or operator as intermediaries.
The challenge was not simply digitising an existing form. I needed to understand how seafarers actually use allotments, what information matters most to them, and what financial information our systems could reliably expose.
Problem
The existing process created unnecessary dependencies between multiple people and systems.
For the seafarer, there was very little visibility after submitting an allotment. They often depended on others to know whether money had been successfully processed.
This mattered because allotments are frequently used to send money to a spouse, children or other family members at home.
The opportunity was therefore bigger than moving a paper form into an app:
How might we let seafarers manage their allotments independently while giving them confidence that their money has been processed successfully?
Research
Understanding the seafarer behavior
I spoke with seafarers and analysed existing allotment data to understand how the mobile experience should be structured.
The main question for the navigation was:
What does a seafarer need to see or do first and understand quickly?
The research showed that the highest-priority information was:
1. Balance
Seafarers wanted immediate visibility of their financial position.
2. Recent and active transactions
They wanted to quickly confirm whether recurring or recent allotments had been processed successfully.
3. Further actions
Creating a new allotment or managing beneficiaries was important, but less frequent than checking existing activity.
As part of this research, I also looked at how often seafarers created new beneficiaries versus sending money to people they had already used before.
Around 80% of allotments were recurring or sent as one-off payments to an existing beneficiary.
This confirmed that beneficiary management should remain secondary in the navigation, while recent activity and transaction status should stay prominent.
Concept development
Concept Development
Because the navigation model in our mobile app was already established, concept exploration focused less on alternative architectures and more on UI hierarchy and interaction design.
Level 1 — Allotments home
Research showed that seafarers primarily wanted to understand their financial position and quickly check whether their allotments had been processed.
This shaped the hierarchy of the first screen:
Available balance → key actions → transaction history
The balance sits at the top as the highest-priority financial information. Create Allotment and Beneficiaries remain immediately accessible as secondary actions, followed by the transaction list.
The list supports continuous scrolling across active, pending and completed allotments, allowing the home screen to work as both an overview and transaction history.
Level 2 — Completing a task
Secondary pages and page sheets are used when the user moves from checking information to completing a focused task.
Flows such as creating an allotment or adding/managing a beneficiary move into this level, removing the bottom navigation and giving the user a more focused experience.
Level 3 — Contextual actions
Bottom sheets and dialogs are used for actions that don't require another full page, such as confirmations, option selection, editing an instruction or handling a specific transaction action.
This keeps deeper interactions contextual without adding unnecessary navigation depth.F
I’d keep it almost exactly like this in the case study. The strongest line is the first one because it makes clear that you didn’t force ideation where it wasn’t needed; you used an existing product pattern and focused design effort where it added value.
Design
01 — Adapting a proven mobile pattern to the research
Crew Companion already had a tried-and-tested mobile navigation pattern, so there was no need to create a new architecture for this feature.
Instead, I adapted the research findings to that existing structure.
On the main allotments screen, the hierarchy became:
Balance → key actions → transaction history
The balance sits first because it was the highest-priority information for seafarers. Create Allotment and Beneficiaries follow as secondary actions, while the transaction list supports continuous scrolling through active, pending and completed allotments.
For deeper tasks, such as creating an allotment or managing a beneficiary, we used secondary pages/page sheets where the user could focus on completing the flow without the bottom navigation.
Smaller contextual actions, confirmations and selections were handled through bottom sheets and dialogs, avoiding unnecessary navigation depth.
This allowed us to keep the experience consistent with the rest of the app while adapting the hierarchy to the specific needs uncovered in research.
Balance
Actions
Transaction list
02 — Designing around real usage patterns
Because most seafarers repeatedly send money to the same beneficiaries, the creation flow prioritises selecting an existing beneficiary instead of repeatedly creating a new one.
Beneficiary management remains available when needed, but sits deeper in the experience.
This reduced unnecessary interaction and aligned the product structure with actual behaviour rather than the structure of the backend data.
03 — Supporting recurring and one-off allotments
The same interaction model supports both recurring instructions and individual payments.
Users can review key details before submitting and clearly understand the state of an allotment after it enters the workflow.
Statuses such as Active, Pending and Completed make it easier to understand what has already happened and what is still being processed.
04 — Designing around asynchronous data
Balance was a key user need, but asynchronous payroll data meant some salary-affecting events could exist before they reached the system, making the balance potentially incomplete.
Rather than remove the balance entirely, I worked with Engineering to understand the limitation and designed the UI to set the right expectation, presenting it as an estimated balance and clearly informing users that recent changes may not yet be reflected.
This let us preserve useful financial visibility without implying a level of accuracy the system could not guarantee.
Final Flow
