MaiTai - Backend Service Research

How to support an application team stand up a backend service with domain context research

Project Overview

Challenges

  • Limitations of our data availability were causing problems for downstream applications due to code restrictions and needed to be technically restructured

  • MaiTai developers wanted assistance scoping the domain MaiTai needed to cover

Solution

  • Identify all pieces of information apps needed to consume

  • Validate assumptions with downstream app teams before developers begin to build the new service

Role

Product Researcher, Context Holder

Tools

LucidSpark, Zoom

Company

Kessel Run through TDMK Digital

Background

As MaiTai grew into a mature product, our developers began noticing more and more limitations. Information that was supposed to be sent to an application was not being sent and expectations for received data were not being met. The developers conducted a spike and determined they needed to build a new backend system for storing our data in a more flexible way, and they needed product design assistance to inform them while doing so.

But I’m a product designer. How can I help the backend?

As the product designer of MaiTai, it is my responsibilty not only to maintain relationships with external users, but also to hold internal domain context surrounding the application as well.

The developers did not want to jump in blind without validating why creating a new backend service was the right choice. I depend on my developers for technical work, and they depend on me to communicate with other teams about how our data ought to be used. In this instance, our focus was improving the workflow of our developer team and working with all the internal downstream application teams receiving information from the MaiTai database, rather than on the external users we normally spoke with.

What information comes from MaiTai?

The purpose of the new services are to provide domain logic and data to the suite, assign assets to a mission, and detect conflicts and incongruities.

MaiTai works at the beginning of the beginning of the suite’s workflow and passes information downstream to the other applications in the mission planning suite.

The main two types of data that are ingested by downstream apps are Assets and Identifiers, each being the focus of a new service.

  • Assets includes jets, ships, their quantities, stationed locations, and any related details

  • Identifiers are things that distinguish specific assets such as codes or callsigns

Internal Team Syncs

We spoke with 6 different internal teams to identify 3 key pieces of information.

  • What information are they already receiving from our backend?

  • What information existing information do they want to receive that is not already being sent?

  • What information does MaiTai not currently have that they want to receive in the future?

For the datapoints listed in red, we began to look for teams outside of the suite in order to bring their dynamic data into MaiTai. Once we found teams that carried that information, we spoke with their product teams and told our developers what information we needed from their applications so they could look into creating endpoints and feed that information to the mission planning applications.

Narrowing Down Scenario Expectations

Before the developers began their work, our team balanced team of designers, developers, and product managers met with the primary Mission Planning app team to check if our assumptions matched their expectations.

Below is one example of a scenario we posed to the Mission Planning team to spark conversation about the system behavior.

Given Asset 01 has the identifier 123 from the timeframe 00:00 to 08:00 and Asset 02 has the identifier 012 from the timeframe 06:00 to 12:00

When Asset 02 wants to change its identifier to 123 for its entire timeframe, but that identifier is currently unavailable at that time

Then what is the expected outcome of the service?

A: System allows Asset 02 to request 123 anyway but flag a warning (least technical complexity)

B: System denies Asset 02 from using 123 because it is already in use (more technical complexity)

C: System denies Asset 02 from using 123, but offers a different available code (most technical complexity)

In this case the mission planning team chose Option C so we informed our developers of the expected behavior.

Service Expectations

After our conversations with the Mission Planning team, we began to outline what our new ideal workflow would be and compare it to how things were currently working. We worked together with our developers to develop a future flow as well as establish some new policies that the future flow would abide by.

Once all our questions were answered, scenarios were mapped and assumptions were validated, we were finally able to hand off our research work to the developer team for them to begin work on the service.

Learnings

As I’ve learned from personal experience, the day-to-day work of a product designer is not only about changing user interfaces. Focusing on the workflow rather than on my direct product team was able to positively impact the capabilities of our entire suite of applications.

I was not expected to know everything about the code, but by having the context behind the backend services, I was able to grow more confident in my context of this complex domain space and better grasp how each application worked together.

Delivery and Impacts 🎉

Our team of 10 developers delivered the new Asset and Identifier services in 262 tickets over the following year, while simultaneously continuing development on front end user facing features as well.

While developer quality of life had vastly improved at the end of their code restructuring, MaiTai users did not immediately notice any large changes to their interface. Much of the work done was to scale future work in the backend and our entire suite celebrated that success!

Still, here were some of the new benefits for our end users✅

New data types shared from MaiTai to users of downstream applications

Improved page loading performance for pages with 500+ assets

New behavior that benefits mission planning application end users

Front end is able to load more info without crashing (10k+ identifiers)

  • MaiTai - Database Request Feature

    A modern way to manage asset requests within the mission planning department of the US Air Force

    View Case Study →

  • Side Projects

    More fun things I do outside of my 9 to 5.

    View Additional Work →

  • Bloc by Block News

    Local Maryland News to Inform, Engage, and Equip

    Coming Soon!