Launching Shipnoise to Quiet Commercial Ships for Orca Conservation

Orcasound

My Research Identified the Need for Pilots to Listen to Their Commercial Ships in the Salish Sea

  • Research indicated that Pilots have tried to listen to the ship they piloted on Orcasound’s hydrophones but were unable to

  • Shipnoise is designed to allow Pilots to listen to a 30 second clip of the ship they will pilot or have piloted from Orcasound’s hydrophones

 

Large Commercial Ships in the Salish Sea Create Disruptive Underwater Noise to Marine Life

  • The endangered Southern Resident Killer Whales (SRKWs) are very sensitive to the acoustic landscape in the water

  • SRKWs communicate using calls, clicks, and whistles and use echolocation to hunt for their food source of salmon

  • The noise of commercial ships greatly impedes SRKWs’ ability to communicate and hunt

  • A solution is needed that quiets the waters of the Salish Sea by communicating to Pilots about the noise that their ship makes

 

Different Classes of Ships Involve Different Marine Roles, Potential End Users, and Quieting Strategies

  • Discussions with oceanographer stakeholders resulted in prioritization of classes of vessels to create a Shipnoise solution for

  • Classes of ships discussed were:

    • Ferries

    • Recreational vessels

    • Tugboats

    • Commercial ships

  • The class of vessel that stakeholders prioritized the highest was the commercial ship

  • Commercial ships are the loudest of all classes of vessels

Prioritization matrix used to choose Shipnoise solution for the commercial ship class

Team Members

  • 2 Stakeholders

  • 11 UX Researchers

  • 12 UX Designers

  • 1 Service Designer

  • 4 Developers

  • 2 Data Scientists

Methodologies

  • Interviewing

    • Persona development

    • Journey map development

  • Internal workshops

Project Duration

  • Jan. 2023 to present

🏗️

Deployment Status

👷‍♂️ PRODUCT UNDER CONSTRUCTION 🛠️

The main Shipnoise stakeholder prioritized commercial ships as they are the loudest in the Salish Sea

I Finished Research Started and Moved Shipnoise to Deployment and Use on the Web

  • I formed a product road map based on the information we had and what information we needed

  • My vision was to:

    • Build initial personas for key marine roles involved in the problem space

    • Create a commercial ship journey map

I used the UX Double Diamond as the Shipnoise product roadmap

The Shipnoise team was formed when I was working on other products at Orcasound. Product leader and UX Designer Rick led the team, and they began running interviews with contacts in the Salish Sea marine industry that were provided by the Executive Director and main stakeholder at Orcasound. Discussions during remote meetings and Slack helped build a direction for the Shipnoise project.

Rick prepared and presented a deck of findings and recommended next steps. I attended that meeting and envisioned how the team could move forward toward a solution. I shared my vision with Rick and others on the team.

Momentum on the Shipnoise team ground to a halt, and I finished up the work I was doing on other Orcasound products. I decided to pick up where the Shipnoise team had left off.

I rewatched the recording of Rick’s presentation and reviewed his deck in detail. The interviews that Rick and others had done provided a high-level view of the problem space:

  • The roles involved in the management and piloting of marine vessels

  • The participation of these roles in programs to reduce ship strikes with whales and to quiet ships

I formed and led a Shipnoise product team to help synthesize the large amount of data that was being gathered from interviews.

I Identified 6 Key Marine Industry Roles

  1. Nonprofits such as the Marine Exchange of Puget Sound

  2. Commercial ship Pilots

  3. Commercial ship Captains

  4. Commercial ship Agents

  5. The US Coast Guard

  6. Environmental Directors

I Created 4 Interview Plans

  • There were large gaps of missing information that I wanted to gather

    • I did not know:

      • Who the ideal end user was for commercial ships

      • What pain points end users needed to be solved so that they could quiet commercial ships

      • The workflows of ideal end users

      • Important details about Salish Sea marine roles that would determine an ideal Shipnoise solution

      • Where in the workflow of an ideal end user Shipnoise could be most impactful

  • I scheduled and moderated interviews with:

    • A Vice President of the Pacific Merchant Shipping Association

    • The Director of the Marine Exchange of Puget Sound

    • A commercial ship Pilot

    • A commercial ship Agent

The Team and I Synthesized 641 Pieces of Data Across 13 Interviews

  • I and the team took notes on all interviews conducted during the entire project to create data in a Miro board for synthesis

    • All the interviews had been recorded

    • The recordings were assigned to team members

    • Team members wrote notes

    • Stickies were written in Miro

Interview with a Vice President of the Pacific Merchant Shipping Association

I wanted to interview Subject Matter Experts for the Coast Guard and Environmental Directors, but I had to move on and determined I had enough data for other roles to make decisions.

  • I organized all data by interview

  • For personas and the commercial ship journey map I synthesized the:

    • Data (observations) into

      • Findings (patterns) into

        • Insights (interpretations)

Assigning interviews for data synthesis to team members

All data organized by interview

I Built 5 Skeleton Personas

  • I used John Pruitt and Tamara Adlin’s seminal book on personas- “The Persona Lifecycle”

Step 1: Identify Important Categories of Users

  • Since we already knew involved marine roles, we did not have to create categories of users through affinity mapping

  • I reviewed data and discussed important Salish Sea roles with the tea

  • I identified 5 important roles to build personas for:

  1. Commercial Ship Agent

  2. Watch Stander at The Marine Exchange of Puget Sound

  3. Commercial Ship Pilot

  4. Commercial Ship Captain

  5. US Coast Guard Operator

Step 2: Process the Data

  • The data we had was already associated with each role

Step 3: Identify Subcategories of Users and Create Skeletons

  • Roles (skeletons) were already known

Step 4: Prioritize the skeletons

  • I had a general idea of role prioritization:

  1. The Marine Exchange of Puget Sound

  2. Pilots

  3. Agents

  4. Captains

  • Prioritization would happen when I had a better understanding of each persona:

    • Needs

    • Access to and use of technology

    • Workflow during the commercial ship voyage in the Salish Sea

Step 5: Develop selected skeletons into personas

  • Now I could make use of the data that had been collected- developing skeletons into personas

The Persona Lifecycle book

I wanted to understand in more detail the important roles I had identified through the research that the team and I had conducted. This would help me understand what each role did and why during different stages of the commercial ship journey through the Salish Sea. This would also help me understand the ideal end user and when a solution should be built for- before, during, and/or after a voyage.

I followed the methodology outlined in the book for skeleton personas, with the idea that they would be fleshed out later with formal persona studies using the interview methodology as described. Since I had limited data on the important roles I had selected, I treated all information as if it were institutional knowledge.

I did not think that the Coast Guard was a viable end user, as their goal was not to mitigate sound pollution in the Salish Sea but to ensure national security of US waters.

I began by creating a templated “Foundation Document Table” that contained characteristics that helped to build personas.

Foundation Document template

I exported the table into Miro and made a copy for each of the roles I was building personas for. For the 5 roles I was building personas for I went through all of the data we had collected, placing data into cells of appropriate characteristics. Not every characteristic had data, which was OK.

Agent Foundation Document table in Miro

I created a templated “Foundation Document” in Google Docs and exported the data into documents for each persona. This is a living document that can be added to when more data is collected during future studies, including formal persona studies run by myself or other team members.

Foundation document for the “Watch Stander” persona

Now that I knew characteristics for each persona, I created a persona template in Miro …

Persona template

… and populated it with important information about each role.

Filled out Pilot persona

I also created an intro page for each persona …

Intro page for the Coast Guard Operator role

… and 517 “Did You Know . . .” pages to cover all data collected across all personas.

“Did you know …” Pilot example

I Built a Commercial Ship Journey Map

  • A commercial ship journey map would help me understand

    • What roles were involved during the commercial ship’s voyage in the Salish Sea

    • What Shipnoise solution should be implemented

      • Paired with addressing the pain point of an ideal end user from the persona work I was concurrently working on

    • At what stage of a commercial ship’s journey through the Salish Sea a solution would fit best

I chose a journey map template provided in Miro and followed the associated article, “An Introduction to User Journey Map + free User Journey Map Templates” (https://stephaniewalter.design/blog/an-introduction-to-user-journey-map-pdf-templates/).

I Followed the Steps Outlined in the “An Introduction to User Journey Map + free User Journey Map Templates” Article

1. Do Your User Research

  • Since interviews with Subject Matter Experts had been conducted, this step was already complete

2. Define User, Goal and Scope of the Map

  • The goal was to understand what end user to design for based on the journey map

    • I identified the end user later in the process (see below)

  • I came up with the following goal and scope for the journey map:

    • “A journey map for commercial ships that enter the Salish Sea or originate locally to understand how to decrease ship noise when orcas (SRKWs) are present that include mariner roles involved”

 

3. Identify Journey Phases

  • Based on the interview data:

    • I had a high-level understanding of the journey phases

  •  Commercial Ship Journey Phases:

  1. Pre-voyage planning

  2. Ship enters the Salish Sea

  3. Pilot boards ship from Port Angeles

  4. Ship voyages to port

  5. Ship waits to dock, anchors near port (dependent on circumstances)

  6. Ship docks at port

  7. Post voyage reporting

There were of course other steps, but I wanted to keep the journey as simple as possible and reduce redundancies to make the resulting journey map more digestible to those who would use it as a deliverable for design and development work. For example, I made the educated assumption that any solution that applied during the “Ship voyages to port” phase would equally apply to when the ship left the dock and voyaged out of the Salish Sea. We also had no data about the part of the journey when the ship left the Salish Sea, as no Subject Matter Expert discussed that.

4. List Actions and Tasks

  • I created tables for each of the roles through each of the journey phases

  • I listed actions and tasks by going through the data and placing individual stickies in the appropriate cell

5. Understand Emotions and Pain Points

Emotions, Thoughts, and Feelings

  • I created tables for each of the roles through each of the journey phases

  • Identifying emotions, thoughts, and feelings was a bit tricky

    • Interview subjects weren’t always forthcoming about their emotions

  • Where emotions, thoughts, and feelings were explicitly referenced in interviews

    • I included those in the table

  • I reviewed the data

    • I made some assumptions about what the prioritized roles might be feeling

Pain Points

  • Identifying pain points was a bit easier

    • I did have to make some assumptions based on what interview subjects said

      • I listened to their tone of voice for clues

6. Find Opportunities

  • Opportunities addressed the pain points I had identified

  • I moderated 3 workshops with Orcasound stakeholders

    • The goal was to ideate solutions related to quieting commercial ships

    • Stakeholder input was crucial to finding opportunities that addressed pain points

7. List touchpoints and channels

  • I identified communication channels at each journey timepoints for each role

    • I combed through the data for

      • Mentions of when and what channel each role used

        • Sometimes I considered that the role was a communication channel instead of a physical one such as a phone or radio

      • Who they communicated to

I Created a Journey Map Repository Document

  • I collated all data into a single repository table

  • The idea is that it would be a repository of all journey map data:

    • A living, dynamic document that could be updated at any time as new research either confirmed assumptions or added new data

  • Along the top of the journey map, I listed the commercial ship journey phases:

  1. Pre-voyage planning

  2. Ship enters the Salish Sea

  3. Pilot boards ship from Port Angeles

  4. Ship voyages to port

  5. Ship waits to dock, anchors near port (dependent on circumstances)

  6. Ship docks at port

  7. Post voyage reporting

A portion of the “Actions, tasks, and activities” table for Agents in Miro

A portion of the “Emotions, thoughts, and feelings” table for Agents in Miro

I wanted to have a clear definition of what a pain point was, as something that was just an annoyance shouldn’t be classified. I defined a pain point as something that blocked a goal and could have some sort of solution that solved the problem. For example:

Goal: Agents want to fulfill government requirements to coordinate foreign flag ship voyages in US waters to ensure national security

Pain point- cost incurred: Customs and other requirements, numbering over 100, that Agents take care of are complex and time sensitive

Pain points table for Agents in Miro

  • The workshops I moderated had 4 objectives:

  1. Ideate opportunities (solutions) that addressed the pain points identified from the interview data

  2. Decide who the end user was that we would design for

  3. Prioritize what the initial solution we would build by using a matrix that plotted the value of the solution to the SRKWs and the feasibility of deploying that solution

  4. Decide what stage(s) of the commercial ship journey that Shipnoise would be built for

I Built a Journey Map from the Repository Document

  • My vision was to:

    • Visualize the insights from the data

    • Quickly communicate important information

  • This was a challenge:

    • The journey map did not follow a single person through a step-by-step process

    • It followed 5 roles through a simplified commercial ship journey

  • Down the left side I listed the different types of data I synthesized:

  1. Actions and Tasks

  2. Emotions, Thoughts, and Feelings

  3. Pain Points and Opportunities

  4. Touchpoints

Portion of the pain points with opportunities table identified during the workshops I moderated in Miro

To prepare for the opportunities workshops I moderated, I built a simple journey map that included contextual information to help with ideation.

 

Each pain point was placed in a column according to the role they came from and the point in the journey they occurred. I sorted pain points into applicable and non-applicable columns. Applicable pain points addressed commercial ship noise in the Salish Sea, non-applicable did not.

Example pain point and ideated opportunity for Pilots from the workshops I moderated

During the workshops we spent time discussing identified pain points and ideating opportunities- potential solutions we could deploy using Orcasound’s hydrophone network, Dev resources, Acartia web-app, and relationships with organizations in our cooperative.

Portion of the “Touchpoints” table for Ship Captains in Miro

In some cases, I made educated assumptions based on my growing knowledge of the commercial shipping domain in the Salish Sea.

Portion of the Journey Map repository

Commercial ship journey phases across the top of the journey map

Journey Map aspects down the left side

I Had Two Objectives for the Personas and Journey Map

1. Define what Shipnoise would be:

a. Identify the ideal end user

b. Determine what solution would best address the problem of noisy ships

c. Understand when during the commercial ship voyage Shipnoise should be designed for

2. Socialize personas and the journey map with stakeholders and cross functional team members so that Shipnoise would be based on research

Rather than make Shipnoise what I or stakeholders thought it should be, I wanted to build a solution that was based on a combination of the objective (needs of Orcasound) and how an ideal end user would use it in the context of their role (needs of the end user).

I Moderated Workshops with Stakeholders and Cross Functional Team Members to Determine What Shipnoise Would Be

  • The workshops prioritized a list of 15 opportunities that addressed pain points

1. I and a team member looked through all ideated opportunities and chose 5 per major phase of the commercial ship journey:

a. Pre-voyage

b. Voyage

c. Post-voyage

2. I created a Google Forms that listed each of the 15 opportunities with a 10-point scale for two questions:

a. How feasible would Solution #(N) be?

b. How valuable would Solution #(N) be?

  • I asked team members and stakeholders to fill out the form

  • There were 13 responses

3. I averaged:

  • Responses per feasibility (X) and value (Y)

  • Standard deviations

    • To get a basic measure of confidence for data on which respondents agreed

4. I graphed the results on an X, Y matrix to understand which opportunities we should discuss

5. I scheduled workshops in which we discussed solutions that landed most in the upper right corner of the matrix- in the “Yes” square

Pilot End User and Solution Identified

  • The solution would allow Pilots to listen to archived clips of the ships they will pilot or have piloted

Choosing opportunities for the workshop

The form workshop participants filled out to rate the feasibility and the valuableness of potential solutions

Solution prioritization math

Prioritization matrix

Prioritization form focused on the noise of ships opportunities

During the second workshop, the Executive Director of Orcasound commented that most of the solutions were focused on listening for the Southern Resident Killer Whales and not focused on the noise of ships.

I went through the opportunities again and chose those that addressed the noise of ships. I created a new form for team members to fill out with 15 opportunities focused on the noise of ships.

I again calculated X, Y and the standard deviation for each opportunity.

Prioritization math for opportunities focused on the noise that ships make

Shipnoise opportunity chosen based on research, prioritization matrix placement, and workshops with stakeholders and subject matter experts

During the third and final workshop, we discussed the opportunities that addressed pain points focused on the noise of ships as graphed in the matrix most in the upper right. We chose the solution that was the most feasible and the most valuable.

During the interview with the Pilot that I moderated, they said that they had tried to listen to their ship in real time while piloting but couldn’t hear it. It was valuable to that Pilot that they hear their ship. Since Orcasound has a data exchange agreement with the Marine Exchange of Puget Sound, an organization that tracks all ships that use AIS in the Salish Sea, matching ships that pass our hydrophones would be technologically feasible.

Study to Understand Design Specifications Runs into Challenges

  • I wanted to learn from Pilots how the web-app should be

    • Including any additional features that would be helpful for them

  • I wanted to run an interview study with Pilots

  • The president of the Puget Sound Pilots refused to work with me to run my study

    • Would not allow me to run an interview study

    • Initially said I could run a questionnaire study then refused

I wrote a study plan with the goal of interviewing a minimum of 10 Pilots based on the User Interviews article Sample Sizes in Qualitative UX Research: A Definitive Guide.

I reached out to the Pilot I had interviewed the previous year as they had been the President of the Puget Sound Pilots organization. They told me that there was a new President and to reach out to this new person.

I sent an email to the new President asking to discuss how I could recruit at least 10 Pilots for my study. We connected on the phone, and I was told that I did not have permission to record interviews with Pilots even though I would provide a consent form clearly stating that the information would only be used internally and not made public. They said that I could instead use a questionnaire to ask the questions that I wanted to ask.

After the call I created a Google Form that contained the consent form followed by the questions that I wanted answers to. This wasn’t the most ideal study format, as I would not be able to ask follow-up questions. However, any data would have been better than no data and I wanted to build a positive relationship with the Puget Sound Pilots organization.

I sent the questionnaire to the President of Puget Sound Pilots for their review and approval. I did not hear back and sent 3 more follow up emails over the next month.

I received a very formal and tersely worded reply that said the Puget Sound Pilots organization would not work with me but with their already established partners. I replied asking what I could do to deepen Orcasound’s relationship with Puget Sound Pilots so that we could be an established partner. Their response was that they had too many organizations that they work with and “could not” work with Orcasound.

I Devised New Plan to Release a Most Viable Product Version of Shipnoise

  • Based on the research that I and others had already done

  • After Shipnoise is deployed:

    • Use my contacts in the Salish Sea marine space to send Shipnoise to Pilots

    • The web-app will include an invitation for users to opt-in to provide feedback

    • I would recruit Pilot users for future releases to:

  1. Improve existing features

  2. Build new features

I Learned That Each Step in the Journey Map Process Required Weeks of Work

  • Although the article I read was short

  • Part of this was because I hadn’t run studies to collect the specific data I needed

    • I had to comb through the data we had

      • Most of which was not relevant

  • To put together a journey map:

    • Running studies that collected required, specific data would result in a faster turnaround with data that was relevant

No Team Member Was Able to Help Me Through the Journey Map and Persona Development Processes

  • No matter how much I communicated my process to my team

  • I did my most productive research work solo

Stakeholder Participation in Workshops Decreased as I Planned More Sessions

  • Engagement in workshops that I moderated started strong

  • Workshops should be few and far between as team members can get burned out on too many