Deckhand
Streamlining the reporting flow and onboarding for a legacy system.
Deckhand is an electronic logbook that allows fishermen to report catch, trip activities, and location data to the NZ government.
PROJECT SUMMARY
Background: We collaborated with Dragonfly, a data science company that manages the data sets for Deckhand.
Challenge: To reduce the amount of support calls, then later expand into onboarding as a business opportunity.
My Role: I collaborated closely with the stakeholders and fishermen to define the problems in the flow and worked on the end to end design process.
Team & Timeline: 4 UX design students, 5 weeks
Problem
The reporting flow was complex, error-prone, and hard to recover from, driving heavy reliance on customer support and increasing operational cost.
Data flow
Customer support team
Fishermen
Design process
Product tear down: Found usability gaps and constraints.
Usability testing: Validate key friction points for the current state.
Service blueprint: Mapped user actions, flow and support touch points.
User interviews: To understand mental models and real-world constraints at sea.
Low-fi designs: Explored multiple ideas for simpler reporting flows.
Comparative usability testing: Tested concepts side by side to validate assumptions
Final concept: Refined the strongest direction.
Understanding the current experience
Current state usability study
Usability study was conducted to understand the flow as well as the common problems when completing the report.
4
2
3
1
1
Users found it difficult to understand which report is active and what stage of completion they are in.
2
Users interpreted the ‘Active’ icon for hamburger menu.
3
Icons are used without supporting text, making them hard to interpret.
4
The scrolling area for the selection field was obstructed by the keyboard.
Lack of confirmation screen caused users to return to step one after submission making it unclear whether the report was complete.
Key insights from interviews
Users: 5 fishermen, 2 customer support
Result
Customer service team provided us information with the recurring problems.
Fishermen helped us understand the real world issues at the sea.
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
The app uses icons without labels which makes it hard for users to communicate the symbols to the support team.
F11-s, F8-f, F16-s, F10-f, F5-f, F8-t
Insight 2
Due to lack of an onboarding process, the older fishermen found it difficult to transition from paper to e-logbooks.
F7-f, F8-f
Insight 3
The app uses icons without labels which makes it hard for users to communicate the symbols to the support team.
F11-s, F8-f, F16-s, F10-f, F5-f, F8-t
Insight 4
Common issues included internet failure, logbook renewal errors, and accidentally creating extra reports, highlighting the need for clearer error communication
F11, F8-f, F16, F5-f
*The alphabets and numbers indicates individual findings from users which helps to track exactly where the insight comes from.
Design decisions
Low-fi concepts
We focused on how users can complete the report faster by adding:
Recent selections for fishing methods
Saved addresses for landing.
App info and FAQs for troubleshooting or when reaching out to customer support.
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.
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.
Concept 2
This version focused primarily on redesigning the sidebar and report completion.
Concept 3
In the third 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.
What we found?
Shortcuts and hint can efficiently improve the user experience, especially for some repeated tasks.
Keyboard was still a challenge with elements being hidden behind it.
Timer as a progress bar on the concept 3 had the most positive feedback.
Mid-fi -Final concepts
Before
After
Problem: Keyboard obstructing the selections on the drop down menu.
Solution: The keyboard is hidden on scroll to reveal more options and on click it pops back.
Before
After
Problem: Users struggled to figure at what stage of the reporting process they are in and circular timer.
Solution: Clearly presenting the states and a timer which lets users know they have to complete in the given time.
Change of project scope
Context for onboarding
Deckhand’s offline capability created a strategic advantage in offshore conditions where their competitors lacked in connectivity, making onboarding important for new users to understand the system quickly and use it independently.
Goals
Give users a quick understanding of how reporting works.
Idea : Onboarding consisted of introducing the reporting flow in 4 simple steps.
In the second half of the onboarding users are taken through the UI elements in a progressive manner, helping them understand each element and its function.
Learnings & Trade offs
Discoverability vs UI space: 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.
Usability over visual improvements: We mainly focused on the core usability structure for the app even though we where constrained by the existing system design.
Error prevention : Confirmation, success screens and reviewing of reports added extra steps but helped users catch errors before submission.
Value of cross function research: Talking to customer support teams early helped us point in the right direction of the problem, combined by interviews with fishermen gave us real world insights.
Project 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.
Request a case study
Want to learn more about this project?
Get in touch to request a case study.
Next project
Want to learn more about this project?
Get in touch to request a case study.