Vessel Registry Modernization

The Vessel Registry supported operationally important and highly regulated work. Registrars needed to manage related vessel items without losing the status, completeness, payment, or certificate context that made each decision trustworthy.

I collaborated with product owners, registrars, service design, developers, and another designer to understand where those relationships broke down. The modernization was incremental rather than a single replacement: start with a difficult relationship, test an interaction model, and carry the useful model into the next operational decision.

The work covered four connected threads:

• Group Requests: make many related vessel items understandable as one request without hiding the individual items.
• Unified Search: explore a more extensible search direction beyond the first entities, as a design and engineering hypothesis.
• CRSM-WLM: clarify workload and cost-recovery relationships and communicate the integration at a useful level of detail.
• Digital Certificates: keep readiness, missing information, certificate type, and the final signing decision connected to the request.

The page distinguishes tested directions, concepts, and portfolio reconstructions from confirmed shipped product UI.

The registry's workflows were familiar, but difficult to scan and expensive to reason about item by item. A registrar could be working with a group of related requests while also needing to understand which items were complete, what amount or waiver applied, and whether a certificate was ready for the next step.

The central design problem was not simply too many fields. It was the loss of relationships between items, statuses, amounts, and actions as work moved across different parts of the system.

The question became: How might a group feel like one manageable request without hiding the individual vessel items that make it valid?

I mapped the existing workflows with product and domain experts, turned broad problems into focused interaction questions, created low-fidelity explorations, tested competing patterns, and refined the handoff with development.

My contribution was the design reasoning around the workflow: what needed to remain visible, which decisions could be safely grouped, where incomplete work had to stay explicit, and how to communicate the model to people with different levels of domain and technical context.

I also brought frontend and GraphQL experience into feasibility conversations. That helped me frame reusable components, query relationships, and future entities as questions for the delivery team—not as proof that a proposed search model was implemented.

The problem

Registrars needed to act on related vessel requests while retaining item-level visibility into completeness, status, amounts, payment, and certificate issuance. Treating each item as an isolated request made the relationship harder to understand; hiding the items behind a single bulk action would have made exceptions harder to trust.

The explorations

I explored a visible group indicator, parent-and-child structure, item counts, a modal, a bulk-edit pane, and an accordion. The testing and project notes support the accordion as the clearest direction because it preserved the group context while allowing individual items to remain visible in the same working surface.

That is a tested interaction direction, not a claim that every explored option shipped or that the test produced a measured performance improvement.

Recreated UI screens

The screens below are authored portfolio reconstructions informed by the recorded interaction model. They replace the source screenshots with synthetic data and a consistent visual system so the interaction can be understood without presenting the original project files as production UI.

Portfolio reconstruction

This short reconstruction translates the recorded interaction model into a clean walkthrough using synthetic request IDs and labels. It recreates the request board, before/after service-request flow, accordion detail, payment review, and certificate readiness. It is not a pixel-perfect capture of the shipped product.

Why the accordion mattered

The accordion was useful because it made the relationship legible without forcing registrars to leave the group view. It gave the team a way to keep the parent request, item count, status, and individual details in one place while still allowing the work to move toward payment and certificate review.

The important decision was not “accordion versus modal” as a stylistic preference. It was whether the interaction preserved enough context for a compliance-sensitive bulk action.

The product owner was thinking beyond the first searchable entities, including Vessel and Owner. I explored whether a unified-search direction could make future entity types easier to add without creating a separate search experience for each one.

My GraphQL experience gave me a useful technical hypothesis: queries, fragments, and shared result components might support a more extensible model. I brought that hypothesis to developers, then developed low-fidelity work for validation.

This remained a concept and feasibility direction in the material available for this case study. I am not presenting it as a shipped feature, a faster search experience, or a measured scalability result.

CRSM-WLM — Cost Recovery System Management and Work Load Management — was an adjacent workload and cost-recovery stream. I mapped the existing flow and the proposed integration with service-design and product partners, looking for the relationships and business rules that needed to survive the transition.

The detailed flow work became too granular for some stakeholder conversations. Rather than adding more boxes, I shifted toward a primary-user view: what the person was trying to do, what the system needed to support, and which questions still needed a business decision.

That shift is the useful design lesson here. It shows how I adapted the communication model when a technically accurate artefact was not helping the group make a decision. It is not a claim that every proposed integration or storyboard became production UI.

Certificate work showed why the group relationship mattered downstream. Ready items could move together, but incomplete work needed to remain visible rather than disappear into a bulk action.

The design direction kept a completeness check, certificate type and count, missing information, and one deliberate signing decision in the same flow.

• The diagrams on this page are portfolio reconstructions of the information models described in the project material. They are not unmodified Transport Canada production screenshots.
• Group Requests is presented as the main tested interaction direction. The modal and bulk-edit pane remain part of the exploration history; they are not described as shipped alternatives.
• Unified Search is a design-and-engineering concept. Its presence here does not imply implementation, user validation, or improved search speed.
• CRSM-WLM is described as systems and communication work. The page does not turn an exploratory flow into a claim of a completed product integration.
• The project record does not include measured adoption, workload, search, or turnaround-time outcomes. The results below stay qualitative for that reason.

• In a compliance-heavy system, bulk actions are only useful when the underlying relationships remain visible.
• A group is not just a visual container; it carries status, payment, completeness, and next-step context across the workflow.
• Technical literacy is most useful in design when it improves the question being asked about feasibility and maintainability.
• Accurate system maps still need the right level of abstraction for the people making a decision.
• Incremental modernization is safer when each interaction direction can be tested, explained, and handed off before the next relationship is redesigned.

The Vessel Registry work was less about replacing a legacy interface and more about making its information flow understandable. I helped the team establish a clearer group model, test how that model should behave, explore a more extensible search direction, and communicate adjacent workload and cost-recovery questions at the right level of detail.

The result was a practical modernization direction grounded in the work itself: preserve the relationships people need to trust, test the smallest interaction that supports them, and be precise about what was explored, validated, reconstructed, or shipped.