.png)
QuayConnect, a freight-forwarding company owned by Port Nelson, manages the complex logistics of moving goods from point A to point B. This process is far from straightforward. It involves multiple parties such as clients, freight forwarders, warehousing teams, packing staff, truck drivers, customs inspectors, shipping companies, and port authorities and many more individuals end to end
Every shipment includes a web of contractual obligations and accompanying documentation. With so many touchpoints, there is ample opportunity for things to go wrong. The Port's current system has evolved organically over time—some processes date back to the earliest days of shipping—and lacks a unified digital solution. Orders are tracked using a mix of spreadsheets, clipboards, whiteboard notes, third-party systems, and the knowledge of experienced individuals. In an industry where rapid and unpredictable change is the norm, coordinating freight across the country is incredibly challenging. QuayConnect was seeking a digital solution to centralise, streamline, and oversee this entire process, an important step in their digital maturity. Our web-app solution, Pelorus, would give customers and staff greater visibility over the entire distribution chain,
About
Overview
My role
My role started after Discovery had been completed and the web-app was beginning to be designed. I initially worked with lead designer and development team, then took over design responsibilities such as:
- Design activites such as developing user flows, structuring the app IA, navigation and page structures.
- Moderated user testing
- Creation and management of a design system
Discovery
Background context
Before I joined the team, Effect (my employer) and Augen (a technology partner for the project) had completed a Discovery phase that included contextual inquiries at the Port warehouses. This early research gave us valuable insight into team workflows, operational processes, and the extensive documentation involved.
Although the Pelorus platform was ultimately intended to support all QuayConnect customers, and tie into wider Port operations, our initial focus was narrowed to the shipment of wine and glass bottles at the national level, specifically for two key clients.
While QuayConnect handles a variety of goods, the regional wine industry represents a significant market segment. By concentrating on this narrower scope for the first release, we were able to reduce product complexity while laying the groundwork for a scalable, modular system with future expansion in mind.
Although the Pelorus platform was ultimately intended to support all QuayConnect customers, and tie into wider Port operations, our initial focus was narrowed to the shipment of wine and glass bottles at the national level, specifically for two key clients.
While QuayConnect handles a variety of goods, the regional wine industry represents a significant market segment. By concentrating on this narrower scope for the first release, we were able to reduce product complexity while laying the groundwork for a scalable, modular system with future expansion in mind.
What does an order take?
To start to untangle this complexity, we mapped the ideal process when things run smoothly. The example below is what domestic shipping of wine from Nelson to Auckland looks like:
- The vinyard (client) contacts QuayConnect to initiate a movement of goods.
- Client packs wine into pallets.
- Trucking contractor arrives and loads pallet into a truck and moves to warehousing.
- Truck is unpacked.
- Another trucking contractor picks up a container from the Port and arrives at the warehouse.
- Goods are packed at the warehouse and order slip created.
- Container dropped off at the port (within the correct time window). Appropriate documentation required.
- Container loaded onto the ship. Ship sails to Auckland.
- Ship arrives at Auckland, container unloaded.
- A new trucking contractor picks up the container and drops it at the destination warehouse.
- Container is unpacked. A trucking contractor drops container off at port.
- Another trucking contractor picks up the palleted goods and drops it at its final location!
If you followed that, you’ve just managed the shipment of wine from Nelson to Auckland. But with so many steps, there’s a high chance something will go wrong. We’ll address these hiccups next, but first, we focus on making this process manageable.
What we learnt
- There are a lot of steps along the way, meaning a lot of opportunities for miscommunication.
- The timings matter - contracts mean that goods have to be moved in certain timeframes.
Define
Creating sense out of complexity
This case study focuses on the order management aspect of Pelorus—tracking an order through the chain of custody. This is where the product provides the most value. Other features, such as viewing lists of orders, creating new inventory items, or generating reports, are more standard SaaS functionalities and do not differentiate Pelorus in the same way.
As Pelorus develops, many third-party applications currently used by contractors will be integrated into Pelorus to enable greater automation. However, at this early stage, our primary goal is to centralize what is currently a highly manual and often physical process—relying on clipboards, paper printouts, and wall notes—into a single digital source of truth. The primary user in this case study is the order coordinator, responsible for overseeing the completion of tasks associated with each order. You'll notice the designs are optimized for desktop and tablet (1024px and above). We made a deliberate decision not to prioritize mobile views in this early phase, as our primary users are working from desktop setups or tablets in warehouses. In later stages, Pelorus will be rolled out to contractors who are more mobile, and mobile-specific interfaces will be introduced. Our focus was on getting the core experience working well first, while maintaining enough flexibility to scale to mobile when the time is right.
As Pelorus develops, many third-party applications currently used by contractors will be integrated into Pelorus to enable greater automation. However, at this early stage, our primary goal is to centralize what is currently a highly manual and often physical process—relying on clipboards, paper printouts, and wall notes—into a single digital source of truth. The primary user in this case study is the order coordinator, responsible for overseeing the completion of tasks associated with each order. You'll notice the designs are optimized for desktop and tablet (1024px and above). We made a deliberate decision not to prioritize mobile views in this early phase, as our primary users are working from desktop setups or tablets in warehouses. In later stages, Pelorus will be rolled out to contractors who are more mobile, and mobile-specific interfaces will be introduced. Our focus was on getting the core experience working well first, while maintaining enough flexibility to scale to mobile when the time is right.
Chunking the stages
While there are many stages involved, one of the things that helps organise shipping is that there are clear and distinct edges as to who is responsible for the container at each step. Driven by liability and insurance, it does provide a natural structure for knowing when one step has stopped and another begins.
Largely we can chunk these steps into the following:
Largely we can chunk these steps into the following:
- Order creation - high-level details are entered, many of which (such as dates) may shift over time.
- Order Booking - co-ordinators must book the contracts and logistics across the many different suppliers and ensure it all aligns perfectly.
- Order management - where the order goes live and physically moves from origin to desitnation.
- Packing - from the moment the first truck arrives at the client to the moment it is dropped at the port
- Shipping - from receiving the container on the port to a truck picking up the container from the port
- Delivery - from the port to the final customers hands
Design ideation
The Order Creation process was designed as part of this project, but it isn’t the primary focus of this case study. As shown below, we implemented a simple step-by-step wizard for entering key high-level information. Since this area was not identified as a major opportunity for innovation or improvement, our team focused most of our design effort on the more complex and value-driving stages: Order Booking and Order Management.
One overview for booking and management
Both the Order Booking and Order Management stages were designed to be managed from a single, bird’s-eye view interface. Orders were structured into two key components.
The top section is the Overview section, which displays essential information about the order, such as locations and dates, to all parties involved in the supply chain. The second is the Order Management area, a dedicated space where order coordinators can plan and manage tasks across the various stages of the order. In future iterations, the platform is planned to provide contractors with restricted access, allowing them to view and manage only the tasks assigned to them.
The top section is the Overview section, which displays essential information about the order, such as locations and dates, to all parties involved in the supply chain. The second is the Order Management area, a dedicated space where order coordinators can plan and manage tasks across the various stages of the order. In future iterations, the platform is planned to provide contractors with restricted access, allowing them to view and manage only the tasks assigned to them.
Booking an order
Before the order can go live, all services need to be booked and have contracts in place. This means for a coastal shipping order, you might have 6-7 contracts. The user flow below maps out the process of adding contracts to an order. The user goes to the order page, opens each service, adds the details and confirms it as booked. Because each service has so much information, these were managed in seperate modals from the order screen.
Before an order can go live, all required services must be booked and have contracts in place. For a typical coastal shipping order, this could involve managing 6 to 7 separate contracts. The user flow below outlines the process of adding these contracts to an order. Users navigate to the order page, opens each service individually, enter the necessary details, and confirm the booking. Each service is managed individually because a co-ordinator might have the information for different contracts arriving sporadically. You might open the Shipping section one day, then the next afternoon open up Packing.
Before an order can go live, all required services must be booked and have contracts in place. For a typical coastal shipping order, this could involve managing 6 to 7 separate contracts. The user flow below outlines the process of adding these contracts to an order. Users navigate to the order page, opens each service individually, enter the necessary details, and confirm the booking. Each service is managed individually because a co-ordinator might have the information for different contracts arriving sporadically. You might open the Shipping section one day, then the next afternoon open up Packing.
As a user books in more services, the order gets 'filled in' and this is represented visually. Once all services are booked, the order can then be switched to being active.
Communicating status and interactions
In addition getting booked, each service needs a series of actions. The below shows the status of both the services overview and then also the services in detail. At (1) you can see a partially booked order, the user presses the un-booked order to open the modal for adding details. At (2) the order booked is fully booked, but the activities below are still greyed out. However at (3) the order is now active, and this section serves less as a way of managing bookings but an overview of the order progress and then a way to manage the actual tasks involved in the service. (4) shows the order completed.
In addition to booking each service, a series of tasks must be completed to move the order forward. The image below show the status indicators at two levels: the overall services overview and the detailed service view. At (1), the order is partially booked. The user can click on an unbooked service to open a modal and enter the required details. At (2), the order is fully booked, but the related activities remain inactive (greyed out) since the tasks have not yet started. By point (3), the order has become active. This stage shifts focus from managing bookings to tracking the progress of the order and managing the specific tasks involved in each service. Finally, point (4) indicates that the order is completed, with all tasks finished and the service closed out.
In addition to booking each service, a series of tasks must be completed to move the order forward. The image below show the status indicators at two levels: the overall services overview and the detailed service view. At (1), the order is partially booked. The user can click on an unbooked service to open a modal and enter the required details. At (2), the order is fully booked, but the related activities remain inactive (greyed out) since the tasks have not yet started. By point (3), the order has become active. This stage shifts focus from managing bookings to tracking the progress of the order and managing the specific tasks involved in each service. Finally, point (4) indicates that the order is completed, with all tasks finished and the service closed out.
Structuring booking and management
We landed on describing this section as 'Action and Track' - an overview of the status of your order and the tasks you need to do to complete it. Each major section such as 'Packing' acted as a tab to provide a detailed view of the subtasks below. This visual model provided a birds eye view of the contracts, but also could be sectioned out as needed to just give access to 'Warehouse' for a specific contractor.
As the designs progressed we refined this visual interaction, providing a visual language to glance an understand progress, using both colour changes, icons and badges to indicate progress.
Structuring the page
In the design above, you can see how started looking at structuring these key stages in step with an order timeline that was scaled. However after reviewing this mockup with client and looking at various orders, there would be too much variability in the length of time for packing vs shipping as an example, resulting in the shipping module visually scaling to be unusably small.
After this first round of wireframes we decided to seperate the timeline from the shipping steps as seen above. Instead we used the timeline as a visual indicator of progress, highlighting the next locations coming up and any issues. For example the red exclamation icons indicate some part of the order hasn't been organised yet.
Separating the timeline allowed us to present Packing, Shipping and Delivery as simple tabs, with the details underneath.At this stage we also begun to introduce the first high fidelity designs, the largely blue theme riffing off nautical colours.
Separating the timeline allowed us to present Packing, Shipping and Delivery as simple tabs, with the details underneath.At this stage we also begun to introduce the first high fidelity designs, the largely blue theme riffing off nautical colours.
Navigation changes
You will notice here that a different navigation structure has been introduced. Our assumption had been that a side bar would provide quicker access to navigating been orders and reports. While this is true, it wasn't as useful as realised. User feedback was that they wouldn't be jumping really quickly between orders or reports, instead working in a more focused manner on a single report. The extra horizontal space gave us more room for for timelines, tickets and any sidebars.
We continued to iterate on the nav, moving away from hamburger menus where possible and maintaining all the features as buttons or hidden behind a settings menu.
Product and Container information
Each order consists of the products being shipped, and the containers involved in shipping them. Each container through an order also will be operating across many stages.
The product information was added to the overview section so all users could see the contents. Then a container informatoin grid was added, showing each container, key details and tickboxes for completion of each status.
This container information grid is also the same interface when opening an order, users can tick off the completed items. This view was surface din a non-editable mode to provide an alternative view of the progress.
The product information was added to the overview section so all users could see the contents. Then a container informatoin grid was added, showing each container, key details and tickboxes for completion of each status.
This container information grid is also the same interface when opening an order, users can tick off the completed items. This view was surface din a non-editable mode to provide an alternative view of the progress.
For example when a container is in transit, a user needs to updat
When this is saved, the order overivew page grid will update to reflect the new status. If not all containers are ticked, the order will not pass 'in transit'. This will also provide visibility to all that a container may not have been loaded.
e this infromation. It might be the order co-ordinator, but could also be a contractor with access rights to the sotrware. The co-ordinator needs to confirm that the containers are in Transit on the ship. As it was not tied to any APIs at this stage this was a manual process at this stage. When this is saved, the order overivew page grid will update to reflect the new status. If not all containers are ticked, the order will not pass 'in transit'. This will also provide visibility to all that a container may not have been loaded.
Refine: User Testing
Our testing process involved regularly weekly feedback sessions with key users but also remote moderated usability testing with shipping co-ordinators; future daily users of the shipped product. Using clickable prototypes we were testing to see if the overall workflow made sense and fit their conceptual model.
Learnings
- Edge cases: Packing and transport of an order might happen at the same time on the day and would be easier to tick off at the same time instead of having to run through each on seperately.
- Ordering of tasks: There was a difference between our ordering of tasks and the users expectations.
Some of the sub-tasks were not in the order that the users expected. - Expectations of the system: The interface implied that the system would automatically provided a certain document (SLI), however this still needed to be done manually. We needed to add prompts to ensure users would complete these tasks.,
Outcomes
Reflections
Pelorus didn't just encompass this project, it is ongoing piece of software at the port, and the V2 design I worked on as well is currently being built. It has become a unique selling point for Quay Connect providing a much more customer centric view including insight into inventory management.
"There has been nothing like this for the industry to date, so get it off the ground. Get it out as soon as possible so customers can realise the benefits."