Design thinking to ace designing dashboards
--
So you have decided to design a dashboard? That’s great. I am going to provide some suggestions that could help with the process. I share these insights from my experience designing dashboards. Depending on the type of dashboard you’re designing, and whether you’re designing from scratch or redesigning your approach could change. But I am going to share some general guidelines that you can keep in mind when designing. So let’s get started.
For the purpose of this article, we can assume that we are designing a dashboard for a sales manager of a cake bakery shop. Customers use online ordering app to place cake orders.
Understanding the need: First of all, we would like to understand if we really need a dashboard. How do we know that a dashboard is a potential right solution? Did the PM propose the solution? If yes, why? Are there any other ideas we could think of? If a dashboard already exists, taking a look at the page visits, engagement, and usage statistics would help know if the dashboard is useful for customers or not. This stage is more about knowing the customer’s problems. Sometimes when we are asked to design a dashboard, it is easy to start solutioning. But instead, taking a step back and gathering data about the pain points customers are having today would help us dive deep into the problems. We might hear from customers about difficulty monitoring a fleet of resources, hard knowing which resources need help, spending too much time debugging, etc. In the case of our cake bakery example, the sales manager might want to know how many cakes are being delivered currently, how many orders can be grouped together to assign a delivery person, orders that were delayed or had wrong items, etc. After we have gathered data, it is time for some discovery and exploring high-level concepts.
Discovery (defining goal of the dashboard): After we have understood the customer problems, it is good to schedule a couple of deep dive & workshop sessions with the team. On my projects, I scheduled sessions with PMs, engineering leads, customer support, and internal customers to learn what questions customers might be asking when looking at a dashboard. FigJam comes in very handy for such sessions. I like to add my notes from research during the sessions so the stakeholders get context. If you need guidance on creating FigJam for these workshop sessions, add a comment and I will write another article and share templates for the same :)
Keep in mind that when it comes to designing a dashboard, EVERYONE has opinions and their feedback might be very specific to the team they are on. For example, customer support might be focused on troubleshooting scenarios as they deal with those issues on a daily basis. So involving more stakeholders will broaden understanding of problems and needs. At this time, the goal is to collect as many data points as possible and not narrow down on any problems. When you have notes from everyone, start grouping them based on common themes. For example, monitoring cake delivery status to manage deliveries, orders requiring customer support for immediate actions, cake ordering patterns to learn about customer likes/dislikes, etc. We can conduct a prioritization workshop to rank these categories based on their importance. At this stage, using the previous research findings along with our assumptions is a good idea.
All these themes will help us define the goal(s) of the dashboard. This will also open up conversations about any secondary target customers we should be thinking about. It is very easy to assume that all the customers are target customers of a dashboard. It could be true in some scenarios but there will be a group of customers whose job is to monitor these statistics. So narrowing down the target audience at this stage will further help define the goal of the dashboard.
Note: Stay away from defining metrics at this stage. During the workshop sessions, some of the stakeholders might end up writing down the metrics — Avg. number of customers ordering chocolate cake vs. vanilla cake. These can deviate the team from staying high level or seeing the big picture. These feedbacks are helpful in the later stages. So save them for later.
High-level concepts: Assuming that we have defined the goals of the dashboard, we are ready to do some high-level conceptualization. In this stage focus on the story of the dashboard. Write down the story you want to tell through this dashboard. The customer journey for the full product is extremely helpful. Let us assume this simple flow for our bakery example:
Customer schedules order -> Bakery prepares order -> Available delivery person takes the order on time -> Cake is delivered to the customer
In this case, using this simple flow/journey the story dashboard that the sales manager could be interested in is:
- Customer schedules order — Which cakes are most liked by customers? Which occassions are most popular? During which season do we get the most orders? and so on..
- Bakery prepares order — Are there any times when we get last-minute orders? How much inventory do we have? Are we storing too much or too less inventory? And so on..
- Available delivery person takes the order on time — Who is available for delivery? Which delivery destinations are closer/in the same way to be grouped and assigned to the same person? How many deliveries are got delayed? How many orders had issues (wrong address, wrong items, etc.) and so on..
- Cake is delivered to the customer — How many customers called customer support regarding any issues with items? How many customers are returning customers? How many customers left good reviews? And so on…
We have deconstructed the steps of the journey to construct the dashboard story. Some of the questions might not be helpful for customers but some of them might be — we need to validate them later. This exercise just helps think of each touchpoint and find new opportunities.
Okay, now that we have the story we can do sketching/lo-fi wireframes just to tell this story. We should use all the data from previous sessions to define this story further. The new opportunities help to close any gaps we might not have thought of before. Create high-level concepts without getting into the metrics. These concepts will help in the following sessions to define metrics with the team.
Defining metrics: Using the high-level concepts in the previous step, it is time for us to start defining metrics. Include the notes from customer research sessions, workshop sessions, and any available dashboard/tools. This is also a good time to look at similar dashboards from competitors. The goal is to stand out from competitors, not to copy :) Dashboards that aren’t exactly from the same domain are also good for inspiration on metrics.
During the workshop include PMs, engineering, customer support, documentation team, and internal/external customers, if possible. Based on the customer access, feel free to add them to the session. For the story we created, ask the stakeholders to write down metrics that can help communicate it. Along with metrics, we should also ask them to write how would this metric help. For example, for understanding which cakes are liked by customers, the metrics could be — most ordered cakes over time, least ordered cakes over time, sales by product over time, seasonal sales, etc. We should do this exercise for the whole story. At this stage, we will have a ton of metrics.
Ideation: At this stage we —
- Understood customer pain points
- Defined the dashboard story
- Defined the metrics to communicate the story
Now it is time to do initial designs. Using all these data, create initial concepts. This time we want to focus on the design details — the layout, type of metric aggregations, dashboard filters, etc. We want to validate the assumptions we have. I will be honest that it isn’t possible to satisfy all the customers completely. But we want to ensure that our dashboard is useful and customers are visiting it on a regular basis to make their life easy. At this stage, there will be a ton of feedback, a lot of design iterations, and perhaps defining phases of the dashboard launch. If our dashboard never existed, it is good to launch the first phase with core minimal metrics and gather customer feedback.
Customer feedback: Preparing a research plan for at least 10 different customers would help us. We could pick new & experienced customers, small, medium & big enterprises, use case-based customers, etc. For example, if we are designing a dashboard for the cake bakery it might be helpful to get feedback from new and experienced customers. The customers ordering in bulk and individuals are also helpful. We should focus on the diversity of customers if the dashboard never existed.
We should also accept that the dashboard will evolve over time. The more closely we will work with the customers, the better the dashboard would get over time. I suggest doing a beta of the dashboard, if possible. From the beta, we can gather data after launch, iterate, and launch the final version with a bit more confidence in general availability.
Define success: When we defined the goal of the dashboard, we also in a way defined the success criteria for our dashboard. For example, if the goal of our dashboard is to help the sales manager become efficient at handling orders, we want to how much time the sales manager was spending before vs. after launching the dashboard. We should define the success KPIs before we launch so we can evaluate how we’re doing.
Measure success: The metrics that we defined in the previous stage should tell us how we did. In addition, we should measure general metrics such as — how many customers have been visiting the dashboard (before vs. after), dwell time on the page, actions taken on the dashboard, drop rates from the dashboard, etc. This is also a good stage to gather quick satisfaction ratings from customers. We could do that by a generic form/message on the dashboard. Keep in mind that we don’t want to annoy customers by showing them such messages every day :) The more contextual those messages are, the better. We should also gather feedback from interviews. Combining the quantitative and qualitative feedback could give us better insights into the customer experience. Based on the feedback, we can revise and make the dashboard better over time.
I hope that this article helps you design a dashboard. I have conducted a lot of workshops with stakeholders for different designs. If you liked this article and want guidance around workshops or FigJams I have created for these workshop sessions, I will post part 2 of this article. Please comment if you would like that.
I am very thankful that you read this article. If you enjoyed reading the article, tap the 👏 button below :)
