2020 / Enabling better coordination for ad hoc ship refueling

Maritime refueling

The Project

Topic: Ships at sea negotiating unplanned fuel purchases with nearby suppliers
Goal: The team wanted to pursue a solution for this relatively unsupported area.
Strategy: They envisioned building a tool that would cover the whole negotiation process from beginning to end.

Definition

I came on board and talked with the team about their objectives and goals, how they think the activity works, their knowns / unknowns / assumptions, and so on. Part of this involved working with them to diagram their understanding of the current customer journey.

I combined those findings from the team into a list of things that we needed to know and verify in order to fulfill the objectives. That led to a set of initial questions to take to users.

Research

For the problem space in which this project was operating, target users were highly specialized and relatively few in number. We thus had access to only a couple, and only for an hour or so each, so it was not the ideal situation for user research. However, that research was necessary because the team was operating primarily on assumptions.

Nevertheless, I talked with a couple of them (after stressing that this was not a sales pitch) and had them walk me through the actual journey involved in ad hoc fuel negotiations. Because of limited time with them, rather than trying to get a complete overview of the entire journey, I focused on getting a very high-level view of the steps involved, and then dug into areas that showed signs of being particularly challenging or painful. The method was a combination of semi-structured interviews and task analysis.

From the few discussions we had, it became clear that trying to build a tool to cover the whole fuel negotiation task would mean competing with major tools such as Outlook and Excel, and that complexity did not fit with the team's time frame and resources.

The pivot

However, the interviews also highlighted scheduling as a particular part of the negotiation process that caused a lot of hassle and uncertainty, mainly because of back-and-forth communications via multiple types of channels between stakeholders.

I proposed that focusing on supporting that particular activity, rather than the whole process, might be a niche we can exploit.

Though I ended up moving to another project at that time, the team pursued the new direction, and my designs served as the foundation for the product that was eventually released.

Concept Testing

Multi-party remote scheduling is a dynamic activity and hard to demonstrate to through static mockups or PPTs, so I built a visually crude but interactively hi-fi prototype in Axure to demonstrate the concept.

I showed it first to the team, who seemed interested. Then to the users I'd spoken with previously, to get feedback. The prototype was not pretty, but the interactivity it illustrated It was well received.

Challenges, strategies, and lessons

The target users were a specialized lot, and they were wary of sales pitches, making it challenging to find representative people to work with us. Fortunately, we were able to find a few through sales contacts, and we pulled some good information from them.

However, with such a limited sample (even in qualitative terms), decisions based on that information would be a bit riskier than if we could have spoken with a few more — or sent a survey to validate what we learned. Such risk is part of the innovation process, though, and it worked out well in this case.

User access was very limited, making decisions based on user research somewhat risky.