works

about

works

about

Deckhand

15 min read

An electronic logbook that allows fishermen to report catch, trip activities, and location data to the New Zealand government.

Background

Dragonfly is a data science company that manages the data sets for Deckhand.

Role

End to end UX role

Platform

iPad

Team & Timeline

4 UX designers

5 weeks

Background

Dragonfly is a data science company that manages the data sets for Deckhand.

Role

End to end UX role

Platform

iPad

Team & Timeline

4 UX designers

5 weeks

The project was divided into two products Deckhand and Right time, Right Place dashboards. In this case study we focus on Deckhand with its usability improvements and onboarding.

Initial Problems

High support call volumes

The reporting process was so complex that new users relied entirely on customer support to complete their tasks.

Increase in operational costs

The troubleshooting calls were long and frequent forcing the business to scale their headcount for support team.

Goal

Solution

Index

Jump to section

Problem

Research and insights

Design concepts

New challenges

Outcomes

Current questions

What frictions and confusions arise from the current Deckhand workflow?

What are the most common and time-consuming reasons for users to call customer service?
What are the use-cases and mental models of the users, and how do these conflict with the current design of the app?
Which information or tools would help users to support themselves better?

Understanding the system

Data flow

Secondary research

Desk research

We focused on common breakdown points across reporting workflows, including report generation, submission and error handling.

Product teardown

In the process of analysing Deckhand, we found that many usability issues were related to the product's context.

The data in the dropdown menu is covered by the keyboard making it hard to scroll.

The icons are unlabelled making it hard to interpret their action.

After completing a fishing report, users are returned to first step which is selecting the fishing method to log the next fishing set. Without a confirmation screen, this causes confusion, users expect to move forward to the next step rather than restart the flow.

Primary research

To validate our assumptions we conducted Interviews and Usability tests with the original product.

Interviews

Users

3 Customer support members

Type

Internal user

Internal user

Goal

To understand the recurring issues using support tickets.

Users

7 Fishermen

Type

Non-technical

Non-technical

Goal

To understand the real world usage of Deckhand under environmental limitations.

Sample questions (Fishermen)

How often do you receive calls from customers?
At what times of day do they usually call?
What are the top three issues they raise regarding the Deckhand app?

Sample questions (Support team)

Can you describe how you use Deckhand during a typical fishing trip, from starting the trip to submitting your catch?
Have you ever made mistakes or felt unsure while entering data? What caused that?

Current state usability testing

Users

4 Dragonfly employees

Type

Marine scientists

Marine scientists

Goal

Observe how users interact with the current flow and evaluate between system logic and user expectations.

Observe how users interact with the current flow and evaluate between system logic and user expectations.

Key findings

Finding 1

The reports on the side bar is hard to understand as it doesn’t indicate the progress of the fishing event.

A2, A14, A15, B12, B22, B27, B28

Finding 2

The end trip button is buried under a menu and its not easily accessible.

A4, B22, D4

Finding 5

Support agents needed system details (iPad version, OS, Deckhand version) before troubleshooting. Manually retrieving this scattered info was difficult for non-technical fishermen, wasting critical support time.

A1, A13, A15, B30, D3

Finding 3

When the keyboard is active, it hides the data input fields, obscuring important information from view.

B30, B31, D2

Key insights from interview and usability test

Fishers struggled with hidden gestures, unclear user flows and unlabelled icons resulting in steep learning curve and limited error recovery methods when stuck.

Insight 1

Fishermen often felt confused and hesitant while using deckhand due to unclear terminology, hidden gestures, and unhelpful error messages making it difficult for them to understand what was happening on the screen. Thus creating frustration and increased their dependence on customer support.

F4-s, F9-s, F4-f, F8-f, F8-s, F13-s, F5-f, F10-f, F2-t, F3-t

Insight 8

Due to lack of an onboarding process, the older fishermen found it difficult to transition from paper to e-logbooks, finding their own means of coping with the transition also causing a huge learning curve.

F7-f, F8-f

Insight 4

Fishermen found the interface visually difficult to use because the interface relied heavily on unlabelled icons for identification and low contrast elements, which made it harder for them to communicate these icons with the support team.

F11-s, F8-f, F16-s, F10-f, F5-f, F8-t

Insight 7

Some of the common problems fishermen encountered where internet, Bluetooth connectivity failures, Logbook renewal errors and accidental creation of additional reports. This shows that there is a need to communicate these errors clearly within the product.

F21-s, F6-f

*The alphabets and numbers indicates individual findings from users which helps to track exactly where the insight comes from.

Designing concepts

Low-fi concepts

This prototype focused on improving the display and interface of the workflow, as well as clarifying key operations.

Problems that needed to be addressed

Users need to clearly understand which stage they are currently in within the overall workflow
Users need to easily distinguish between different report types.
Users need to understand the purpose and meaning of the timer displayed in the report section
Users need to be able to clearly differentiate between interactive elements such as dropdowns, labels, and buttons

Feature solutions

System info

Grouped all device diagnostics in one place, eliminating the need to manually search during support calls.

Offline troubleshooting

Fishermen can troubleshoot independently, even when stranded at sea with no network connection.

Quick selections

Addition of 'recently used' section and 'saved addresses' to remove the friction of repetitive manual data entry

After performing a quick usability test with our low-fi concept we found:

Users couldn’t easily tell reports apart or track progress
The circular timer confused users, with some mistaking it for a report progress indicator.
When the keyboard is active, it hides the data input fields, obscuring important information from view. We cannot change the structure of keyboard so had to find alternative solutions

After performing a quick usability test with our low-fi concept we found:

Users couldn’t easily tell reports apart or track progress
The circular timer confused users, with some mistaking it for a report progress indicator.
When the keyboard is active, it hides the data input fields, obscuring important information from view. We cannot change the structure of keyboard so had to find alternative solutions

Challenges

Deckhand is an iPad-based app, but it doesn’t adhere to any of the rules or interactions principles of the iPad system.

We had to consider existing users and avoid making drastic changes to the product, which meant exploring multiple solution options.
The fishermen where not accessible so usability testing was mainly conducted with Dragonfly staff. Therefore some of our findings may not reflect real world usage scenarios.

Deckhand is an iPad-based app, but it doesn’t adhere to any of the rules or interactions principles of the iPad system.

We had to consider existing users and avoid making drastic changes to the product, which meant exploring multiple solution options.
The fishermen where not accessible so usability testing was mainly conducted with Dragonfly staff. Therefore some of our findings may not reflect real world usage scenarios.

Design decisions

Comparative usability testing

Due to limited access to fishermen, we tested 3 concepts with 3 Dragonfly employees who where new to Deckhand. The testing focused on reporting panel, timer and report status.

Concept 1

This version explored different ways to enter data, while accounting keyboard as a major constraint for space.

Using a circular timer with a countdown to show the time left to submit the report

Providing a quick selection tab along with a scrollable list of all the fishing methods and species

Exploring different ways to show the report status card as well as guiding users on when to take an action.

Exploring the placement of End Trip button

Concept 2

In the second version, we explored ways to display text fields within the dropdown menu and introduced a progress-bar-style timer to indicate the remaining submission time.

The in progress reports are highlighted with an active status along with a timer

On click the recently used options are shown as part of the entry point for fishing.

Concept 3

This version focused primarily on redesigning the sidebar and report completion.

The entire report status is redesigned to have pending, In progress and completed tabs.

The card is minimised when not in active state.

The report card has been designed to show a timer, submission status and key action buttons.

Adding a collapsable side bar so fishermen have more real estate space on smaller iPads.

The report section can be minimised when not in active state.

This version also has success screens and reconfirmation of actions so errors can be prevented.

New challenges

Context for onboarding

Goal

How might we provide a glimpse of how the reporting flow works to the users even before they start?

The onboarding consisted of two parts, introduction to the reporting flow (4 steps) and progressive walkthrough of the interface.

Adding a collapsable side bar so fishermen have more real estate space on smaller iPads.

This section would consist of a step by step video which shows someone completing the report.

Users can get the context of which part of the flow the video is connected to.

We guide users on where they could find different elements on the UI.

At every point we provide users with a choose slowly gaining trust.

Proposed solution

Final designs

We concluded our project with mid-fidelity designs. Since Dragonfly had limited access to change certain system details and visual design, so we provided them with suggestions that intentionally focused on fixing the core usability and optimizing the flow.

Before

The report section on the left doesn't provide any context to what it currently shows.

With keyboard being a major part of the UI it provides only two selection items at a time.

After

The entire report section is redesigned to provide more clarity with new status indicators and countdown timer.

Improved data entry by hiding the keyboard on scroll to reveal more dropdown options.

Before

After

The empty state clearly tells the user what they should expect from the space.

The empty state clearly tells the user what they should expect from the space.

Before

After

The revised design raises the input field of keypad for better visibility, increased the size of the submit button, and added double-zero shortcuts for faster entry.
Deleting a fish species previously relied on an undiscoverable swipe gesture; we added a visible delete button while retaining swipe for advanced users.

The revised design raises the input field of keypad for better visibility, increased the size of the submit button, and added double-zero shortcuts for faster entry.
Deleting a fish species previously relied on an undiscoverable swipe gesture; we added a visible delete button while retaining swipe for advanced users.

More changes:

The repetitive loop encountered when completing a fishing method was resolved by clarifying progression through UX copy such as “Start set 2.”
Multiple entry points for ending a trip were introduced, including a clearly identifiable primary action, while retaining the existing Actions tab workflow.

The repetitive loop encountered when completing a fishing method was resolved by clarifying progression through UX copy such as “Start set 2.”
Multiple entry points for ending a trip were introduced, including a clearly identifiable primary action, while retaining the existing Actions tab workflow.

Learnings

Trade-offs

Adding visible controls like End trip button and status indicators made the UI busy, but we prioritised helping users quickly understand their progress and system status over maintaining minimal design.
We mainly focused on the core usability structure for the app even though we where constrained by the existing system design.
Confirmation, success screens and reviewing of reports added extra steps but helped users catch errors before submission.

Adding visible controls like End trip button and status indicators made the UI busy, but we prioritised helping users quickly understand their progress and system status over maintaining minimal design.
We mainly focused on the core usability structure for the app even though we where constrained by the existing system design.
Confirmation, success screens and reviewing of reports added extra steps but helped users catch errors before submission.

Next steps

The next phase of the project will focus on creating a high-fidelity version of the final design. Due to time constraints, we were unable to create a complete high-fidelity version, only exploring aspects such as colour, visual hierarchy, and interactive states.
Although usability testing with the Dragonfly team was positive, but further validation is required. We need to test directly with fishers to prove the design holds up under their actual working conditions.

The next phase of the project will focus on creating a high-fidelity version of the final design. Due to time constraints, we were unable to create a complete high-fidelity version, only exploring aspects such as colour, visual hierarchy, and interactive states.
Although usability testing with the Dragonfly team was positive, but further validation is required. We need to test directly with fishers to prove the design holds up under their actual working conditions.

Let's connect about the next big thing.

rohitmohan093@gmail.com

Behance

About

Case study

Let's connect about the next big thing.

rohitmohan093@gmail.com

Behance

About

Case study

Next Project

Right Time, Right Place

Data driven dashboards for fishers.