MaiTai - Database Request Feature

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

Project Overview

Role

Product Designer and Researcher

Challenges

  • Interface previously only supported a single user type, and ignored anyone else who fell outside of that ideal user image

  • User workflow was not supported, and dealt with through various conflicting means

  • Leadership was concerned about business value of the new feature set when looking holistically at the impact within the portfolio

Solution

  • Introduce a new user type and create communicating interfaces to facilitate requests

  • Collaborate cross-team with other product teams to form a united workflow

Company

Kessel Run through TDMK Digital

Tools

Figma, LucidSpark, Zoom

Background

I joined MaiTai as the previous designer was rolling off the team. I quickly assumed the primary position of context holder and quickly spun up on information as another product designer also joined the team. We worked closely with 10 developers and a product manager.

MaiTai is the source of truth database application of the Air Force working along side other applications to support the battle management suite. The MaiTai application was already full of most of the basic information necessary by the time I joined the product team.

Debbie - Database Manager

GOAL - Maintain accurate and updated asset information in the database for mission planning purposes

PAIN - Simultaneously manage and coordinate many asset request forms coming from several different sources

A Problem Arises

We had already established our primary users, database managers. We conducted prior research had created a detailed persona, named Debbie, whom most of the workflows in MaiTai had already been catered towards.

It wasn’t until we visited multiple offices in person that we noticed unaccounted users were also using MaiTai to create assets without permission nor the proper knowledge of asset formatting and realized...

MaiTai was not designed for other users at all.

MaiTai was initially built with only database managers in mind. Actions taken by any other user with MaiTai access resulted in a lack of data accuracy as those users did not have proper training to maintain information.

Unaccounted Users

GOAL - ?

PAIN - ?

A Rocky Start

Since MaiTai is a single application within a suite, there was initial push back from leadership about how this feature would provide value not only to MaiTai users, but also to the suite as a whole. Our product team drafted a research plan and through multiple conversations, explained how prioritizing the unaccounted user flow would align both the portfolio needs with immediate MaiTai user needs. With our research plan approved, our work began.

User Interviews

In order to learn about the current offline experience behind submitting asset requests, we set up zoom meetings and spoke with both database managers as well as the additional known requester groups at 5 different office locations. A total of 13 people were interviewed.

Through our these interviews, our main research goals were to:

  • Identify all ways requests were being submitted and any specific request discrepancies

  • Understand the current workflow outside of MaiTai and the types of information requests that are submitted

  • Discover sources of information that can be pulled into the application

Affinity Mapping

From the learnings of the interviews, we took notes of each of the important points in the conversations on virtual sticky notes and color coded by their office’s location. Then, we created groupings to identify our top insights that helped us recognize our user pool’s main pain points.

Digital record doesn’t match real life

They do not have a digital way to track availability of assets to reflect real life nor do they receive updates when assets leave the current area.

Requests come from many sources

Requests were coming in for database managers from 7+ different teams, in 7 different ways, making it difficult for them to manage.

Requester Input Errors

Database managers need to deal with human error, especially when requesters input their own info rather than submitting a formal request.

Adding a Persona

We were already very familiar with the database manager persona we had envisioned using our app. However, during our observations of MaiTai being used at different offices, and from the feedback of mission planning users, we moved forward and created a new user persona to encapsulate the needs of the requester. Additional details about each persona is listed below. Meet Ellen!

Debbie - Database Manager

Contractor. 56. Retired from Air Force enlistment.

GOALS

  • Maintains the database with the most accurate and updated asset information on file

  • Communicates with all requesters to make sure the content in the database meets all the needs for upcoming missions

PAINS

  • Polices the system so only those with proper database permission can edit information

  • Needs to search for existing information in handbook or on the internet before they can complete a form

  • Manages and coordinates many different forms of asset requests all at once

Ellen - Requester

Active Duty Air Force. 28.

PAINS

  • Has not previously used MaiTai to create assets; uses different application for work

  • Needs a reliable way to submit requests when database managers are away from desks

  • Does not always know all required information that is needed about the request that they are submitting

GOALS

  • Submits all needed asset information to MaiTai before missions can be planned

  • Plan missions in advance for the upcoming schedule with asset information in MaiTai

User Actions

Both our users had the goal of preparing the data in MaiTai for future mission planning, and we wanted to support each role’s part while still maintaining database accuracy and integrity. There was overlap in the actions each of our user types wanted to accomplish when it came to viewing information. MaiTai displays the most actions in the side drawer so that is where the majority of differences between the interfaces would lie.

Database Manager Actions

  • Create a new asset

  • Edit an existing asset

  • Delete an existing asset

  • Approve or reject asset requests

  • Contact requester

Overlapping Actions

  • View status of a request

  • View details of a submitted pending asset

  • View details of an existing asset

Requester Actions

  • Request to create a new asset

  • Request to edit an existing asset

  • Request to delete an existing

  • Review reason why an asset was rejected

User Workflows

We mapped out the scenario of the existing workflow of creating an asset and added the new steps for an asset to be requested. There were a lot of new steps, but each step creates more accountability and trust for the users to have in the data stored.

New Mockups and Improvements to Existing UI

We knew the database manager view would primarily stay the same, so we focused our changes on how requesters would view the page.

Existing View - previously what all users would see

New Requester View - Asset Page

Iterate to Improve

We conducted moderated usability tests over Zoom in order to get opinions about the new flow and and while they liked what they saw in our first pass at designs, they recommended various ideas to refine the usage of the new request flow.

After a few iterations we created a new page dedicated entirely to managing requests. All registered user would be able to reference the page regardless of roles to see statuses and details of requests, but only database managers would have permission to take actions.

New Requester Table - Database Manager View

Some pieces of feedback we received had a big impact on the overall workflow even if it only had minimal changes to the MaiTai interface. Interact with the slider below to see our iterations! (Note: slider will not appear in mobile view)

Link requesters to MaiTai

We collaborated with the mission planning app teams to bridge our apps. This increased the traffic into MaiTai and highlighted the flow for requester users

Requester Info Section Changes

Users suggested a dedicated tab for requester info rather than forcing users to scroll down a long side drawer and expressed interest having thesystem save their info since filling it out each time felt too repetitive.

Align UI components and quick actions

We made sure to stay compliant with the suite component library, standardize the language on the page, and added easy actions like copy contact info

The Deliverable! 🎉

Our product team delivered the new request feature workflow in 61 front-end stories over 5 months, in addition to many other unrelated features and backend we were working to deliver at the same time. The request workflow helped us account for a previously neglected workflow, build up our user base, and better ensure data validity within the suite.

Impacted 10 per day submitted through other means during a multi-day exercise

7/9 database managers expressed ease and positive impact of the new workflow

6/6 users completed tasks in prototype without raising concerns for data validity

“I just want to call out how awesome the new request flow just was and how it immediately addressed so many complaints we have gotten over the years”

— Chris Hodge, KRADOS Leadership

Reflections

While my team and both our users groups were happy with the results of our long awaited feature, I still wanted to call to light many of the challenges we faced before reaching our end state, and things we could do better for our following features!

Plan Ahead with Cross-team Collaboration

My team did come together to draft a plan, but we initially left out another product team that could have filled in context for us. Our new users were their current users, and we realized we should have included them in the making of our plan rather than after the fact.

Iterate Fast

Thank you for reading through my case study!

My design pair and I spent a lot more time on the initial design of the request manager before scrapping the idea for the table in the following design iteration. We know next time it is okay to showcase our ideas to our users without having every pixel in place.

  • Backend Service Research

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

    View Case Study →

  • Side Projects

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

    View Additional Work →

  • Pokébase

    Who’s really catching them all? This case study dives into reorganizing user profiles for a regulatory association

    Coming Soon!