-
Summary • At a glance
Defined a standards-based foundation for a Maintenance Management System intended to align equipment classification and scheduling practices across 150+ vessels.
Core decision: Adopt SAWE Classifications and WBS Codes as the shared equipment and parts taxonomy.
Delivered: Product definition documentation, journeys, screen flows, wireframes, and prototypes to align Product and Engineering prior to build.
Outcome: Established structural readiness for fleet-wide governance and future optimisation.
— Context
As part of the IoT and Performance team, I collaborated with the Product Owner and Technical Lead to produce documentation encapsulating the vision for a new Maintenance Management System as the backbone of a Fleet Management Platform.
The system is intended to audit equipment, inventory, and schedules across the fleet — standardising maintenance scheduling and supporting longer-term procurement.
— Problem
Inconsistent maintenance data prevented fleet-wide governance
Each vessel operated semi-independently. Chief Engineers maintained local Excel-based schedules, equipment naming conventions varied, and parts were classified inconsistently. Inventory visibility across vessels and warehousing was limited.
As the fleet scaled, fragmentation became a structural risk: maintenance history was difficult to compare across vessels, onboarding and handover relied on personal documentation, and reporting was inconsistent and difficult to audit.
- Fragmented scheduling: Spreadsheet ownership made continuity dependent on individuals rather than a governed system.
- Inventory opacity: Limited parts visibility across fleet and warehouse constrained planning and reduced confidence in availability.
- Limited standardisation: Without a shared taxonomy, cross-vessel comparison and auditability were constrained.
- Optimisation blocked: Future IoT-driven scheduling would be unreliable without standardised classification.
“We were faced with finding a globally recognised taxonomy to identify and audit vessel equipment and machinery to standardise maintenance work, and support Chief Engineers’ scheduling practices across the fleet.” — Zodiac Product Owner
— User
Chief Engineers needed continuity across vessels and handovers
Chief Engineers worked in time-constrained, task-driven environments. Their workflow was practical: locate machinery, identify parts, confirm status, schedule work, and record maintenance with limited tolerance for ambiguity.
Spreadsheet tools provided flexibility but offered no governance. When engineers rotated or new vessels were onboarded, continuity relied on personal documentation and manual reconciliation.
- Fast retrieval: Find equipment quickly within a predictable hierarchy.
- Reduced cognitive load: Terminology and structure needed to remove interpretation rather than introduce it.
- Operational continuity: Handover should be supported by system structure, not personal spreadsheets.
— Feature
A standards-based maintenance governance foundation
The intervention focused on structural alignment rather than interface novelty. The system was anchored on a shared taxonomy and a consistent hierarchy model to reduce ambiguity and support fleet-wide auditability.
1) Shared taxonomy (SAWE / WBS)
Adopted SAWE Classifications and WBS Codes to standardise equipment and parts identification across vessels. The aim was to align with recognised maritime standards and reduce governance risk associated with bespoke internal conventions.
2) Hierarchy modelling (Sector → Installation → Machinery → Parts)
Modelled a consistent drill-down structure to reflect how engineers conceptualise vessel systems, improving predictability during operational tasks and reducing duplication in parts registration.
3) Build-ready product definition
- Product definition document to formalise scope, taxonomy adoption, and open questions.
- User interviews and shadowing to surface workarounds and edge cases.
- Sketch workshops to align Product and Engineering on structural direction.
- Journeys and screen flows to define transition states and ownership boundaries.
- Wireframes and prototypes to reduce ambiguity for development and QA.
How these artefacts supported build readiness
Wireframes and workflow mapping were used as governance artefacts: to clarify onboarding and registration steps, define ownership boundaries, and reduce classification drift before engineering work accelerated.
— Outcome
Structural readiness for scale, governance, and future optimisation
This phase focused on establishing a defensible foundation rather than reporting optimisation metrics. Outcomes are therefore described as alignment and build-readiness signals.
- Aligned Product and Engineering on a shared taxonomy strategy to reduce interpretation and support auditability.
- Defined a scalable entity hierarchy capable of supporting 150+ vessels without taxonomy drift.
- Reduced ambiguity in equipment and parts classification, improving readiness for onboarding and handover.
- Produced artefacts supporting development planning and QA validation (flows, wireframes, prototypes).
- Established a foundation for future refinement, including IoT-driven scheduling improvements.
The value here is structural leverage: enabling cross-vessel comparability, clearer audit trails, and more consistent governance as the platform expands.
Final visuals
— Iteration
Testing navigation models and communication formats
Iteration focused on validating how engineers locate and drill into machinery and parts, and on selecting communication formats that reduced downstream rework risk.
- Grid-based entry: Supported browsing and orientation when exploring unfamiliar structures.
- List-based hierarchy: Aligned with task execution and machinery structures, and was treated as the primary operational path.
Prototype video demos were effective for stakeholder alignment. Wireframes and annotated flows remained the primary artefacts for iteration as requirements evolved, supporting faster change and clearer QA expectations.
Prototypes
Prototype video demos helped secure feedback and consensus, but were less suitable for rapid iteration as viewpoints changed.

