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. This case focuses on a decision-support workflow I designed within their fleet operations platform: the arrival approval flow.

The problem

Port arrivals are high-stakes, time-critical decisions. Operations teams need to assess whether a vessel can safely and compliantly enter a port — evaluating physical constraints, Port State Control inspection risk, and operational readiness — often with incomplete information and tight tidal windows.

The existing tools either surfaced too much raw data at once or collapsed risk into a single score, leaving operators to manually reconstruct what actually mattered. This created two failure modes: delayed approvals due to uncertainty, or premature sign-off without full risk awareness.

Design process

I started by mapping how arrival decisions actually unfold in practice — not the idealised process, but what operators were actually doing across multiple tools and mental models. The key insight was that approval isn’t a single moment. It’s a sequence of smaller judgements, each one narrowing the scope of uncertainty before the next question becomes relevant. Nobody looks at tidal windows before they know whether the vessel is broadly ready. Nobody checks berth availability before they’ve assessed inspection risk.

That observation shaped the entire design approach. Rather than designing a dashboard that surfaced everything at once and trusted operators to filter, I worked with the Orca AI team to define what each stage of the decision actually needed — what questions had to be answered, in what order, and what could safely wait. This meant a lot of early sessions mapping the decision logic before a single screen was drawn.

Working within Orca AI’s existing design system added a productive constraint. The component library and token structure were already established, which forced clarity about what could be communicated through existing patterns versus where the workflow genuinely needed new solutions. Most of the heavy lifting ended up being structural — information architecture and sequencing — rather than visual invention.

Why progressive disclosure

The obvious alternative was a single consolidated view: one screen with all the arrival data — draft constraints, PSC risk, weather, berth status — laid out for the operator to assess holistically. This approach has real appeal. It respects operator expertise and avoids the feeling of being walked through a process step by step.

But in practice, the consolidated view has a failure mode that’s hard to design around: it puts the burden of sequencing on the operator. When everything is visible at once, every piece of information competes for attention equally. In a routine arrival, that’s manageable. Under time pressure — a narrow tidal window, a high-risk vessel, multiple arrivals queued simultaneously — it becomes a source of errors. Operators reported skipping steps not because they didn’t know they mattered, but because the interface gave them no clear signal about what to look at first.

The staged model trades some flexibility for reliability. By structuring the flow around the natural decision sequence — awareness, triage, constraint validation, commitment — it removes the cognitive overhead of figuring out what to do next. Each stage has a single intent, a small set of relevant signals, and a clear exit condition. The cost is that experienced operators who already know the sequence can find it slightly prescriptive. That tradeoff was discussed explicitly with the team and accepted — the priority was reducing errors in high-pressure scenarios, not optimising for speed in routine ones.

From wireframes to final screens

The wireframe phase was less about aesthetics and more about validating the decision logic. The 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 changed 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’d done the triage work of identifying which arrivals actually needed attention. The final version is deliberately sparse at fleet level, surfacing only the signals needed to prioritise, and deferring everything else to the vessel-level brief.

The approval step itself also evolved significantly. Initial wireframes treated it more like a form confirmation — a final summary with a single confirm button. 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, Escalate — each anchored to the current risk state, so the operator is making a choice with context rather than clicking through a checklist.

Across all screens, the shift from wireframe to final was largely about signal clarity — making sure status indicators, risk levels, and available actions communicated hierarchy through semantic meaning rather than visual decoration.

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 — monitoring, analysing, deciding — on the same view.

Fleet overview

At fleet level, the system supports continuous monitoring rather than decision-making. Risk signals, voyage progress, and PSC inspection exposure are surfaced to help operators identify which arrivals need attention — without pulling them into detail they don’t yet need.

Arrival brief

Selecting a vessel opens a focused arrival brief that summarises readiness, inspection exposure, 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

Port-specific intelligence shifts the review from general readiness to physical and regulatory feasibility. Draft limits, tidal windows, pilotage requirements, berth status, weather, and inspection probability are evaluated together. Unresolved blockers are made explicit — approval only becomes available once this stage is complete.

Approval

Once all prerequisite checks are resolved, the workflow moves into a final review state. Operators explicitly choose one of three outcomes: Approve, Hold, or Escalate — each tied directly to the current risk state. Approval is a deliberate commitment, not a formality.

Design system

The interface is built on a lightweight semantic token system. Status colours, spacing, and component variants are mapped to intent — approval, warning, escalation, neutrality — so risk signals and action hierarchies stay consistent across every screen. The priority was reducing interpretation effort under time pressure, where changes in state, not visual novelty, should drive attention.

Outcome

The staged model gave operators a clear path from situational awareness to committed decision — without requiring them to hold multiple systems in their head simultaneously. Making risk explicit at each step and gating approval until all constraints were resolved reduced the cognitive burden of arrival decisions and made accountability clearer for both operators and compliance teams. The design also established a pattern the team could extend — adding new data sources or regulatory checks fits within the existing stage structure without requiring a redesign of the interaction model.