Context
A PLANNING TOOL TO OPTIMIZE OPERATIONS
The pandemic showed the world how quickly disruptions in the supply chain industry can cause major economic crisis. Most goods are transported globally via large cargo ships that need to be loaded and unloaded at maritime terminals. The position a cargo ship is allocated at a terminal is called “Berth”. The allocation of a berth position must be carefully planned as arrival and departure time need to be sequenced with other departing and arriving vessels. A planner also needs to consider on shore equipment like cranes or container storage positions at the terminal’s yard for choosing a ship's berth position. The overall goal of a berth plan is to optimize operations and keep them at full capacity to maximize the profitability of the terminal.
a cargo vessel is berthed at a terminal so cranes can unload and load containers
"Berth Window Management" is a SaaS tool for cargo terminal berth planners to create a vessel visit schedule
Goal
Replace legacy software & GENERATE ARR
legacy berth feature of N4
Navis is a mid-sized software company specialized in the development of SaaS solutions for managing the logistics at a maritime cargo terminal. It’s core product “N4” is a terminal operating system that processes crucial data needed for any kind of terminal operations. Various departments are responsible for different parts of the cargo processing flow. This starts with planning for the arrival of a vessel, all the way to loading individual containers onto trains or trucks for transportation to their destinations.
At the time N4 had an integrated berth scheduling feature which had become obsolete. Also other start ups began to offer modern versions of such planning tools. Navis urgently needed to stay competitive for the retention of valuable customers and to sign up new terminals. The transition from a service revenue to a reoccurring revenue model was crucial for the company. This shaped the goal for the new berth tool:
convert existing clients to subscribers and generate new ones!
My Role
A DESIGN TEAM OF ONE
Navis had been an engineering driven company, just realizing the value of good product design. I was the only product designer in a team of one product manager and four engineers located in Spain. The PM was the knowledge expert and driver of the roadmap. We established a regular meeting schedule to ensure a speedy development. I was responsible for the full end to end design process from research, analysis, ideation to creation of mocks and prototypes, user testing and timely delivery of graphic assets and instructions. The engineering team had adopted an agile development process with a monthly release cycle. I took a hands on approach to ensure that all tickets in the backlog were properly addressed and had all design related material attached whenever they where prioritized for the next sprint.
a small agile development team of one PM, one designer and four engineers
My Process
A Top priority was to supply the development pipeline with enough tickets for the engineering team to keep working. We used Pivotal Tracker for our agile development process.
The PM and myself had two regular meetings per week:
one was on Tuesdays for short term deliveries. We made sure all tickets were ready for the next day’s weekly team sync.
Long term projects were discussed on Thursdays as well as kick offs for new features. For these meetings we invited a member from engineering to keep the rest of the team in the loop about upcoming projects. It also helped us to estimate the scope of any new feature and applied changes where necessary.
delivered pixel perfect mocks in Zeplin and Figma for the development team to extract specs /
annotated PDFs were attached to tickets in Pivotal Tracker outlining the UX concept and flow
In pivotal tracker, I was responsible for attaching the required deliverables to any ticket tagged with an UX/UI label. This was mostly a PDF with annotated mocks outlining the concept and functionality of the new feature. Digital assets like icons or logos were also needed for some tickets, which I provided in SVG or PNG format. Initially I used Zeplin and later Figma to provide pixel perfect mocks so the engineers could extract the specs for layouts, paddings, margins, positions etc.
Research
Collaborating with knowledge experts
The legacy Berth feature of N4 needed a UI refresh but also upgrade its basic functionality. Solutions offered by competitors had a clean look and feel and the capabilities of a modern web application. The PM had already a clear vision about the new berth tool becoming a competitive product in the market. He previously worked at one of the world’s leading terminals for several years and was a knowledge expert in this domain.
For me as a designer it was important to build empathy with the end user. On occasion I could make an onsite visits at a terminal to conduct contextual inquiries. Looking over the shoulder of a berth planner revealed a lot of details I otherwise would not have learned about. It was important to see the context in which he or she gathered all needed information before starting the scheduling process. Many had built an elaborate spread sheet in excel or came up with creative devices. One put a transparent plastic sheet on top of a magnetic white board so he could slide all notes sidewards as time progressed.
at onsite visits I conducted contextual analysis, did interviews, took notes and snapshots of a berth planners work environment
I wrote reports about my onsite visits to share them with the team and to build a knowledge base. Photographs of a planner’s work environment showed how he or she used software together with other tools and devices. An important learning was that the planning process is highly collaborative, where the planner continuously gathered the latest data from other coworkers. I created a diagram which helped us to better understand the flow of information between multiple departments.
Analysis
Understanding Complexities & Pain points
A persona kept a good focus on the pain points and needs of a berth planner. But it was also helpful to understand the role of other personas involved in the process. These personas allowed everyone of our team to share the same understanding. The analysis revealed that the workflow of a planner is a highly interactive process. It relies on multiple data sources, which have to be continuously updated as the arrival time of a cargo vessel approaches. These multiple data streams were either automatically obtained by Navis’ terminal operation system N4, by phone, email or copied from shared excel spread sheets. What complicated the process further was the fact that for certain informations like estimated time of arrival (ETA) of a vessel, the planner could choose from multiple providers. This suggested a data input design that also offers the user to choose the desired “source of truth”.
Personas focused on user's goals, tasks and pain points
.jpg)
a user journey map visualized the basic steps that are needed to create a berth plan
The step by step management of a vessel visit was visualized in a user journey map. It identified the following steps:
-
step 1: logging the "proforma"
-
step 2: creating a vessel visit
-
step 3: continuously updating a vessel visit
-
step 4: estimating the departure time
It became clear that the main use case our solution needed to accommodate is step 3 where multiple data sources have to be reconciled constantly.
Information Architecture
Defining the key screens of the new design
The PM and I established which core functionalities our new berth tool had to have. An information architecture diagram captured all key features and gave me a better understanding of the needed navigation flow. It also allowed me to form a long term vision, as we were not able to implement everything at once.
an information architecture diagram guided the design of the navigation
%20copy.jpg)
Validation
Creating a prototype for user testing
I created a prototype with a few key screens from the first draft. Unfortunately I could not just ask people on the street to evaluate if this was a better way to schedule berths for cargo vessels. Sales did not want to bother established clients with user testing, so I had to search among colleagues within the company that had an appropriate amount of knowledge about the subject matter. Fortunately there were a few, who were willing to sit down with me. I tried to get the most relevant and valid data from these sessions, so I carefully selected the scenario and wrote a script. I opted for an unmoderated usability testing, giving the participants specific steps to accomplish a task without any guidance. This allowed me to observe quantitative metrics like:
-
how long did it take to accomplish the task
-
how many times did the user get stuck or had to ask a question
-
counting the click through rate
-
how often a mistake was made
-
was the user able to correct the mistake
In the second part of the session I conducted an interview to obtain qualitative data. What was their overall feedback? Were you able to concentrate on the task or did the UX keep you distracted? What were your thoughts? What were your feelings while trying to accomplish the task? Everything was captured and documented so myself and the berth development team could properly evaluate the outcomes.
unmoderated user testing sessions were conducted to obtain quantitative and qualitative data
Ideation
First draft
I followed the detailed guidance of my product manager, as he had already a clear concept for this new version of the product. In this initial design stage I deliberately positioned myself as his “right hand” to facilitate the visualization of his vision. He was the knowledge expert and conveyed all the complicated details that needed to be addressed.
My research showed that the main element of a planning tool consists of a vertical time line grid segmented into approximately 5 days. The top of the grid represents the current time and the bottom the 5 days from now. Above the time line grid is a simplified representation of all available berths, with dots indicating Bollards.
since the user journey map put the focus on step 3 (continuously updating a vessel visit), we prioritized the design of the timeline grid
A rectangular box on the grid represents a “vessel visit”. The width of the rectangle equals the length of the ship with the left and right side indicating the bollards allocated to it. The rectangle’s hight measures the time the vessel would be berthed at the terminal. Thus the top of the rectangle shows the cargo ship’s “Time of Arrival” and the bottom shows its “Time of Departure”. How long a ship needs to stay at a terminal is calculated by the amount of cranes available as well as the amount of containers to be unloaded and loaded (aka “Crane Moves”).
adding vessel visits to the time line grid
the first draft quickly grew into a highly complex modal for managing all data of a vessel visit
The first draft quickly grew into highly complex modal. A challenge was to reconcile all the technical requirements with the best ux/ui practices like simplicity or usability. However it gave me a much better idea how to approach these issues moving forward to the next iterations.
Constraints
Advocating best practices
Several challenges had to be addressed for the GA release:
-
integrate improvements based on prior user feedback
-
create an MVP version that meets the road map’s requirements as well as fits the bandwidth of the engineering team
-
implement Navis “Atomic” design system which was still in development
-
drive further optimization of usability and simplicity of the user interface
Bringing a new product to market is a collaborative effort of the entire team. Compromises have to be made, even if this goes against the best practices of design. Fortunately the iterative release cycles of the agile development process allowed me to formulate long term goals that helped me to achieve a first class product design. I advocated for ux/ui improvements even if the team was rather focused on technical priorities. I kept making the case with mocks and diagrams for important design changes until finally I've got enough buy-in from the product manager and head of engineering to prioritize the appropriate tickets. The next release was a vast improvement in the overall look and feel of the product and even the executive staff was impressed.
a redesign improved the UI and added many features
At that time Navis started to put more focus on web and mobile application development for which it hired another designer. He established the atomic design system that the company wanted to be applied for all it’s software products. We collaborated together in order to extend the design system so it was also applicable to the berth tool.
Collaborated with a fellow designer on the company's "Atomic" design system
Iteration
Continuous design improvements
The redesign of the berth tool addressed the previously cluttered modal, by having a more simplified input layout as Position, ETA/ETD, moves and cranes each got their own tab. I also separated the “calculator” and merged it with the graphic representation of the operation time line.
maturing the design and streamlining the modal layout
An important concept in human computer interaction (HCI) is the “metal model”. Mental models are what people really have in their heads and what guides their use of things. "In other words, the designer designs a conceptual model into the system in order for it to appear graspable and coherent to the user. (https://www.interaction-design.org/). If an established mental model can easily be applied to a design of a product then it can be a great gain for its usability. Google calendar was widely adopted and constituted the standard for many people in the industry. It’s timeline with events and hover interactions showing a floating preview panel was very similar to the main berth window planner interface. With key ui and ux elements adopted to the berth planner tool, the user experienced a sense of familiarity and intuitively started interacting with ease.
Another concept was the compact layout and high density design for input modals. This stands in contrast to design trends primarily in consumer applications where only few elements surrounded by a lot of white space suggest a simple interaction. User testing however showed that professionals in the supply chain industry expect a compact design from their enterprise solutions. Their hands were mostly on the keyboard hitting just a few standard key commands to advance to the next input filed, speeding up their data logging flow.
the floating panel took advantage of a common interaction pattern established by google calendar
Business Needs
Leveraging design to meet financial goals
The supply chain industry is rather conservative as many are managing their internal data chaos with a patchwork of self made solutions. Although the new berth tool convinced a lot of our clients, they needed more incentives to dare a change. Sales came up with special pricing but there was also more potential in product design.
I developed two initiatives with the goal to support the adoption of the new berth tool. One was a concept to add a simple mobile application that presented a summary of the latest vessel schedule updates. A simple list shows berthed and incoming vessel visits providing a quick and easy to read overview of the current situation. Operations managers, stowage planners, controllers or shift managers could now do a quick check of any potential consequences for their departments. The mobile app itself was a simple task for our engineering team and sales was eager to add it to their package deals.
The other initiative stripped any advanced features from our ever growing berth tool and was offered it as “Berth Light”. A lower subscription cost lured existing clients as well as new ones into giving it a try. This “land and expand” strategy enabled our sales team to be more creative with subscription packages. The engineering team only needed to bundle certain features and turn them on and off independently from the main app.
Next Steps
Rapid feature development
Once basic functionality for the berth planner was established, a high amount of feature requests by management and clients filled the backlog of our pipeline. The roadmap included tight deadlines for many new functionalities to be added to the tool. The perfectly clean design of the top tool bar for example was about to become overloaded! Fortunately I reminded myself of the book “The Laws of Simplicity” by John Maeda. It states that complexity can be reduced by organization and categorization. Sure enough, most of the new features could be organized into distinct groups and categories. Simple design elements like drop down menus were implemented, making more buttons in the tool bar unnecessary. As the company’s atomic design system matured, I could also take advantage of an collapsible and expandable side bar. It’s vertical layout was scalable enough to hold an increasing amount of icons as new features were introduced.
new features like tides or crane shifts were added to the side bar
A more creative approach was taken for planning features that required the whole width of the browser window. In the legacy version, the static crane allocation graph across all berth sections was inserted on top of the timeline grid, taking up valuable space. We implemented an innovative floating panel the user could activate as needed and drag it across all vessel visits. This made the crane graph much more contextual.
For the administration part of the software I designed various configuration flows for print layout, vessel visit box label customization, units for measurement, safety distances etc. Vessel visits on the time grid can also be displayed as a table with all information sorted into columns. The table was also customizable, sortable and featured filters, time range settings, color codes, ocean carrier logos ect.
for the admin section I designed complex tables and configuration flows
Impact
Measuring Usability
After the official release of the new berth tool a few early adopters started using the application. This was an opportunity to measure a few design KPIs. One way to obtain quantitative data was the implementation of a few code snippets from Google Analytics. We then created a dashboard in Google Analytics to measure features used, frequency of usage, error rates and time spend on key pages like the time grid or amount of actual vessel visits.
To generate qualitative data we came up with a survey that inquired aspects of overall ease of use, pain points or suggested improvements and reviews. Overall the findings were encouraging and enabled us to implement further improvements in subsequent releases.
Result
High adoption rate driving ARR
In time, the berth tool became more mature. Its updated look and feel and numerous features made it an attractive product on the market. The amount of new terminals to sign up for a trial or even committing to a multi year subscription grew steadily. The berth tool quickly became one of the most successful products in Navis’ expanding software portfolio. Meeting the subscriber goals, Navis was able to significantly grow it’s ARR model!
Learnings
Inclusive Design process & positive team culture
Although there were a few changes in personal over time but our small development team was well established. A key factor that made our work so successful was collaboration and trust. Despite stressful deadlines and numerous challenges our communication was always professional, respectful, collegial and mutually supportive. I made sure that my design process was transparent to the team and inclusive. Early involvement of engineering in discussion between myself and the PM kept everyone in the loop and avoided misunderstandings that would have cost valuable time. To see that our hard work paid off in bringing a new product to the market that was well received by our customers instilled a sense of pride in our team.
