Where Information Hierarchy and Data Visualization meet.
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.
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.
I was the lead researcher and designer on this accelerated project.
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.
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.
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.
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.
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.
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 design must be compliant with the Redline Design System , leveraging existing React components.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.