The Dive Ops team at the Georgia Aquarium is responsible for all underwater activities, including fish feeding, tank cleaning, and animal training. Each dive is overseen by a dive tender, someone who's responsible for ensuring divers' safety and recording relevant details from the dive. The tender would have to log this information on paper, which would need to be re-entered through a desktop-based software- all of which could be cumbersome and inconsistent.
‍
A team of 2 other designers and I were tasked to design a tablet app for tenders to be able to log dive information at the time of the dive, challenged with creating something that matched their existing workflows as seamlessly as possible.

On-site interviews and contextual inquiry formed the backbone of our research.  Three key insights emerged after interviewing seven different groups of dive tenders:

1. Navigational flexibility is key. Because there are multiple dive types, diver types, equipment types, dive objectives, and different sets of information required for each of these categories, dive tenders may find themselves entering information in a slightly different order for each dive. Paper dive logs provided the flexibility that dive tenders needed, so we wanted to mimic this flexibility:

2. Tenders have a specific rhythm & user journey for data entry. so while our design needed to provide flexibility, it also needed to match the general workflow for a dive tender:

3. Information architecture will need to lead the way. with so much information that needed to be captured in the limited screen size of an iPad, the usability and success of this design would ultimately be grounded in information architecture.

Whiteboarding: We began our brainstorming process by white-boarding all the questions we could come up with that might apply to the dive log process to identify the boundaries of the project.  We jokingly called this 'what is water?' to remind us that questions about the basics of diving were as important (if not more so) than anything else at this early stage.

HMWs & Affinity Mapping: We organized our brainstormed questions by turning groups of them into 'how might we' (HMW) questions -- things like 'how might we make data collection quicker?', 'how might we ensure easy input for multiple users?' and 'how might we gather all the data that users want/need to see in a dashboard?'. We then used affinity mapping to group similar concepts and guide our feature development.

Sketching: We sketched separately and as a team to brainstorm different concepts, quickly settling on a design from which to build out our first set of wireframes.

User Flows: And, we built out the user flow and data-entry flow for different dive-type scenarios to ensure that our first iteration prototype would function according to the tender workflow.

Lots of Wireframes: Even at this early stage of the process, our wireframes changed and evolved as we developed them...

Initial user tests with key stakeholders and users gave us an opportunity to determine whether our navigation was intuitive and how it matched the dive tender work flow.  Three key comments from users led to critical iterations in the prototype:

User tests with eight different tenders gave us 2 more insights about how to improve the app:
1. Most tenders appreciated the guiding orange bar, but the briefing checklist and inventory icons were not obvious at the bottom of the screen.  Moving them to the top right corner brought them into clearer view for the user.
2. Tenders were not accustomed to using the scrolling feature to select diver names, and instead preferred the search and autofill function. Removing left module of scrolling names saved additional space and further streamlined the app, while better matching tenders' workflow.

Log in and home screen: Dive tenders enter their credentials and begin to log information about a particular dive on the home screen. By requiring the tender to identify their dive as an Aquarium, Field, or Guest dive, we ensure that they are prompted to collect the correct information.  At the same time, the design prioritizes flexibility, allowing tenders to enter information in whatever order they choose, or to skip this screen for the time-being and proceed to entering diver information.

Diver Entry: Tenders enter each dive name by typing directly into the "Diver Name" field, while the app autocompletes based on the letters entered.  This matched the process that dive tenders are most comfortable with and accustomed to, and was also flexible enough to also be used for entering guest divers who are not already in the staff & volunteer database.

Diver In, Diver Out, and Briefing Checklist: Before dive tenders can log the time in for each diver, they are required to review a briefing checklist with the dive group.  To ensure that this step takes place the "Time In" entry fields only appear once the briefing checklist has been opened and reviewed.

Inventory Checklist: In exhibits with birds and/or mammals, divers are required to record all equipment and personal items that they take into the tanks.  Here we incorporated an error-handling feature to alert tenders when the number of items coming out of the water does not match the number of items that went in. Again, with flexibility in mind, dive tenders can close the inventory list while there are still errors, but cannot close out the dive until all items are recorded as out of the water.