Putting Data Clean Up on the Map
Enterprise Web Application
NOTE: Some details and designs have been removed or changed to protect client confidentiality and proprietary data, but the case study still reflects my process and approach.
Role
Product Design,
UI Design,
UX Research
Duration
Fall - Winter 2022
(3 months)
Deliverables
Feature Requirements, User Flows, User Tested Prototypes, Dev Handoff
Tools
Sketch, Invision, Miro, AG Grid
Where are We and How Did We Get Here?
This feature was part of a larger, brand new application that was based off of a manual process that typically took over a year to complete. The decision was made to automate as much data as possible in order to speed up a lot of this manual process.
This step that would eventually incline this feature usually took users about 9 weeks to complete, and the team wanted to get that down to 4-5 weeks, but that is where the UX concerns started.
55%
Estimated Reduction of Time on Task
$38,500
Estimated Labor Cost Savings Annually
Data automation can give applications a leg up, especially when the focus is on analyzing it’s outcomes. The trouble is when the data isn’t always trustworthy or clean.
Previously, users had become accustomed to manually cross referencing 4 different databases to clean up the data and get it into shape. They had control over the final outcomes without having any need to audit the final results.
Automation made cross referencing the data easier, but took a lot of that control out of the users’ hands. It was up to UX to find a way to highlight unfixed errors and make sure that users could adjust data when the system got it wrong.
Discovering the Problem
I first noticed the potential issue during the Discovery Phase of the project. A GEMBA walkthrough revealed how much users relied on the ability to edit data at will throughout the entire process. Add on top that users were having to check every cell of data and that lead to a lot of double work, human error, and a lack of an audit capability.
NOTE: This is one of those pesky proprietary information sections.
I brought my concerns up to the rest of the team and we realized that we would need a way to give some control back to the users to correct the data errors, but also balance that with the new abilities that will come with automation. But how?
How Might We…
…give users the information they need to make data changes confidently?
…reduce the risk of human errors while still maintaining user control?
…clearly and quickly allow users to identify potential errors?
Users in the Driver’s Seat
The previous observations and HMW questions were based on interviews that I had conducted with our users.
Who is driving this thing?
2
1
Users has completed the process more than once
Total Users
6
Users have completed this step
3
1-on-1 Interviews
Excel Experts…
Users have completed the entire process
If they didn’t check it, they don’t trust it.
Data Distrust…
Who are hesitant to need to learn a new application and process
Operating Margin affected by users annually
~$300 Million…
2 Types of Interviews
I worked through 2 different types of interviews with my users. The goal for me was to better understand their process and to get them to trust me as their advocate as we built this application for them. I did a second round of interviews with the 3 users who had competed this stage in the process to get more in depth on what they were use to and what improvements could be made.
Group Interviews
The focus was on connecting with the entire user base and getting them comfortable working with me.
We walked through an overview of the entire process, which already started to show where the cracks in their training were.
We talked about general pain points felt throughout the process and in every stage of competency that the users and experienced.
They shared work arounds and solutions they had to create to solve existing problems, which gave me insight into features needed and potential pitfalls that might occur in development.
These interviews were conducted with the 3 team members that completed the error correction step in the manual process
Millions of rows of data meant that the data correction process was extremely tedious and time consuming, clocking in at over 9 weeks of manual labor. Going cell by cell was necessary as they never knew what the outcome might be.
Often they would have to reach out to other teams for clarification or advice.
They would spend a great amount of time looking at data that was already clean and ready to use, which equated to the feeling of a lot of time wasted.
With so many cells of data, the likelihood of mistakes was high, often leading to later rework.
It was difficult to remember where they left off at the end of a working session.
They had to rely on learned knowledge to determine if the changes they made were correct, the trouble was that most users hadn’t been on the team long enough to gain that used knowledge and it changed depending on which engine line a person was working on.
Interview Highlights
Ideation Pitstop
My next step was just some rough ideation on possible solutions.
I looked at how other products and services tackled some of these user issues, starting with products in the company already to try and maintain consistency across features. I also researched 3rd party possibilities as well.
NOTE: This is one of those pesky proprietary information sections.
I made lists of possible solutions and how I presumed the flows and screens would adapt to those solutions. Then, it was collaboration time!
Users in the Driver’s Seat
I connected with the dev lead to discuss possible solutions.
He had much better knowledge of the data sources available and how they were being used in other applications across the company. From there we worked out the biggest concern - individually cleaning every cell of data.
Auto-Mation Nation (Building Back End Logic)
Using the same sources used in the manual process, we could do most of the cross-referencing for the users. Weeding out any data that matched on the back end as clean data and only needing user time on data that needed more attention.
I recommended that data only be marked as clean if the system could guarantee through multiple (at least 3) data points that the data was correct. This would remove the bulk of the data clean up from users while still letting them feel in control over the messy parts.
Because we now had those sources of data available, we could use them to make qualify the systems decisions to the users and give them recommendations on how to fix bad data!
Once that major time saver was planned out, it was time to see what the interface could do to make their lives easier.
Finding Direction(s)
Through the research, users made it clear they needed to have access to all the data, to see it and edit it. But with about 500,000 cells of data, weeding through what was good data and bad data would take forever.
500,000
Estimated Data Cells (Or is it…?)
Estimated time spent on this step annually
2,160 Hours
The first thing I needed to do was make sure users could find the data.
I put on my research hat and started looking at other database designs, but none of it was supporting the vast amount of data used in this process, nor was it really helping to guide the user. So, I started looking at other industries and design patterns - enter google maps!