Orca — Arrival Approval Flow

Orca AI builds computer vision and AI systems for commercial shipping fleets, helping crews navigate safely and giving operations teams shore-side visibility across their vessels. I worked as a freelance product designer embedded in their UX team, contributing to the fleet operations platform across UX design, design system work, and engineering handoff. This case focuses on the arrival approval flow.

The brief

Port arrival decisions are time-sensitive and high-stakes. Operations teams need to assess whether a vessel can safely and compliantly enter a port, working across physical constraints, inspection risk, and operational readiness, often with incomplete information and tight windows.

The existing flow had grown over time and become cluttered. Operators were landing on screens with too much competing for attention and no clear signal about what to do first. On top of that, new features needed to be added. Before anything new could be built properly, the foundation needed to be cleaned up and aligned to a new design system being introduced across the product.

Cross-functional process

I collaborated closely across product, engineering, domain experts, analysts, QA, and the design team throughout the project.

With the product manager I worked through information hierarchy early, deciding what data belonged on the main screen versus what could live in expandable detail panels. We agreed on scope together, keeping the core flow on track without compromising critical compliance logic.

With maritime domain experts and port officers I ran discovery sessions to understand how operators actually made decisions. That research shaped how we approached the redesign and where the biggest friction points were in the existing flow.

With the analyst we mapped how operators were using the existing tools, what they looked at most, and where they got stuck. That data fed directly into the information hierarchy decisions.

With engineers I brought feasibility into the process early. The dashboard required live data feeds, so I worked with frontend and backend developers to make sure designs were realistic to build and performant under real conditions. For handoff I documented every edge case state so nothing was lost in translation.

With the QA team I stress-tested interactive prototypes before launch. Walking through worst-case scenarios identified the risk of accidental sign-off on a flagged vessel, which led directly to adding a multi-step confirmation before the approval could be committed.

Approach

The core design challenge was cognitive load. Operators under time pressure were making errors not because they lacked expertise, but because the interface gave them no clear signal about what to look at first. When everything competes for attention equally, things get missed.

The team aligned on a staged approach: structure the flow around the natural decision sequence so each stage answers one question before the next becomes available. Awareness, then triage, then constraint validation, then commitment. Each stage has a single intent, a focused set of signals, and a clear exit condition. The tradeoff was that experienced operators might find it slightly prescriptive in routine cases. That was discussed explicitly and accepted. Reducing errors in high-pressure scenarios mattered more than saving steps in easy ones.

From wireframes to final screens

The wireframe phase was focused on validating the decision logic before touching visual design. Key questions were structural: where does each piece of information live, what triggers the transition between stages, and when exactly does the approval action appear.

Several things evolved between early wireframes and final screens. The fleet overview went through the most iteration. Early versions showed too much detail per vessel, pulling operators into analysis before they had done the triage work of identifying which arrivals actually needed attention. The final version surfaces only the signals needed to prioritise at that level.

The approval step also changed significantly. Early wireframes treated it more like a form confirmation. Feedback from stakeholders close to the operations workflow pushed back on this. Approval needed to feel like a deliberate act, not a formality. The final version introduces three explicit outcomes, Approve, Hold, and Escalate, each anchored to the current risk state.

Low-fidelity exploration

Early wireframes tested structure, hierarchy, and action placement across all four stages. The main validation at this point was confirming that each screen could serve a single intent without requiring the operator to mentally switch between modes on the same view.

Fleet overview

At fleet level, the interface supports monitoring rather than decision-making. Risk signals and inspection exposure are surfaced to help operators identify which arrivals need attention, without pulling them into detail they do not yet need.

Arrival brief

Selecting a vessel opens a focused summary of readiness and top constraints. This stage answers one question: is this arrival generally ready, or does it need deeper analysis? Low-risk arrivals can be cleared quickly. Ambiguous cases are flagged for further review.

Port intelligence

This stage shifts the review from general readiness to physical and regulatory feasibility. All relevant checks are consolidated in one place. Unresolved blockers are made explicit and the approval action only becomes available once this stage is complete.

Approval

Once all prerequisite checks are resolved, operators explicitly choose one of three outcomes: Approve, Hold, or Escalate, each tied directly to the current risk state. A multi-step confirmation blocks accidental commitment. Approval is a deliberate act, not a formality.

Design system

A new design system was being introduced across the product. My job was to apply it consistently throughout the flow, updating existing components to use the new tokens and building new components where the flow needed patterns that did not exist yet. New components were documented and incorporated into the system for the wider team to use. This required close collaboration with both the engineering team and the design system team to make sure everything mapped correctly to code and could be reused beyond this flow.

Outcome

The flow was redesigned and aligned to the new design system throughout. Operators had a clearer path through each decision with less noise at every stage. New components built for this flow were added to the system for the wider team. And the new features that needed to be added were built on a solid, consistent foundation rather than bolted onto something that was already struggling. The staged structure also proved flexible enough that new checks could be added later without rebuilding anything from scratch.