At the beginning of my Practical Dashboards workshops, I ask participants what their main challenges are when designing dashboards. Regardless of what type of organization they work for, the top challenge is almost always the same: Some version of “My users don’t even know what they want.” In a workshop, this may come out as…
“My users call everything a ‘dashboard’.”
“My users all want something different.”
“My users only give me vague requirements that aren’t nearly specific enough to design a dashboard around.”
“My users ask for different things at different times.”
“My users want everything [i.e., ridiculous amounts of information] on the dashboard.”
To me, though, a dashboard designer complaining that users don’t even know what they want is like a physician complaining that patients don’t even know what treatment they need. Of course they don’t! Obviously, it requires a great deal of expertise to examine patients and then figure out which treatment will be most helpful to them, and it’s not reasonable to expect them to figure that out on their own.
For whatever reason, though, far fewer people seem to realize that the same also applies to dashboards. Figuring out what type of information display is going to be most helpful to users (a weekly auto-generated email? a presentation slide? a push alert? a dashboard? if so, what type of dashboard?) requires a great deal of training and expertise, and we shouldn’t expect users who haven’t had any such training to figure it out on their own. As reporting professionals, we need to bring that expertise to the table to figure it out for them. That’s part of our job description, not theirs. Obviously, we need to listen to them, but…
We shouldn’t expect users to give us fully formed, specific reporting requirements; we should only expect them to tell us what their concerns, complaints, and business needs are. It's up to us to turn those into specific requirements.
(Of course, some users do have very specific ideas about how to design their dashboards, but this tends to turn out about as well as when patients tell their physicians which treatments to prescribe, i.e., not well, unless the user/patient is a specialist themselves. This is definitely one of those cases where the customer isn't always right.)
This is why directly asking users what they want their dashboard to look like usually results in poor user satisfaction and, all too often, an abandoned dashboard.
Engaging with users to figure out what kinds of information displays they need and how to design those displays is an entire skill set unto itself, and requires more than just “being a good listener” or “being client-focused”. We need to be armed with specific, targeted questions that help us understand why users need the information and how they'll be using it, such as:
Are there specific types of problems that you’re concerned that you’re not noticing within the organization?
Can you name a specific action that you’d take if this metric were to go into a problematic range?
How quickly might you need to respond to this metric?
Do you have any hopes or expectations around what this metric should be?
When/how often do you need this information?
While asking the right questions is essential, there are, of course, other skills that are required to design truly useful dashboards, which most users lack. In particular, designers need to be familiar with a wide variety of different types of dashboards and other types of information displays so that we can match users’ current needs with the most appropriate type of display, just as physicians need to be familiar with of a wide variety of treatment options to prescribe the most appropriate one for a given situation. (And, in both cases, the patient/user may never have heard of the treatment/display type that’s going to be most helpful to them.)
Once we’ve figured out what type(s) of information display(s) are needed, we also need to be able to design those different types of displays competently, just as physicians need to be able to perform a variety of treatments (surgical procedures, etc.) competently. Again, this is something that requires a high degree of skill, and we shouldn't expect patients/users to have those skills.
What if we ourselves lack some of these skills? How can we learn them and deliver truly successful dashboards that users actually like? A couple of decades of experience usually does it 😊 If you want a slightly quicker way, though, well, these skills are basically the high-level learning objectives of my Practical Dashboards course.
By the way…
If you’re interested in attending my Practical Charts or Practical Dashboards course, here’s a list of my upcoming open-registration workshops.