Case Study: Designing Dashboards
Turning the finances into a passive dashboard
When designing user dashboards, stopping and taking a few minutes to plan what you want to provide will go a long way in creating a valuable end product. Let’s face it. It doesn’t matter how good a dashboard is; it will mean nothing if nobody uses it.
A bit of context:
Why do people want dashboards in the first place?
They are the most literal representation of data possible.
Companies are still figuring out how to make sense of all the GIGANTIC data they are collecting. The best ones are doing amazing things with machine learning or bots, but by and large, it’s still a field just hitting its stride. While designers (like myself) like to whine that dashboards aren’t helpful, they give most users excellent insight into previously opaque data.
They look cool
I am the first to admit; good UI does not always mean “cool”. Even in the days of keto-mania, the best interfaces were visually simple.
So when you’re designing a new product, it’s hard to elevate your work to become screen-grab-ready (I think this has driven the trend to more illustrations and block-frames in product marketing sites).
They are the showroom for products.
It’s effortless to use a dashboard to convey a lot of functionalities. You can put little graphs, some lists with people on them to show collaboration and a mini-calendar. It’s like the first floor of IKEA.
But let’s be honest. It is a safe space here. Dashboards terrify most of us. All the colours, spacing, and a constant bombardment of mortifying Dribbble shots from designers halfway across the world. It’s too much.
Project Goal
My client provided me with an excel sheet with all kinds of sales data, and the idea was to create a single place to share all of that information, so anyone could dip in and stay up to date.
The Problem
I was supposed to design a dashboard that could streamline the product sales data by consolidating the features that matter the most and creating a relationship between the data points. The scenarios presented were how to view
- Segment-wise sales for each Month
- Product-wise number of units sold
- Country-wise Sales in the value of products
- Segment-wise profit of products
- Total sales by Month and segment
- 2014 and 2013 sales by Month
- 2014 sales by product
Further, with such numbers and data, I was to avoid cluttering up the Dashboard. Avoiding ‘data vomit’ to show more data; in reality, we simply vomit data onto the screen. We may give our users some interesting and even valuable tools for manipulating, sorting, filtering and browsing through that data. Still, often we have failed to truly help them because all we’ve given them is data.
I also had to remember that UI should be simple enough to develop. Whatever you design by way of graphs will have to be built, and usually, developers will be using a kit or library. So all that Dribbble nonsense you want to do will be cut immediately when you get to scoping. Instead, I explored the charts available with developers and restricted myself to sizing and colours — the important stuff.
User Experience Design Process:
The idea behind the Dashboard was to have sales data efficiency and maintain one single view for tracking every intricate detail on the go. I followed IDEO’s Human-centered Design Thinking approach, which goes this way :
Personas
Using the Lean UX framework, I defined my persona to understand my user better.
Knowing Rachel’s habits, it was clear her most significant need was a one-stop shop for her everyday tasks.
If the goal was to optimize Rachel’s workflow, I needed a way to measure if I had succeeded or not.
Ideation & Solution
To make the data crisp and clear and on the fingertips, I needed to identify what exactly the user wanted:
To make effective navigation, I had to group the categories into number-based and non-number-based.
I placed three different filters of Time, Segment and Country; and made a graph for Sales, Profits and Products. However, this graph does not cover two scenarios, so I had to make different graphs.
Product Leaderboard (w.r.t. to Time, Segment and Country)
Segment Leaderboard (wr.t. to Time and Country)
I tested and created all the relationships between the mentioned categories:
With the relationship established and a rough wireframe for the same, I picked up the UI of the Dashboard, keeping it while choosing the best possible graphs to display the information.
Conclusion
This task was exciting to study the problems and give a solution while knowing the technical challenges I may face because the cause of all our UX and UI problems is a need for more communication between designers and developers.
Dashboards communicate — they tell us the real story of what is happening and the right/wrong side of the business, and this communication must be a conversation — there can’t be a 1-way dialogue.
