Data Visualization and Accessibility

Shelene Lee
7 min readMar 17, 2021

--

Micro Case Study, ICS, UX Design Portfolio by Shelene Lee

Project Overview

The Client

ICS Business Partner who reports to worldwide area stakeholders of the Church of Jesus Christ of Latter-day Saints.

The Problem

The business partner created monthly reports in excel with data he had to collect from a developer that was stored in a database. He needed a solution that would enable him to create and customize reports without having to go through a developer to get the data he needed.

Team

  • Principle UX/UI Designer: Shelene Lee
  • Project Manager: David Monk
  • Developers: Max Cloward, Jeff Hiatt, Drew Shirts
  • QA’s: Michael Cowley, Scott Turton

My Responsibilities

  • User Research
  • Wireframes
  • Prototyping
  • Collaborating with cross-functional team
  • Quality Assurance

Tools

  • Figma

Results

  • Creation of reporting dashboard overview
  • Improved chart and graph views, UI, area selection, and tables
  • Simplified and improved reporting, fewer categories needed
  • Replace the need to create individual excel reports, and do it in a time efficient manner.

Original Concept

The business partner shared with me a sample of the excel reports that he created each month. Along with tables of data, he also created charts that he used to visually compare the stats of different areas. He was creating these reports because the original online dashboard was difficult to use and even though the system contained the data that the business partner needed in the database, the interface did not provide a way for users to access the data or configure reports.

*Image contains redacted information for privacy.
*Original dashboard with redacted information for privacy.

Research

Stakeholder Interviews

I met with the business partner to determine the business requirements, goals for the project, and problems to solve. We discussed the type of reporting he was looking for, the frequency he needed to use the reporting tool, the information that he needed to be included in the report, etc. With each iteration, I would meet with the business partner for design reviews, ask clarifying questions, and confirm that designs met/exceeded his needs and desires for the reporting tool.

Key Findings from Stakeholder Interviews include:

  • He was currently contacting the developers each month to gather data for the report.
  • He used that data each month to create spreadsheets and charts in Excel that contained charts and 28 individual spreadsheets.

Literature Reviews

For this project I researched chart types and accessibility to understand the best type of chart to use for the data as well as which colors in our design system to use in combination to meet accessibility standards.

Chart Types:

  • Pie- Takes more space than other types of charts and they are not ideal for accurately comparing multiple pie charts because it is harder to distinguish size/area of a pie chart and distance of a curve vs. a straight length.
  • Grouped Bar- Could be used to show grouped data categories on the same axis, but since bar length represents numerical comparisons it would not be as good to allow for percentage comparisons.
  • Stacked Bar- Shows how a larger category is divided into smaller categories, each part combined to create the total amount. Each main category would be different lengths and therefore very difficult to compare individual smaller categories.
  • Normalized Stacked Bar- Shows how a larger category is divided into smaller categories, and each part is a percentage of the main category as a whole. “This makes it easier to see the relative differences between quantities in each group.”

(https://datavizcatalogue.com/search/comparisons.html)

Accessibility:

  • Color Blindness
  • Printing in black and white
  • Contrast
  • Font Size

Because of the Literature review these are the points we needed to address in the design:

  • Both numbers and percentages are important when comparing areas.
  • The charts need to meet WCAG accessibility standards.
  • The reports may be printed out in black and white so color values and contrast are important.
  • All designs need to meet our design system standards and use company colors.
  • Customizing reports needs to be intuitive and efficient.

Ideation

Accessibility

My first step in ideation was to create a mockup of all the colors in our design system and apply a color blindness filter to see which color combinations worked well together. Then I took those same color combinations and added a grayscale filter so I could see color values and contrast when printed in black and white. The final combination had to pass both colorblindness and grayscale tests. The business partner was used to using green, red, and yellow to represent the categories in his reports, but after showing him results from the color research, I proposed a dark blue, light blue, yellow combination of colors.

Design System Colors
Color Blind Filter Applied
Grayscale Filter Applied

Chart Types

The next step in ideation was to try a couple different chart types which helped in the decision to use a normalized stacked bar chart so that category percentages could be easily compared.

Figma Mockups, Prototype and Testing

It was important to create a dashboard that was well organized and presented pertinent information in an intuitive format. I wanted to be sure to incorporate good design techniques in the prototype such as contrast, repetition, alignment, proximity, etc. I created the mockups and prototype in Figma, paying close attention to content, structure, hierarchy, and functionality. I was able to use this prototype to test with the business partner. In testing the prototype we were able to pinpoint use cases with the data we had not previously considered, so I had to further ideate on how to display the numbers in the chart if any of the sub categories were at zero. We also moved the form input controls below the tabs so each tab could have separate controls to facilitate setting different report criteria. The user is able to select any of the areas, or all areas from a dropdown list to create the chart and table with the desired data.

After final design reviews with both the development team and the business partner, the dev team began coding the dashboard reporting chart. I worked closely with the front end developer, helped with CSS issues, and assisted the QA’s to ensure the quality of the end product.

*Image contains redacted information for privacy reasons.
*Image contains redacted information for privacy reasons.
Figma Prototype

Lessons Learned

I worked closely with the developer and the QA on this project to make sure the end product met our design system requirements, as well as solving a couple UX issues when coding the charts. The following are examples of some things that we worked through:

  • What happens when a main category has a sub category with a very small number/percent or a zero? We had to establish some rules for a minimum size color bar to be able to display a number inside the bar. We also determined that since the charts might be printed we needed to represent a zero sub category on the chart by showing the “zeros’.
  • I specified a max width for the chart because it was difficult to read at a wide screen width.
  • There was a third tab that the business partner and Product Manager decided was not needed anymore since they could now more clearly see the data for each individual area as well as the areas compared to each other.
  • To help the user quickly identify the percentage of each sub category, we developed a hover tooltip with the amount and percentage details for each sub category and corresponding color so the user can quickly see the data.
*Image contains redacted information for privacy reasons.

Outcomes

  • Creation of reporting dashboard overview
  • Improved chart and graph views, UI, area selection, and tables
  • Simplified and improved reporting, fewer categories needed
  • Replaced the need to create individual excel reports, and do it in a time efficient manner
  • Ability to allow more users to create and download their own reports
  • Designed a process that saves 8 hours of work per month, 96 hours of developer and PM time per year, freeing them up to work on other projects.

Works Cited

“Comparisons.” Comparisons: The Data Visualisation Catalogue, The Data Visualisation Catalogue, datavizcatalogue.com/search/comparisons.html.

--

--

No responses yet