A mobile application for levee inspection across the United States
May 2022 - January 2023
Lead UX Researcher & Designer, UI Designer
US Army Corps of Engineers (USACE)
The U.S. Army Corps of Engineers (USACE) manages more than 1,600 levees across the United States that border the homes of over 13 million people across the country. In order to make sure that each levee is structurally sound and serving its purpose, USACE sends out inspectors to each levee routinely throughout the year. During these routine inspections the USACE engineers survey thousands of elements on the levee, and collect a mountain of data that is then uploaded to the National Levee Database (NLD).
The application they use to collect this levee data is getting outdated, causing a lot of frustration among the engineers that use it on a regular basis. This prompted USACE to put out a bid to redesign the application to make it easier to use and allow USACE engineers to perform inspections more efficiently. That's where I come in!
The United States Army Corps of Engineers (USACE) were looking to update their application for levee inspection to make it more efficient and easier to use.
Redesign the USACE mobile inspection tool to allow users to conduct inspections faster and with less errors.
The first step to designing a great solution is fully understanding the problem you are trying to solve. To do this, I began my work on this project by conducting multiple interviews with the head engineers at USACE to understand their motivations, pain points with the current app, and the most common use cases for their current application.
As someone who did not have an existing background in engineering or levee inspection, this process was also a great way for me to gain an understanding of the communication landscape within the corps as well. Asking questions about the existing communication networks within the corps and how they resolve issues after noting them in the app allowed me to think beyond the current issues they were experiencing and build more functionality into the application to help them solve problems well into the future.
What did I learn about levees?
What did I learn about our users?
After interviewing key members of USACE staff that would makeup our user base, three primary pain points stood out to me as the starting place for improvement:
4 of 5 Users noted that switching between levee features within the application was cumbersome
3 of 5 users had issues with recalling information from previous screens while using the app.
5 of 5 users interviewed preferred to view observations from the map screen rather than lists
Creating personas based on the engineers that I interviewed was an insightful exercise that allowed me to imagine how the background and personalities of our unique user group would impact their objectives and biases while using the software.
One example of a primary consideration that factored into the redesign was the wide range of tech literacy among the user population. USACE engineers are employed across the country, and come from a variety of different backgrounds, so the solution that we create needs to be accessible to several different tech literacy levels.
This concept impacted the final designs in many ways, including labelling icons, using large typeface sizing for easier reading, and intuitive navigation modifications to reduce the time to task completion for most users during testing.
Creating a user journey map helped me understand how the user might progress through the main flows within the application and track their perceived emotional state during each of these steps to highlight certain areas for improvement. The pain points identified in our original interviews heavily factored into the creation of these maps, and further demonstrated how user pain points appear during the use of the software.
Some of the main opportunities for improvement were adding hierarchy and grouping to observations and cleaning up the way they were presented. We also identified some areas in the user flow that did not align well with the inspection process, so we reduced time on task by adding additional affordances for users at certain steps to allow them to enter the appropriate information without having to go back or switch screens within the application.
Once we had correctly defined the problems we were trying to solve, I led several ideation exercises with the design team for this project to generate potential solutions for our problem statements. We worked through crazy 8’s, affinity mapping, “how might we?” statements, and other ideation methodologies to create intuitive and functional designs that met the user requirements defined in our prior research. I then began creating paper sketches of the main parts of the primary user flow. Sketching on paper allowed me to rapidly iterate on designs and make quick adjustments without worrying about making mistakes.
After refining the designs on paper, I presented the concepts to the project manager and development team for feasibility and began working on digital versions of the low-fidelity wireframes in Figma.
After receiving buy-in from the rest of the project team I began creating low-fidelity versions of the main sections of the user flow in Figma. This process was very fast-paced and dynamic as it involved a lot of back and forth between me and the rest of the project team, resulting in a series of iterations on my designs that steadily improved the usability and function of the tool. Getting perspective from our developers early in the design process allowed us to all get on the same page and highlight technical considerations that would impact the designs before showing any wireframes to the client.
After creating a low-fidelity prototype of the application based on the information architecture that I approved with the client, I began the process of validating and testing the design with users. I conducted a usability study with 5 mid-level USACE engineers to see how they might use the application in the field. Participants were selected from a diverse range of ages, ethnicities, and technological skill levels to ensure the results would add to the overall accessibility of the app.
The team also sourced feedback on the designs from presentation meetings with the client. In those calls I walked the head engineers through the application to ensure that our process was as transparent as possible, to get buy in from the client, and to give them an opportunity to request changes on the designs before moving into development. By keeping the client involved and accepting feedback from them at this stage, we ultimately reduced the overall impact on our design to cost (DTC) by limiting the amount of feedback we would receive during the development process. Changing the designs in a Figma file is a lot easier and cost effective than modifying your code base to solve the same problem.
After conducting usability studies and interviews with the client, I used their feedback to refine the original designs. By listening to users and making changes, my designs became more intuitive for our target user groups and more accessible to a wider audience. The main changes that I made to the designs were as follows:
This project has gone through the development process and is now in active use by the US Army Corps of Engineers. Our team has been periodically making improvements to the app based on client requests, and through the first few months of implementation we saw a 10-15% reduction in the time to onboard new engineers compared to the legacy version of the application.
The successes of this project contributed to Trinnex (my employer) winning millions of dollars worth of additional projects with USACE, including an inspection app for Dams that was inspired by this project.
As with my life outside of work, I always try and reflect on my projects to get a sense of how each one helped me grow. In recalling the ups and downs along the process of working on this app, I came away with a few key insights that I'll be building off of as I take on new work in the future:
Consider primary vs. secondary sources during user research
During the initial phases of the design process, I was working with senior USACE engineers to gain context on all use cases and validate design decisions before testing. It wasn’t until we tested with mid-level engineers (who would be using the application) that we were able to uncover the insights that contributed to the usability and intuitive workflows that the tool provides. The difference in information that we received was very insightful and illustrated the point that you can't just talk to the boss about their employee's needs; you'll need to get your info straight from the source if you want to capture your user's pain points correctly.
Building mobile-first (progressive enhancement) reduces stress down the line
Since this application was intended to be used on tablets, there was a lot of discussion for which platform we should create our first set of designs for. Ultimately, I suggested we pursue a progressive enhancement design framework which would allow us to eliminate any potential issues that may occur down the line as we try to scale large components into a smaller screen size. This required a more constrained effort during our initial design & development but saved us time on redesign efforts and maintenance as the project scaled to larger breakpoints and underwent iteration.
Different people use the tool in different ways (and you are not your user)
While testing in the field, I observed that different USACE engineers had different preferences when browsing for information. Out of the 5 people I watched use the application on site, 3 of them found observations by clicking on the map while the other 2 used the 'observations list' section to find the correct observation on a written list by filtering. Not everyone uses the tool in the same way, and certainly not in the way that I would use it by default. Usability testing like this during early development helped highlight some key improvements to the tool late in the process, and ensured a smooth launch process for our client.