RAIL DASHBOARD
ROLE
Product Designer
User Research, Wireframing, User Persona, Empathy Map, Design Systems
Jan ‘23 - March ‘23
OVERVIEW
Redesigning how procurement team accesses and analyzes their data on inland network routes.
BACKGROUND
The procurement and rail team was utilizing an excel spreadsheet to analyze and access 1000s of rows of different data points. The team wanted to move towards transforming this data into a web app. I was tasked with creating mock-ups of various screens in Figma that would represent the data they needed in an accessible and digestible way.
DESIGN PROCESS
TALKING TO USERS
Based on research and discussion with the procurement team as well as the developer, we decided our users would fall into the following categories:
Procurement team users that utilize the dashboard to select the most cost efficient rail path.
Operations team users that utilize the dashboard to get insight on main trends of rail volume.
MAIN OBJECTIVE
As this was a smaller design project, the focus was more on discussing with the defined users and aligning on what information/data was necessary. Since the excel spreadsheet contains a lot of information, it was also important to synthesize as much as possible. The developer had also done extensive user research, so we discussed in detail so I understood the current pain points.
For questions or specific pieces of the need I was unclear on, I spoke with the user groups for clarification and comprehension.
The excel spreadsheet contained 15 different sheets and my goal was to consolidate these sheets into 3 different screens. This is important for usability of the dashboards as well as time efficiency for users to find what they are looking for.
REDESIGN PROCESS
After defining the most important data sets, I then spoke in depth with the developer of the data excel set to understand what functional requirements should be included in the website application mock-ups.
We decided the app should be broken up into 3 main screens: A main homepage, an input page, and an output page.
From there I discussed more with the two user groups to understand their overall process for looking for rail routes or data that they need. After this, I went through each screen and thought of all the functionalities I could include that would make this process intuitive and also useful.
PAPER SKETCHES
I often use quick paper sketches to help me brainstorm ideas for developing the design. It helps me visualize several different design possibilities and decide which one fits the users needs best.
WIREFRAMING
Here are low fidelity wireframing based on my paper sketches.
ITERATIONS
Unfortunately, this project ended up being paused so I was not able to create any high-fidelity iterations. However, below is the progression of my design into 3 rough screens that were meant to be built off of after gathering additional internal feedback. It gave me good exposure to consolidating large data sets as well as learning more about design systems.
To complete this project I would have thoroughly developed my design system in terms of colors, typography, and branding aligned with the company. I also would have done extensive work to ensure accessibility. That is crucial for this project since it is information heavy. Ensuring fonts and colors allow users to search for the data they need comfortably is always a priority and especially relevant for this project.
CHALLENGES
For this project, the main challenge was the synthesis of data. The algorithm that creates the data set is very complicated and it was difficult at times to differentiate what information was absolutely necessary, what information could be merged, and what information was not necessary. To combat this, it was important for me extensively interview the developers and users to define the information they needed. I also walked them through some of my low-fidelity prototypes, as well as their process when they open the excel sheet. This was to understand how much of their original process aligned with what I included in my first iteration and to see if visually the mock-ups I made improved this process. Communication and detail-oriented process mapping were crucial to overcoming this challenge.
KEY TAKEAWAYS
As previously mentioned, this project ended up being paused. However, the last iterations I gave for the web application mock-ups allowed the development team to have more productive and structured conservations on the project moving forward. Since the data we were working with was very heavy, many times the user interviews the developers were having were unstructured. It was also difficult in the beginning to truly hone in on the necessities of the web app. By having the work I did to document this process as well as inspiration for the web app, when this project is un-paused the progress towards a final product will run much smoother than it did in the beginning. It also allows the original algorithm used to create the data set to improve, which will make the transfer of the data set into the new web app less cumbersome. The relationships I built with the various users as well as the development team were important as well. I now have a clearer idea of their thought process and how they work together. Now, I am able to better prepare to give workshops and guided interviews catered to their needs or similar team structures/functions in the future.