Materiel Demand Module
Project Overview
For this project*, our customer asked us to revisit an old module that had failed to launch several times over the previous 7 years and essentially redesign it from scratch.
Collaborating with designers and stakeholders, I led the discovery and research efforts for the project, and used this as an opportunity to establish the company’s first UX research practice.
*Some information has been redacted due to a NDA. You can view more artifacts in the password-protected version here.
Client
United States Army
Duration
4 months
Team
Me (UX Researcher), UX Design Lead, Senior UX Designer, Project Manager, Subject Matter Expert, Business Analyst
Generative, Evaluative & Strategic Research
Problem Statement:
The Army’s [redacted] user needs to submit a request for additional equipping for their unit in an automated way that allows visibility on all current requests. Currently, users throughout the approval chain use different products and formats (on and offline) to record decisions. This makes it difficult for the decision-maker to compare requests across the Army and make informed analyses and decisions, resulting in many hours of extra work.
Main Goals:
To understand who our users are, along with what matters to them (their needs, goals, motivations, and pain points) in regards to submitting equipping requests
To evaluate the existing solution and workflow to uncover gaps between the current and desired state
To evaluate whether or not the Army’s requirements documentation aligns with users’ current behavior and expectations
To. strategically balance design recommendations with the business requirements and the uncovered user needs
Methodology & Procedure
Diving into discovery: Researching the right thing, to research the thing right
First steps:
Gain context of the current problem space
Review existing artifacts
Stakeholder alignment
Methodology
-
After reviewing prior design mockups and the Army's requirements document with my UX Team Lead, I strategized how to get the team to pause, take a step back, and re-evaluate where we were, what we were doing, and why we were doing it.
-
1 x 1 hr
Remote - Microsoft Teams
-
DescriActivities: Stakeholder Interview, Root Cause Analysis, 5 Whys, Proto Personas, Assumption Mapping, Knowledge Board, Prioritization Matrix, Affinity Mapping, Persona
Attendees: Army Subject Matter Expert, Business Analyst/SME, Project Manager, UX Team Lead, Senior UX Designer, UX Researcher (me)
3 x 2 hr sessions (Discovery)
Remote- Microsoft Teams & Miroption text goes here
-
1 participant who is current user (we had a lot of restrictions placed on us to access users due to governmental red tape, below I touch on how we handled this)
3 x ~30min - 1 hr sessions (plus on ongoing conversations)
Remote & in-office
-
Attendees: Army Subject Matter Expert (SME), Business Analyst/SME, Project Manager, UX Team Lead, Senior UX Designer, UX Researcher (me)
2 x 1 hr sessions
Remote- Microsoft Teams & Miro
-
UX Researcher (me) & UX Team Lead
Done in Miro, presented to previously mentioned stakeholders and entire product team (PM, UX, Devs, QA)
My Role
Planning
Lead discovery & exploratory research
Lead synthesis & analysis
Share deliverables
Process & Challenges
Given our company's emergent UX maturity, we had never had the opportunity to establish a proper research process at the beginning of a project, so I saw this as the perfect chance.
I presented my research plan to the project manager and internal stakeholders, explaining why the up front effort will save us time and resources in the long run.
Once I gained their buy-in I invited them to take part in the discovery workshop to help further their understanding of UXR as well as establish alignment on our user and their needs, and to my excitement, they happily joined the efforts.
After starting the discovery workshop, we realized that we needed more information about who our users were, as well as more context surrounding the problem space.
Initial assumptions
What we heard stakeholders say mattered to our users
At this point, we were assuming the user’s needs to be:
Speed of application use: task completion
Ability to collaborate
Ability to quickly check status and as a manager
Remove any bottlenecks in the request pipeline
From our workshop activities, we developed our discovery research questions and our discovery research goal.
Discovery research questions
Who are the users that interact with this product?
How are they currently completing their equipping requests?
What are the biggest issues users face while trying to make requests?
Discovery research goal
Decide how we can assist the [redacted] user in efficiently making informed decisions and analyses in the Materiel Demand Module's [redacted] request feature.
If interested, click through to read what we did in the discovery workshop, why we did it, and how it moved us forward.
Lack of access to our users
Once we arrived at the stage of needing to speak with our users, we discovered that the Army was not going allow the UX team to be in direct contact with them.
Getting creative: using resources we did have available
Our Army SME and Business Analyst had direct contact with one of our users in their office. So, after prepping them, we had them conduct the user interviews, observe the current solution state, and report their findings to us in a workshop in Miro over Microsoft Teams.
In addition to this, our SME had previously worked in the position of and alongside our target user(s). Therefore, while not ideal, we had to defer to his experience for some of our assumptions. We hoped to more properly address these assumptions once our first iteration was released.
“We do everything in Excel, PowerPoint, Word, and Outlook. It's difficult to tell if any progress is being made without making a lot of phone calls.”
— Army Major
Initial findings & insights
The findings and insights up to this point started to tell a story of an experienced and highly motivated user who was spending a lot of extra time making sure they had the right information to submit and track their requests.
Who are the users that interact with this product?
How are they currently completing their equipping requests?
What are the biggest issues users face while trying to make requests?
These started to shape our Persona.
Persona and more detailed insights can be viewed in password-protected version of case study.
In this initial discovery research we also learned that there are multiple request type flows. We then had to learn what each meant, which one(s) we needed to prioritize for this iteration, and if there were any additional users involved.
Together through further conversations with our user and the Army stakeholders, we decided which request type to prioritize for this product iteration and started to come up with questions as to how we might address the themes uncovered in our findings.
How might we create a standardized request submission process?
How might we save users time when creating a request?
How might we allow users to feel confident in the request data they are viewing?
How might we provide a way for the user to search for a specific item in documents that are often complex?
Updated goals:
Understand the user's [redacted] request process workflow
Understand and align on how many actors are involved in the side work and decision-making throughout the request processes.
Through our weekly stakeholder-UX meetings we were able to:
Regularly align on goals, user needs, and business needs
Confirm priorities
Discuss feature request feasibility
This allowed us to do the following:
*Map is viewable in password-protected case study
Have additional proto personas made of the other people/entities involved in the request flow to help us gain context around complexities in the user's work
Our SME happily took this task on himself and it was another great example of the desire to be involved and stakeholder buy-in
Map the request process and various actors involved in it
*Viewable in password-protected case study
With the insights from these activities we developed more questions to frame our ideation
How might we allow our users to seamlessly pick up where they left off in a working document?
How might we show a requests status when it arrives at in "offline" stage in the process?
How might we provide users an easy and accurate request tracking experience?
Results & Deliverables
Once we had these 2 artifacts, we were able to combine the insights from both to map out our user story.
Then, I worked with our designers to ideate solutions to try and address our "how might we?" questions.
*Mockup viewable in password-protected case study
*User story map viewable in password-protected case study
After designers came up with initial mockups, I inserted screenshots of them into our user story.
This way I was able to give more contextual information to the Project Manager and internal stakeholders as to how we saw the steps and interactions looking.
Share out
Once we validated these mockups with stakeholders, I gave a presentation to the product team showing and explaining the persona, proto personas, process map, and user story map artifacts.
In collaboration with the Project Manager, I added links to relevant JIRA tickets to the user story map for the QA and Development team.
These artifacts were all put into a Miro board that I shared with the team so that they could reference them at any time while working, or in our meetings.
*Artifacts viewable in password-protected case study
Impact
“You unclogged bottlenecks [with stakeholders] that had prevented the forward movement of the project for almost 7 years.”
— UX Team Lead
I was able to add visible value to the team by:
Next steps:
Once our designs were in the world with users, we planned to work with the PM and QA team to organize a usability test.
If you’ve made it this far and still feel like reading (yikes, but thank you), here’s my reflection:
None of this would have been possible without the support of my UX Team Lead. It was because of his support and belief in me that I was even allowed the opportunity to spearhead this entire discovery and research endeavor. This project felt like jumping off the deep end and hitting the ground running all at once, and I had no choice but to grow quickly as a UX Researcher. In my back pocket I had what I had learned in school and my previous internship but this was finally the reality of industry and “research can be messy”. While it was incredibly frustrating to not be able to access users directly, it was an excellent exercise in being scrappy and strategic. I constantly reminded myself that trying to do what we can, as best we can, is better than no research at all.
Something I am quite proud of as a young UX Researcher is that I introduced and led design strategy conversations and created and executed a research plan, which our team had never done. Not only had they not done this within the context of this project, but never at all in our company. This gave me more confidence to continue speaking up and applying pressure to continuously learn more about our users and uncover insights to implement their actual needs into our designs as well as identify new business opportunities. From this project I gained incredibly valuable experience working with stakeholders by introducing them to user research, gaining their buy in, and then working alongside them throughout the discovery process. I am truly grateful to them for their openness to try something new and trust me to lead the way.