Building a dashboard is as much art as it is science. Think of it the way a screenwriter thinks of a storyboard: A progression of information and images that lead the viewer from a beginning to an end. And like any good storyteller, you develop a story over time, with multiple drafts, plenty of editing, and a little feedback from your audience.
In my last post, I talked about the benefits of rapid prototyping in the dashboard design process. This week, I’ll walk through 5 dos and don’ts when creating and presenting a dashboard prototype to your users.
1. DO ask your users to show you what they want.
In initial meetings, ask users to draw on a whiteboard or show you examples of user experiences that they like—and ask as many questions as you can along the way: “What information do you need from me and what form do you need it in? What do you need to understand about this data? What do you like or dislike about this example?”
Kiel Knisely, Product Engineer at Avail Technologies, a software provider for public transit systems, says, “Customers like giving feedback regularly. They feel like you’re listening to their input.”
2. DON’T show real data right away.
“I’ve found that if you rapid prototype something, it’s best to just have generic data behind it,” says Knisely. If customers see information that looks real, he says, they may get too caught up on the data and have trouble reviewing the purpose of the dashboard.
The same holds true with other elements of dashboard design, like color, fonts, and icons. The risk of rapid prototyping is your dashboard may look so “real” that users can get caught up on the details and miss the big picture. When running the review meetings, keep the focus on your dashboard’s functionality and purpose. Explain that you’ll have additional meetings to finalize the design elements, but at this time you’re focusing on how it works.
3. DO go in with an idea first.
If you begin your meetings asking the customer what they want, without any guidance or starting point, you risk them wanting everything—or nothing at all.
On one hand, a carte blanche question means customers can ask for anything and everything. On the other hand, some customers may have no idea what they want, and an open question will only stump them. In both scenarios, the customer’s needs get eclipsed by an aimless conversation.
“Have a base to say, ‘this is what we’re thinking’,” says Knisely. “If you guide customers down a path, they’ll tell you if you’re on the right path, plus they won’t ask for the world.”
4. DON’T show them a finished dashboard.
It’s best to avoid showing a finished dashboard—in fact, the rougher the better. If your dashboard looks finished, if the mockup looks too good, then your end users tend to just say it looks good, rather than thinking about whether it really answers their questions.
As you create versions, mark them Draft, ask for feedback and then refine to get to a next version. If the conversation gets derailed, refocus the group on the goals of the dashboard instead of the looks.
5. DO start small.
Whether you’re in prototype mode or moving to a finished product, start with just a few KPIs for each user group. In the beginning, make sure you’re solving problems they face now and make it easy to enhance functionality in stages.
As you deliver intelligent tools and users become proficient with them, they will begin to ask new questions and adoption will increase over time. Dashboards are meant to change with your business over time, enabling you to remain informed as your business needs change.