High Risk Queue

Where Information Hierarchy and Data Visualization meet.

The Challenge

A High Risk Analyst looks at current and historical data to determine if dealers are demonstrating signs of risky behavior. If a dealer is showing signs of suspicious behavior, the company can mitigate its losses and terminate the relationship.

With the help of one very knowledgable staff member, the High Risk Analysts built themselves an Access Database to visualize this data. The database was not implemented or supported by Technology, and was reliant on one person to maintain it. The company was also moving from WebFOCUS to SSRS reporting. A new application solved many issues.

The Database Built by Users
The Information Architecture of the Access Database included five tabs.

Pre-Kickoff Insights

June 26, 2018 I was approached by a Product Delivery Manager (PDM) and told I was being added as a blocker to an epic… the Dev Team requested a design. Work on the epic was scheduled to begin in the following sprint. The PDM scheduled a design review meeting for Monday, July 2nd.

Role

I was the lead researcher and designer on this accelerated project.

keyboard_arrow_up

Discovery Phase

Hypothesis

By applying the Design System and it’s best practices to the Access Database, we can quickly move this department into a new solution… even with an accelerated timeline.

Defining the Problem

The good news… I knew who my users were and had a Design System to handle most of the components and styling. This left the workflow and existing data fields to learn.

This is where working with internal users is extremely beneficial. I was able to walk over to the High Risk Analysts, introduce myself, and observe their workflows and tools. After I understood the role and responsibility of the High Risk Analysts, I asked for a few screenshots of the Access Database and got to work.

Access Database Fields
I broke down the data points on each tab and created a heatmap.

Pain Points Revealed

My first steps were to document the data on each tab (see image above). I found a lot of duplicate information across the tabs… which I highlighted in yellow… data displayed more than twice I highlighted in orange. Data duplication shows a lack of information hierarchy… common for a tool built by users.

Using this frequency as a guide, I created a new hierarchy (shown below). With an understanding of the data, the next thing I needed to solve was how to display the data within the Design System.

The New Information Hierarcy
I created a new information hierarchy based on the number of times (and how) a field was displayed.

Reframing the Problem

I created a Trello board to more easily move the data around the screen. Using existing components, I organized the data points on how/where the data would be presented on the UI.

Using Trello to orgaize the Data
Mapping the data to existing components and patterns.

Ideation Phase

Sketches

As a result of the shortened timeline, I did not allot myself time for experimentation. I sketched out a few layouts on paper before moving into Sketch.

Sketching Ideas on Paper
An early sketch mirrored the Access layout.

Wireframes

My first ideas were designed in a lower fidelity. I found I was spending too much time converting high fidelity componenets into low fidelity, so I pivoted.

The first rough idea in Sketch
I started designing in low fidelity before deciding high fidelity was quicker.

Design Phase

Parameters

The design must be compliant with the Redline Design System , leveraging existing React components.

Proposed Solution

With a better understanding of the data and the analysts’ decision-making process, I began designing an interface to replace the existing tool. For a dealership to hit this queue, it either has a high risk score (ARS) or a large Offsite percentage. Analysts must look at the data and decide whether to create an incident… continue to monitor the situation… or do nothing.

For my inital design, I proposed a hero (or jumbotron) component that displayed data specifically about the dealership. This data would help frame the information below. Knowing that every dealership would be unique, I proposed an “F” Pattern-friendly layout that quickly called out areas of concern. ARS and Offsite graphs stacked on the left, the other frequently used data points were given next priority, and finally the tabs were for digging deeper into trouble areas. Analysts would write comments and their reviews in a section anchored to the bottom.

My Original Design
My initial mock-up for the High Risk Queue.

Once I was happy with the layout, I approached the manager of the High Risk Analysts to validate the idea. She pointed to the color-metric bars and said “I could make 80% of my decisions with this section right here.” We discussed a few minor revisions and left the meeting feeling really positive.

A New Component

While I was happy with the design and direction, I knew the Design System was missing a component for the color-metric bar. I opened CodePen and built the missing component.

The CodePen version of the missing Component
This component would need to be built and added to the Design System.

A Few Curveballs

I demoed the design in the July 2nd review. The PDM asked me about a few wish list items which I was unaware of. Two attachments were missing from the epic. The next two days I revised the design to accommodate these requests. I was out of the office July 4–6th.

July 10, 2018 a Software Engineer modified my solution, stating it was a better layout for the data. He believed ARS and Offsite belong centered at the top of the page (since they are the most important pieces of data).

I tried, but failed, to properly demonstrate why the ARS and Offsite scores need the context provided by the hero. In the end, I was able to sell the users on my solution, but I failed to get the Dev Team’s buy-in. It was a tough pill to swallow, but my role is in support of Technology… and if Technology decides to go in a different direction, I must support that too. As far as I could tell, my engagement with this project was complete.

Validation Phase

The Users Speak Up

August 15, 2018 the High Risk Analysts invite me to a meeting along with the PDM and Software Engineer to discuss their new application. I attend the meeting to record their feedback and listen to their concerns. It was my first time seeing the deployed solution.

The first iteration of deployed code
The solution that was presented to the team.

September 13, 2018 I receive an email from the manager of the High Risk Analysts. It contains a brand new concept, designed by one of the users. This new concept has several similiarities to my original design, so the manager asks me to share my original design with the team. ”Your design gave me butterflies. I want to see if the team reacts the same way.” I inform the PDM of the situation and ask how I should proceed.

A user-submitted design
User-proposed solution… with enough similarities to mine to spark a conversation.

A New, Old Direction

The conversation with the team went exceptionally well. We discussed the pros and cons of all three designs. As a group, it was decided I would update my original designs… incorporating things learned, new ideas, and the team’s feedback.

Re-Design Phase

A New Hierarchy

The biggest update to the requirements, was the need to display all vehicles on floor plan… not a subset. This additional data replaced the need for the metric bars and the majority of the data in the hero. I conducted a card sorting exercise to re-prioritize the data and better understand their decision-making process.

Card Sorting Exercise
Trying to better understand how Analysts drill down to the info they need.

Updating the Solution

I revised the data within the hero component and removed the metric bars to make room for the additional vehicles. One other major update included a vertical icon-based tab layout.

A new Solution
The second iteration or the High Risk Queue.

Validation Phase

User Testing a Prototype

I converted my Sketch file into a clickable prototype by syncing it with InVision. I sat individually with the manager and three analysts. I asked them to Escalate or Pass a dealer using historically accurate data. We found a few very minor issues and talked through some edge cases.

Validating the Layout with Users
Validating the design with users.

Story Writing and Grooming

I worked with Product, Technology, and the High Risk Analysts to write user stories around the updated prototype. I created a Data Mapping document to ensure no data was missed.

Takeaways…

Things I Learned