| Client | US Navy |
| Problem | The current 12 year old financial and project management application suite is trying to be a one-size-fits all solution with massive amounts of data. Between the old tech stack and poor information architecture, the users struggle with slow pages and are forced to dig and piece together bits of data from various sources. |
| Solution | Update the existing enterprise web application to improve customization, provide richer data views, simplify navigational flows, and reduce workloads while maintaining functional equivalence and supporting immediate feature requests. |
| Outcome | Continued DoD contract renewals, top-mark CPARS scores, and enthralled users that can get more done in a day with an improved quality of life and fewer roadblocks |
CTA is contracted with the US Navy to provide a suite of financial and project management applications. Our job is to help several naval departments gather, store, and analyze data so that they can efficiently produce some of our military's most innovative technologies. Hundreds of users interact with the application suite every day, each contributing their specialty to a multi-layered and complex PPBE process. Dozens of data types stream into the department from multiple external sources and are ultimately stored in our application as a record-of-truth, taking the users out of the dark ages of unreliable Excel documents into a streamlined age of data entry and analysis with a kaleidascope of data visualizations.
Disclaimer: the details and data of this application are protected under NDA and government security guidelines. I will do my best to extrapolate on the core UX principles and processes with the little information I feel comfortable sharing. Most of the images and scenarios below are not representative of the final product.
For more public information about this project, visit CTA's website.
I've been a part of this project for almost 10 years. It was my first salaried industry job after college and I've never left. The work is exciting, the team is amazing, and the pride in being able to service our nation is hard to beat. This project has been 100% remote work since I was hired, way before "remote work" was trendy.
You can read more details in my Resume, but to summarize, I was hired on to this project as a Software Tester / Quality Assurance Analyst. I was a guinea pig Tester as the team was just starting to grow rapidly and had no need for a Test team prior to my arrival. I walked in to an application riddled with bugs, usability issues, and performance problems. I cut my teeth developing the application's first-ever automated test cases, documenting issues, and learning the domain.
From those first days, I couldn't wait to get my hands onto the code and make a lasting impact on the user's experience with the application. Long before I knew UX was a career path, I was under the impression that if you wanted to make software better, you best know how to write some code. I was well versed in C# from my college years building XNA and Windows based games. How hard could this .NET stuff really be?
I convinced my boss to transfer me to the Development team. Using waterfall methodology, we gathered user feedback (Change Request documents) and injected new code to make the application work with what they wanted. Little to no formal design effort took place, excepting the technical specifications we received. Our team provided value to the client by giving them exactly what they wanted (not the same as what they needed) for several years.
In 2016 we hired on a Solution Architect (Chuck Boudreau) that had a strong appreciation for UX, Information Architecture, Agile, and culture change. He "recruited" myself and a co-worker (Patrick Shechet) to start a Design function in the company. I took classes, read books, and soaked in lesson after lesson from my new supervisor and mentor. THIS is how I could finally make the difference I have been yearning for. I was hooked.
I officially became a founding member of the newly formulated "Design Team". Patrick was transferred to aid in SQL development, and I became the only member of that team under Chuck's direction.
It's too difficult to try and cram years of feature enhancements and upgrades into a single case study. Each client feature request probably deserves its own evaluation. This study will focus on a trivial but meaningful feature enhancement our team embarked on a few years ago. The specific data objects and their purpose in the application have been omitted and generalized. It should also be noted that we are currently in the process of migrating to a new UI, images shown here do not reflect the current visual direction of the application.
During a rare in-person product planning session with the users, there was a small irksome workflow they brought to our attention. The applications primary reports are only accessible through a single point of entry. The Report Center is a page off of the main menu that hosts a list of hundreds of different variations of graphs and charts showing different perspectives on the clients data. If the user wanted to access a report for a particular data object, they would have to leave the work they were doing, navigate to the Report Center, find the report they wanted, tell the application about what data object they want to report on (even though they were literally just working on it), and then "run the report" which navigates to yet another page showing the charted view. In a tech stack that relies heavily on postbacks (page refreshes that allow the system to gather/store data), this was an untenable solution. Each postback on a slow network forces the client to stare at a loading screen for 30+ seconds, causing hours of lost work time over the course of the week.
As a user who frequently toggles between data entry and data visualization, I find it frustrating that in order to view my report I have to navigate away from my work and re-enter the data prompts. It's like the system has amnesia.
As a user, I am annoyed at the amount of time I waste while trying to view a report. There are too many loading screens.
The ideal solution would allow the users to access these particular data reports directly from the primary workflow and would minimize postbacks to save the users time when completing this objective.
The scope of this request will impact the report(s) and the forms and lists where the user is primarily working with this data object.
The path to completion for the users objective in this scenario is easy to exercise in the application. It quickly becomes apparent how long it's taking the users to accomplish this task, and how much work has to get paused to do so.
I start the Conceptual Architecture process by opening a new document to capture ideas and screenshots. There's obvious answers and more complex ones, each varying in the amount of time they would take to code/test, but the simplest answer is usually the best one.
Here's a quick summary of the solution options:
A couple low fidelity mockups were rendered using Balsamiq to show the Product Owner the choices visually. After strategically choosing some options what we had time for, and what made the most sense from a UX perspective, we move on to the next phase.
In this case, the mockups were generated during Conceptual Architecture. There was no need to provide high-fidelity mockups or prototypes as the concepts and code components were already well understood, and would be described textually in Solution Specification.
If the feature request requires interaction with another team (like the Database Architects) this is the time that I set up and facilitate meetings to ensure everyone is on the same page and to make inquiries where needed. In another new document, I take the mockups, and the chosen solutions to translate them into something actionable for the developers. Though I won't post a picture of it, the document resembles a cooking recipe. It summarizes all the technical specifications, all the design decisions, and all the documentation we have gathered for the feature request. Then it tells developers exactly what to build on exactly what page with exactly what data API. All issues and questions are addressed as quickly as possible.
This document can take on several iterations as product direction changes come in. In the case of our example, there was only one version.
Where can we put a navigation link to reduce the greatest number of postbacks?
Where can we put a navigation link so that it's not buried too deeply down into the sitemap for the users to actually get value from it?
Answer: On the list where they frequently visit and can access reports from a single or multi-item context.
For multi-item reports, how can we get the user to the report perspective they want with the fewest number of questions?
Answer: Add a single dropdown control in front of the button This doesn't require a new form, and it only burdens the user with one question as opposed to several in the previous workflow.
For single-item reports, how can we get the user to the report perspective they want with the fewest number of questions?
Answer: Since there is no screen real estate for a dropdown input, we'll have to ask the user for this information in a quick modal form. It only adds one more click, and doesn't add any postbacks if engineered properly.
This small feature received tons of praise from the end-users. We received multiple feedback emails about their excitement with this small change. Most of our feature enhancements allow the users to meet a unique business need, but this one was a quality of life improvement that was much needed. It's cases like this that persuaded them to allow our team the time and resources needed to push forward with our backlog of other UX issues and ultimately the complete overhaul modernization effort that we are still tackling today.
Note: We do not have any statistical analytics tools built into our application to track heat-mapping, usage, performance, etc. Due to security protocols, our success metrics are forced to be a bit more abstract. Our user base is extraordinarily busy and post-release user testing is also not an option, so if we receive direct feedback from them, that helps us gauge success.
From this example, I learned that even small and seemingly simple changes can have monumental impacts on the user's relationship with the app. One dropdown and a button lifted a huge weight off their chests which improved their opinions and perceptions of the app.
Additionally, it is extremely important to always be listening to the users. This feature enhancement came from a meeting that about a totally unrelated subject matter, and we captured a valuable opportunity to improve our app because we paid attention to a user's thought that they accidentally said out loud.
Congrats! You must have a lot of time on your hands. Feel free to check out some more of my projects.
Next Project Previous ProjectNate Marrs
(719) 505-3781
© Nathan Marrs 2021. All rights reserved