top of page
Long_ERS_logo.png
ruler_black_edited.png

ERS DRIFT

• SOLE DESIGNER
• 6 MONTHS

The Emergency Response Service (ERS) of DNV provides 24/7 shore-based damage control support to ocean vessels and offshore units. In the case of maritime emergencies, their experts advise ship operators/owners about risks, consequences and possible courses of action. One common emergency is when ships lose their engine power and become stranded at sea; this could quickly deteriorate into dangerous situations when the vessel starts drifting uncontrollably due to ocean currents. Thankfully, today ocean sciences are advanced enough that computer simulation models can actually predict object drifting trajectories in real time. However, most commercial products in this area suffer from poor user experience. This is unfortunate as the maritime industry as a whole lags behind in terms of digital transformation. Hoping to increase their response efficiency during actual emergencies, ERS came to my team at DNV Digital Solutions asking for an easy-to-use tool suitable for a variety of emergency scenarios.

DriftIntro.jpg
RESEARCH

RESEARCH

Interviews

This project proved to be difficult from the start. Because our service was billed by the hour, the clients did not want to pay for something as nebulous as “user research.” Initially, the client representatives from ERS were very straightforward with their functional demands. I had to reach out to the ERS representatives and advocate for better user experience. By building a whole new product, we had the opportunity to make the lives of both our customers as well as our own service operators a lot easier, thereby making the entire service more efficient and attractive. Through a number of interview sessions I asked the ERS clients to walk me through their daily work involving drift prediction.

User Journey

By outlining the step-by-step ERS procedure during an emergency, I traced the flow of drift prediction data as it changes hands from the API provider, to ERS, to various stakeholders in the emergency. Very quickly I realized that the biggest hindrance to user experience and operation efficiency lied not with data generation, but data sharing. Namely, the sharing of data from on-shore offices to vessel operators and search-and-rescue personnel at sea, who are likely to be working in hostile and high-stress environments. Despite such demanding conditions, most communication between the ERS and its partners was still done through phone calls, emails, and PDF documents with page after page of tables and charts.

Drift_journey.png
Drift_problem.png
Competitive Analysis

The design challenge now focused on finding a way to efficiently share complex trajectory data with multiple touchpoints suitable for emergency rescue. With that in mind I began competitive analysis, which also proved to be quite difficult. First, there were simply not that many competitors on the market, as drift prediction was still a very emergent and niche service. I then looked into similar products such as shipping route planners and SAR coordination tools, but even then many did not address my specific needs — and generally had poor UI.

Drift_comp_analysis.png

My breakthrough came from a very unexpected source: hurricane forecast apps. Although at a glance not at all related to ship drifting, they also visualize a predicted path within a specific time period. One detail quickly caught my eye: many forecast apps have a timelapse feature, with a playback bar showing animation within a set time period. This was the inspiration I'd been looking for.

Drift_inspiration.gif
IDEATION
IDEATION
Design Requirements

A timelapse animation is not only an effective way to visualize the highly complex drift prediction data, it is also easily sharable across web and mobile platforms, suitable for the type of emergency scenarios our users are likely to be engaged in. With a clear idea of the type of product we are going to build, the rest was a matter of translating the design concept into concrete requirements. Based on the list of "must-have" and "could-have" requirements, I then built out a 3-tiered proposal to present to client representatives. The intermediate plan was chosen as the most cost-effective option.

Drift_requirements.png
Drift_proposals.png
Flows & Sketches

With design requirements now finalized, I went ahead to plot out the user task flows for each requirement. I then extracted from the key tasks the functional content needed on each page of the application and sketched them out on a whiteboard. As soon as I had gathered all the necessary information, I moved on to building the protoype.

Drift_sketches.png
PROTOTYPE
Low-fidelity Wireframes

Although each page's content had been confirmed, the specific UI still required exploration. I performed some crazy-8 exercises to brainstorm different layouts, and developed some of my favourite ones into slightly more detailed mockups to present to the client representatives. After working with them through a few rounds of workshop sessions, we were able to agree on a general design.

Drift_lofi.png
High-fidelity Prototype

After multiple rounds of design workshop with the client representatives and our frontend engineers, I finally built out a fully interactive prototype using UXPin. In spite of the timecrunch (going through user research despite not being billed for it) I was able to deliver all design material on time for development. I then proceeded to work with the frontend engineers on implementing our company's design system.

Unfortunately due to NDA I cannot share the full prototype. You can read more about the ERS Drift tool on the DNV website.

Drift_hifi.png
PROTOTYPE
REFLECTION
REFLECTION

Overall, ERS Drift was definitely a hectic project for me as a designer. At the very beginning, trying to advocate for UX research with customers who were UX-minded was a big challenge. Later on there were some requirement changes by the customer, so I had to coordinate very closely with the project manager and engineers to ensure minimal disruption to their development work while drafting new designs. Initially we were also missing a frontend engineer on the team so I often found myself having to jump in and help on the CSS. 

Ultimately though, we were very successful with the final delivery. A company-wide internal demo was held in Norway, and the product was very well received by the customer. The new tool is able to greatly automate ERS’s prediction reporting workflow, bringing what used to be almost half an hour of manual compiling down to as fast as 2 minutes. ERS Drift is now being used by DNV to support almost 5000 registered vessels worldwide.

Drift_final.gif

ERS Drift also turned out to be one of the most interesting projects I’ve worked on, and definitely one that I am very proud of. If the other projects showcased my understanding of methodologies, then this is definitely a test of my flexibility in communication and collaboration, the ability to find inspiration from unexpected places, and of course being proactive with the customers to own the product.

bottom of page