UX Design Strategy

Defining and executing a product strategy for modernizing a legacy application

User Journeys, Style Guides, Information Architecture, Implementation Strategy, Lean/Agile

 

Old Layouts (left) The old visualizations did not follow any guidelines or pricnciples. They were difficult to understand and use.
Re-design (right) I created and enforced new design principles and best practices that made the visualizations easier to understand and use

 

The Challenge

The safety analytics team has hundreds of charts, visualizations, and reports dedicated to analyzing and enforcing global car safety standards. The critical information was splintered across several departments, there was no established practice for creating these visualizations and reports. As a result

  • Executives and managers were finding it difficult to find the right charts, and reports as they were all located in different sites, under different divisions.

  • The inconsistent reporting practices meant that the users were finding it difficult to digest the information

  • The challenge was to further organize the various charts and reports, and bring a level of consistency to the product.

 

My Role

  • Understand and define the scope of the project and how UX could help with the issues

  • Research users, tasks, and workflows and deliver a plan that prioritizes user needs

  • Create and enforce Style Guides and Pattern Libraries to standardize how the reports were being delivered.

  • Design a landing page that allows all the users to access the information with ease.

  • Usability testing and iteration

  • Implementation strategy

 
 

The Approach

The sheer size of the product meant that a complete overall of the designs was not feasible. I had to come up with a design strategy that would

  • Update all the visualizations with minimum disruption for the users.

  • Inform the stakeholders (on user needs and pain points) so that they can make decisions on which technologies to invest in.

  • Allow developers more time to transition from older technologies, and set up a new infrastructure.

I broke down the redesign into three distinct phases and staggered them so that the team would get more time to address the more complex issues.

 

Phase 1: Standardize

Users found the visualizations difficult to understand and use. Most of these issues were being cause because of lack of consistency; there were too many visualizations using many different patterns. Each chart was different and the users had to learn how to interpret them individually. This was too taxing and frustrating for the users.

 

 

Having a fixed deadline meant I had to improve the visualizations without drastically changing the back end. Essentially, I had to improve the visualizations under these constraints:  

  • remove unnecessary information,

  • re-position elements,

  • change colors,

  • improve the visual hierarchy.

  • I was not allowed to add anything new.

Old Layout Issues (left) The old visualizations did not follow any guidelines or pricnciples. They were difficult to understand and use.
Re-design (right) without changing the backend, I was able to improve the visualizations by position elements correctly and removing unnecessary noise.

 

The improved visualizations were received positively both by the users and the developers. The users found the new charts easy to understand and use. The developers did not have to make drastic changes.

As a result of the improved visualization, the updates needed to be scaled to all the remaining charts. To be able to do this, I created a style guide, and a pattern library to standardize how to make the visualizations. I worked closely with the developers to create templates within their preferred tools so that the transition was even smoother.

Standardized Charts(above) The improved charts were cleaner, and easier to read and use.
Style Guide(right) A style guide I created to help bring consistency throughout the entire application

 

Phase 2: Organize (Ongoing)

One of the key issues we identified was that users were finding it difficult to find the visualizations. This occurred due to poor information architecture, and lack of organization. The navigation failed to capture the user's process, it haphazardly arranged the different visualizations without realizing that there was a logical order to the visualizations. Through several sessions of user research and iteration, I was able to define the navigational architecture for the product.

Site Map (top) I created this site map (based on user resarch) to figure out how to organize all the information.
Old Navigation (left The old navigation had several hierarchy issues and missing links. It made it difficult for users to find the right visualizations
New Navigation (right) The new navigation re-organizes the information to match the user mental model, remove unnecessary links, and improve information hiearchy

 

Phase 3: Consolidate (ongoing)

With all the visualizations scattered across various different divisions, it became difficult for users to find the right information. The lack of visibility led to several different challenges

  • Brand new users need context behind all the visualizations to properly identify which visualizations they need

  • Returning users may need a quick refresher on what has changed, and where they are supposed to go

 

  • Users need to be aware of the different visualizations and reports that are available (not just the ones they use regularly). Cross divisional knowledge can be very useful for them

The idea behind this phase is to help users become more self-reliant and aware of the different reports that are available. This phase needed the most effort (gathering all the visualizations, new server) and as a result we focused on this after everything else was done.

Final with Callouts.png

New Layout The new proposed website re-organizes the information into digestible pieces. It provides contextual information the older website did not have

 

The Process

The team (Product Managers, Users, Developers, and Stakeholders) differed on what the issues plaguing the product were, and were having a hard time selecting an area to focus on. On top of that, they were unfamiliar with the UX process and were not particularly sure on how UX could help solve their issues.

 
 

Understanding the problem space

To help the team identify an area of focus, I created user journey diagrams to better capture the issues within the product, how they were impacting the business, and the opportunities we could address. I based these of the user research I had done (Contextual Inquiry, Interviews, Usability Testing). This helped bring the team on the same page

 

The team was able to agree that the issues  within the product could be lumped into three categories:

  • Consistency (or lack there off): The overwhelming diversity in charts and visualization practices made it very difficult for users to understand the data

  • Hierarchy: The information was not laid out correctly. This meant the users were focusing on the wrong areas thereby misinterpreting the charts.

  • Visibility: While the charts and reports were there to help inform the users, because of lack of organization the vast majority of users were unaware that the charts existed to begin with.

 

Exploring Solutions

To identify the constraints and scope of the project, I quickly started to sketch out ideas on how we could potentially tackle each problem (consistency, hierarchy, & visibility). It was important to explore broad stroke solutions at this stage to:

  • identify resources that would be required to solve the issues

  • start a conversation with regards to feasibility of solutions

  • offer the team multiple solutions

Through this phase I was able to breakdown the issues further and prioritize the issues based on the impact they would have. 

Solution Exploration I used rough solutions (like this image) to understand what resources it would require to implement and the potential impact it would have on its users

 

Plan

Once I had a through understanding of the constraints and the priorities, I collaborated with the team (users, managers, developers) to formulate a plan of action. We used this plan as a guide to move forward. 

It helped us set roles, expectations, deliverables and deadlines for each of the phases.

 

Design Sprint Plan A plan I created to help move forward with all the different phases. This helped the team stay on the same page and use it as a guideline.