The summer of 2019, I worked as a software development intern at Aeris communications in Chicago. Although going into the summer my main task was to pick up the React framework and help with front-end development, this soon shifted upon seeing what Aeris’s AerTrak platform dashboard looked like.
Now, before I do the critique, I should explain what AerTrak does. It is a platform in the Internet of Things (IoT) space, usually meant for fleet managers. Think a Taxi company that has a lot of vehicles they need to track. These fleet managers will need to know information on emergency alerts, driver performance, and other Key Performance Indicators (KPIs).
Below, you can see the original AerTrak dashboard.
The original dashboard isn’t great but also isn’t horrible. Here were my original thoughts:
- Very simple UI, no way for the users to be confused with what the dashboard accomplishes.
- The modules within the dashboard aren’t intuitive to use. You have to hover to see the data points.
- You are restricted in the time frame you want to see, either the past 3 days or the past 3 months.
- There isn’t a lot of flexibility for customization.
So upon seeing this dashboard, I asked our UI/UX team whether or not they were working on a redesign. They responded with this screenshot.
Now at first glance, I wasn’t too impressed with the user interface, but upon further inspection, I think this redesign made up with improving the user experience.
- There is more data and functionality on the page. This fits the needs of more users.
- I think the insights tab is an interesting addition, and if well executed could be extremely useful.
- Here there are both operational and analytical data, unlike the previous iteration. This helps users have a centralized location where they can either address urgent matters with their vehicles or check the trends over time in the same place.
- There is more data and functionality on the page. It almost feels too cluttered now.
- In order for the insights tab to be executed well, we would need to put in a non-insignificant amount of time into developing it on the back end. For the purposes of a meaningful, actionable redesign, I think it was out of the scope of what’s feasible if we wanted to roll it out ASAP.
- It was unclear whether this was a medium-fidelity or high-fidelity mockup, but the elements on the page themselves had room to improve aesthetically.
- The data is now clearer. I put the operational data on the left and the analytical data on the right. It should be noted operational and analytical data are now linked. I will elaborate on this in the detailed section of this write-up. (or you can try it out yourself!)
- More intuitive to use. Using the tabs you can quickly scan the main KPI’s and if you want a more detailed view, you can click on it to get the individual data points, as well as the trend lines.
- I’m not a huge fan of the operational data as it is. I wanted to do more user interviews to see the pain points of the customers, but we ended up getting 0 interviews done that summer for the AerTrak platform.
- I’m concerned the tabs on the dashboard might get too cluttered if the user adds too many tabs. Still trying to brainstorm ideas on how to fix this type of issue for my future designs (would love to hear some ideas!)
- There’s a lot of features going on. I’m concerned the learning curve for this dashboard is much higher than the previous one.
Sidenote: I want to structure this Medium post so that the reader will get the main takeaways immediately looking at the pros and cons for each design above. (Woah that’s like improving the user experience on a medium post. Meta.). Past this sidenote is the detailed process that got me to the redesign above.
Mockup 1: The OG
At this point, I hadn’t really done any research on dashboard designs. I didn’t even know there was a distinction between operational and analytical data. So, as you can see here, I just tried to cram all functionality I could possibly think of.
Upon throwing these visuals together I immediately started on a new one, knowing this one was garbage.
Mockup 2: Electric Boogaloo
here I tried adding KPIs as toggles. I liked this idea since it allowed the user to see a quick glance at all their KPIs, and if they wanted to, they could click on it to see more detailed information. However, it felt very very cluttered with information and functionality density.
Mockup 3: Revenge of the Extremely Cluttered UI
I decided to double down on even more information overload. Not the move. Oopsie.
Mockup 4: (an aptly named) A New Hope
Here I removed all the clutter and attempted to make all functionality on the dashboard focus on one goal: displaying data quickly and easily.
Mockup 5: Help I’m running out of clever names
Here I tried to add the functionality to see the individual operational data. This just felt like it was more cluttered. I also redesigned the sidebar somewhere in between these mockups for a cleaner, more modern look.
Mockup 6: The Final Iteration (sorta)
I ended up changing the operational data so that you get a quick overview — similar to the tab functionality above the graphs. This felt more intuitive and more cohesive thematically.
This was my preferred final design, but removing the sidebar entirely would be too big of a change in user experience, which made this redesign not feasible for a final rollout.
Overall, I had an incredible time tackling this design challenge. This was my first time really honing in on redesigning just one functionality of a webapp for three months. This meant I would be able to keep refining my designs and, more importantly, had the time to do more research on how to refine my designs.
Since I redesigned the dashboard in my spare time between fixing bugs on the front end, it wasn’t considered a priority — and thus I didn’t feel pressure to follow the ‘standard’ approach to designing in an agile framework.
Without needing to hop on standup calls, or following the usual design sprints of user research -> low fidelity mockups -> user research -> high fidelity mockups, I could focus on refining what my own design process looked like.
Some key takeaways I learned:
- I personally iterate better by having medium/high fidelity mockups. If it’s only low fidelity, I think the design feels too abstract for me to iterate on. Learning how to use low fidelity mockups effectively is my next goal as a designer.
- User research is key. But when you can’t get any interviews you should resort to case studies. I studied Palantir, Uber, Lyft, and Hello Tractor for this redesign. Seeing the common elements of each dashboard helped me see some insights these companies probably received from their own user interviews.
- I think in previous design sprints I felt like a lot of the steps in between felt almost extraneous. Such as the user persona. However, what I realized is that I just don’t like the user persona template, not the user persona itself. By this, I mean that the user persona I created didn’t have a name or specific personality traits. Instead, it was just a lot of generalizations of what a fleet manager would want. For me, this style of thinking about the customer is easier to digest because I don’t feel like I’m pigeonholing myself to catering to just one niche subset of your entire user base.
All in all, I found my experience at Aeris very rewarding, and am excited to continue iterating and improving my own design process!
Thanks for reading!