ShipShape

Keeping seafarers safe, with an HSE incident reporting app

Visit project
App
Design System
Product Design
UI/UX Design
Concept

Project Overview

When at sea on a cargo ship, seafarers need to be able to quickly and accurately report hazards and incidents so safety compliance is achieved. I set myself the task of creating a concept HSE (Health, Safety & Environment) app to manage the reporting of this information.

I have approached the task as if it were a real-world project, undertaking research to understand the business and user needs, mapping out the user journey, creating wireframes to document the process and so on. To keep the project focused on the business and user needs at all times I have followed the Design Thinking process.

Design Thinking

1. Understand - Discover, Define

Setting the context

Basic research established that this type of app falls under the banner of HSE (Health, Safety and Environment) Management. HSE software is designed to help individuals, businesses and organisations ensure standards compliance with established HSE protocols and guidelines. Common features of HSE apps are: checklists and forms for inspections, Geo-tagging for monitoring remote workers, HSE incident reporting on-the-go, insights and reports and so on.

Competitor analysis

Basic competitor analysis reveals the types of features and functionalities this kind of app/software should contain.

Competitors

User research

In a real-world situation I would conduct user research with a broad cross-section of the app’s potential user base. Information I would like to establish is:

  • Who are the users, i.e their role within the maritime organisation, gender, age and so on?
  • What are their priorities regarding an HSE incident reporting app?
  • How frequently would they use it?
  • Where are they mostly likely to be when using the app?
  • What time of the day would they most use it?
  • Could any potential adverse conditions arise that might impair their ability to use the app?
  • Which devices will they use to access it?

User personas

Working to some assumptions, I created two typical user personas, outlining their needs, frustrations and specific use cases.

Personas
User Cases

Defining the problem statement

If more detailed user research were possible I would list and prioritise the problems the users face when currently reporting hazardous incidents. I would then list and prioritise potential solutions to the problems. Based on this data it would then be possible to define a problem statement(s) to provide focus for the project.

A typical problem statement for an app like this might be:

Problem Statement

2. Explore - Ideate, Prototype, Test

User touch points, journey map and app user flow

In order to help shape how the app should flow and function, I outlined the key user touch points. I then created a journey map, paying particular attention to the pain points and opportunities. Finally I mapped out the user flow to establish the app logic.

User Touch Points
User Touch Points
Journey Map
User Journey Map
User Flow
App User Flow

Sketches and wireframes

Bearing all the research, user data and problem statement in mind, I started to roughly sketch the app layout and flow. I then turned these sketches into a low fidelity wireframe prototype. The wireframes allowed me to explore the content and layout hierarchy in more detail.

Wireframe Sketches
Wireframes

Usability testing

In a real-world situation, user testing would be done on the low fidelity wireframe prototype. The objective of testing at this stage is to identify any problems or improvements before moving on to the final implementation phase. Once testing is complete, a high fidelity prototype can be designed. I performed my own basic testing and not everything in the wireframes found its way into the final designs as a result.

ShipShape App Usability Testing

3. Materialise - Implement

Building a design system

Establishing a design language is an important part of any digital project. I created a simple design system, consisting of colours and shadows, typography, buttons, inputs and icons. With these building blocks in place, I was able to move into the final design phase.

Design System

Creating a high fidelity prototype

Circling back to the problem statement, I kept in mind the importance of making an app that would be quick and easy to use. I designed the key screens and created a simple working prototype.

High Fidelity Prototype

Click here to view a live version of the prototype.

ShipShape Sign In Screen

4. Retrospective

Looking back at the project, there are a couple of things I would change or do differently:

  • Given more time I would like to create light and dark modes
  • The app might be used at any time of the day or night and in any kind of weather, soI now feel that the form inputs and labels should be clearer/bolder
  • I also think the form structure could be simplified - imagine a user trying to fill out an incident report at night in a storm, whilst holding on to a hand rail (so using the app with only one hand). It might be better to allow them to simply take a picture and have the app report the date and time automatically. They could then go back and fill out more detailed information later if required

Summary

To recap, I designed an incident reporting app for seafarers. The app had to be easy to use, and provide a quick and accurate way to submit reports. I believe I have created a strong solution to the problem. If this were a commercial project I am confident that users would be happy to use it on a daily basis.

  • Based on my experience in UX design for ecommerce, I tried to imagine what would be most important for users in this case
  • I tried to keep the hierarchy and layout as simple as possible, removing unnecessary text and elements where possible so as not to overwhelm the user
  • Accessibility was a consideration, for example text sizes, contrast levels, button and link clarity
  • I chose to present a single page report form for ease-of-use - multiple page forms make it harder for the user to go back and edit what they’ve entered
  • Next steps would be to go into the more detailed elements of the prototype, such as error handling, interactions/animations and so on