Design Thinking for Dashboards
A chunk of our work is in design. A chunk of our work is to help people use data better. So, with these two activities we are often asked to help teams at the overlap of these two chunks: good design for dashboards.
Anybody who has taken a design thinking course has been introduced to the concept that is often explained as three circles overlapping in a Venn diagram.
Desirability is what people want or need, and the degree with which they need it. All of us, at least most of the time, prefer doing things in familiar ways no matter how imperfectly the outcomes. It just isn’t worth changing if the problem isn’t important.
Feasibility is what is possible to build from a technical standpoint. A flying carpet would be immensely desirable (skip the traffic, easy to roll up, and work as a yoga mat), but, so far, hasn’t made it out of the research lab.
Viability refers to answering the question: is it worth doing? Usually this is measured in financial terms: will our new product solve a highly desirable problem, result in sales or profitability that is great enough to overcome the costs of developing this solution. Costs, while commonly expressed in financial terms, should also encompass the effort to do the project and the uncertainty of attaining the desired outcome.
When we work on a project to develop a new dashboard, or series of dashboards, we also visualize the design challenge with the three circles, adjust for the domain of data, and for the fact that often dashboards are used internally and require different metrics.
How do we approach desirability when it comes to designing dashboards?
The answer: in much the same way we approach any design problem.
We want to know, what is the user (the consumer of the dashboard) trying to accomplish? We are trying to find the user’s goals–what is their ideal outcome? A fast decision? A more confident decision? A decision that makes them look good in front of their boss or their colleagues?
At the same time we are trying to understand their pains: what barriers are keeping them from reaching those desired goals? Maybe the user doesn’t trust the data in the existing dashboard. Maybe the information is out-of-date, and they need to call directly to somebody (where the data is getting created: a transaction at a bank, an IoT sensor on the factory floor) to confirm the data they have received. The user lives in fear of making the wrong recommendation because they had the wrong information, old information, or not enough information. Like any design challenge, a user’s goals and pains are heavily influenced by emotions, even if they are trying to act objectively.
Throughout the process of understanding desirability we don’t want to fall into the solution-mindset trap: we aren’t trying to fix an existing dashboard, even when the user is describing their goals and pains w.r.t. a tool they currently use.
As we move to gaining insights about feasibility, it is tempting to think, “our solution is a dashboard.” Much time is spent looking at fonts, placement of information on the screen, and deciding where the buttons are to call up back up screens. This over-emphasis on the visual is often found in other common design applications, the design of apps and websites. With high-fidelity tools such as Figma, it is easy to create something that looks real, to the excitement of the designer–and worse!--the excitement of the user.
A beautiful layout, carefully chosen colors and fonts, nice buttons, the right icons, give the feeling of “done”-ness. The problem: while the user is beguiled with the beautiful layout, they are imagining their job getting easier, better, faster, with higher confidence. Beauty, alone, (in a dashboard, at least) cannot deliver those things.
Feasibility, therefore, should include the visual aspects of the dashboard, but far more important is the existence of the exact amount of data, in the necessary format, completely cleaned and free of duplication or string errors, at exactly the time an important decision needs to be made.
Dashboards are the face of the design project, but the real challenge is can we, or how can we, get the data that is required to allow the user to reach their goals and minimize their pains.
Feasibility asks whether the data is available, what sources provide it, how can it be brought to one single place, is it complete, is it accurate, is it timely.
Finally, viability is an important part of the dashboard design process, even if there is no external customer and no direct impact on sales. What makes the dashboard project worth doing? There might be readily calculable means for demonstrating a cost savings, or an improvement in work efficiency (the user can handle 20% more cases in a day’s work).
More difficult to measure, but often far more important, are gains in aligning activities across an organization.
The right data, brought together and presented in an easy-to-use format can ensure disparate teams can coordinate their efforts, making each of their jobs more efficient and also providing gains in service quality to external stakeholders. Finally, the cost of getting the data is an important part of viability. Feasibility asked whether the right data was available at the right time. Viability asks whether the costs (including time and uncertainty) of making that data available at the right time, is worth it, given the expected outcomes.