There is a particular kind of confidence that arrives when a designer opens an old enterprise product for the first time. The interface is crowded, the terminology is mysterious, several buttons appear to have survived from a previous century, and somewhere in the workflow a spreadsheet is doing work nobody has formally admitted exists.
The temptation is obvious: tidy it up.
In maritime and aviation, that instinct needs to be handled carefully. These are not industries in which software merely helps somebody organise their afternoon. The products sit inside commercial commitments, operational handovers, regulatory obligations and decisions with expensive consequences. A confusing screen may be genuinely poor design. It may also be the visible edge of a workaround that has kept a complicated operation moving for 12 years.
Designing for these industries means learning to tell the difference.
Resistance to change is usually carrying information
Maritime software often serves people who have spent years becoming exceptionally good at working around their tools. Procurement teams may move between ageing platforms, email threads, supplier portals and spreadsheets assembled by somebody who left the business before the spreadsheet acquired its eighth tab.
Calling these users “change-averse” is not entirely wrong, but it is incomplete. They are often consequence-aware. They know that a small change to a familiar workflow can affect quote handling, approvals, audit records, supplier communication and the timing of a vessel operation. They also know that replacement systems have a habit of arriving with attractive dashboards and a slightly theoretical understanding of Tuesday morning.
This became clear while redesigning the procurement experience in my ShipServ procurement interface overhaul. Some of the pushback was directed at decisions that looked, from a conventional product-design perspective, like obvious improvements. Existing users had learned where information lived, how to scan dense pages and which odd sequence of actions reliably produced the outcome they needed.
Changing the interface meant changing a learned operating model. That is a much larger request than changing the position of a button.
The International Maritime Organization treats the human element as central to maritime safety, recognising that systems, management, training, working conditions and human capability are inseparable. Its guidance is aimed at shipping rather than procurement software, but the principle travels well: technology does not sit outside the operating environment. It becomes part of it. The IMO’s work on the human element is a useful corrective to the idea that adoption can be solved by polishing the onboarding tour.
The spreadsheet is not the enemy
Enterprise design conversations often treat spreadsheets as evidence that a workflow is waiting to be rescued. Sometimes it is. Sometimes the spreadsheet is the most honest representation of the work.
People use spreadsheets because they are flexible, inspectable and forgiving. A procurement specialist can add a column, flag an exception, paste data from an email and construct a temporary view without requesting a six-week change programme. An aviation commercial team can compare routes, costs and quote options while retaining a sense of where every figure came from.
The spreadsheet also absorbs ambiguity. Formal software wants to know the schema. Real work occasionally replies, “It depends.”
Moving people away from spreadsheets therefore requires more than reproducing the same columns in a browser. The product must replace the freedoms people rely on:
It must support comparison without making users export the data first.
It must preserve traceability, especially when figures are calculated or imported.
It must make exceptions visible without forcing every exception into the standard path.
It must provide useful bulk actions, filters and saved views.
It must allow data to leave the system when somebody genuinely needs it elsewhere.
In my work on smarter procurement insights for ShipServ, interviews showed that customers wanted to compare periods, understand drop-off, identify valuable counterparties and tell a credible story with their data. Export remained important, but the product could earn more work by making those questions easier to answer inside the interface.
That is a better migration strategy than declaring war on Excel. Build something worth staying in.
Aviation adds a different kind of operational density
Aviation and air cargo share some of maritime’s legacy constraints, but the rhythm is different. A cargo charter request can become a multi-route quote, negotiation, contract, booking, operational plan and invoice. Information moves across commercial teams, operations, finance and external systems. A change that looks local may alter the work waiting for somebody else.
This is why an aviation interface cannot be designed as a collection of isolated screens. It needs to express the lifecycle of the job.
When designing for charter management, the important questions are not only “Can a user create a quote?” They include:
Which values came from the customer, which were calculated, and which were changed manually?
What has been approved, by whom, and at what commercial threshold?
Which version became part of the contract?
What needs to pass into operations?
Which data must reach finance, CRM or cargo-management systems?
What happens when one connected system disagrees with another?
IATA’s work on digital aircraft operations reflects the breadth of the challenge. Digital operations span flight operations, ground operations, maintenance, supply chains and the movement of aircraft assets. In air cargo, IATA’s Digitalization Leadership Charter has also emphasised collaboration, resilience and a shift from legacy systems towards data sharing through web APIs.
For designers, the practical lesson is simple. A neat task flow is not enough if it ignores the systems and teams on either side of it.
Approval workflows are where the organisation hides
Large organisations often appear precise from the outside and surprisingly folkloric from within. Ask how approval works and the first answer may be straightforward. Ask what happens for a large value, an unusual customer, a changed clause or an absent approver, and the workflow begins producing additional limbs.
This obscurity is not unusual. Approval rules grow through policy, risk appetite, organisational structure and remembered incidents. Some rules live in systems. Others live in documents. A few live in the sentence, “We normally ask Martin.”
While designing an AI co-pilot for contract negotiation, it was not enough to make suggestions appear intelligently. The interface had to help users understand what was proposed, what evidence supported it and where human authority remained necessary. AI can reduce the effort involved in reviewing material, but it should not make organisational responsibility disappear behind a confident recommendation.
Good approval design makes the hidden model visible:
Show the current stage and the reason approval is required.
Identify the responsible person or role.
Present the changed values and their consequences.
Keep supporting evidence close to the decision.
Record comments, overrides and previous decisions.
Explain what will happen after approval or rejection.
This is particularly important in safety-conscious and commercially sensitive industries. Friction is not always a design defect. Sometimes it is where the organisation pauses before doing something expensive.
Start with the edge cases people remember
Customer interviews in specialist industries can become misleading if they remain too general. Ask somebody how they create a quote and they may describe the official process. Ask them about the last quote that went wrong and the actual product begins to appear.
The useful stories often concern exceptions:
A supplier responded after the request had changed.
A route required positioning that affected the commercial model.
An approver was unavailable while the customer waited.
A contract clause was acceptable for one organisation but not another.
Data reached finance in a format that required manual correction.
Somebody exported to a spreadsheet because the system could not compare the right scenarios.
These are not peripheral details to be addressed after the core journey. In mature industries, they often are the core journey.
I try to ask three things during discovery. What happens most often? What causes the most risk? What do experienced users do that the documented process does not mention? The overlap between those answers reveals where a redesign can create value without removing the coping mechanisms people still need.
Earn change through increments
Large redesigns are satisfying in presentations because every inconsistency can be resolved at once. They are less satisfying when thousands of experienced users open the product on Monday and discover that familiarity has been classified as technical debt.
Incremental change is not a lack of ambition. In operational software, it can be the more strategic approach.
A useful sequence is:
Observe the existing work, including exports, notes and unofficial handovers.
Identify one costly or risky point in the workflow.
Prototype the changed behaviour with real scenarios and representative data.
Test with experienced users as well as newer users.
Release to a small group with clear support and measurement.
Preserve an escape route while confidence develops.
Use observed behaviour to choose the next change.
Early customer involvement matters because it changes the relationship. Users are no longer being asked to approve a finished idea. They are helping expose the conditions under which the idea must work.
It also helps teams separate resistance to the unfamiliar from criticism of a genuine flaw. Both can sound similar in a meeting. Only continued observation tells you which one you are hearing.
Modernisation should preserve operational confidence
The goal in maritime and aviation is not to make old work look modern. It is to make complex work clearer, safer and easier to coordinate.
That usually means respecting several truths at once. Users may need better software and still be reasonable to distrust a sudden replacement. Spreadsheets may create governance problems and still contain capabilities the product has failed to provide. Approval workflows may be inconsistent and still encode real organisational risk. Legacy systems may be frustrating and still be connected to everything that keeps the operation moving.
Good industry-specific design begins by understanding those truths before simplifying them.
The designer’s job is not to arrive with a cleaner interface and win an argument against the past. It is to discover why the current behaviour survived, preserve what remains valuable and create a credible path towards something better.
In industries built around vessels, aircraft, contracts and coordinated operations, trust rarely arrives through a dramatic reveal. It arrives when the new workflow handles the awkward case, keeps the evidence visible and lets an experienced user finish the job without reaching immediately for the spreadsheet.
That may be less theatrical than transformation. It is also how transformation tends to work.
