Validating Your Design (Before It’s Too Late)

Once you’ve determined the data needs of the different personas in your user base and started coming up with your dashboard design, you still need a way to validate your decisions. Gathering requirements and pulling together datasets is purely quantitative work; design, however, is subjective—and it’s often complicated by human nature.

That’s why it’s vital that you user-test your designs while you’re building to make sure you’re on the right track. Just because you’ve “checked the requirements boxes” doesn’t mean people will actually use your dashboard. If your application doesn’t resonate, you’ll see poor user adoption—and that won’t benefit anyone.

Validating your design is an especially important step, but there’s one caveat: Don’t spend so much time or money on validation that you stall your project.

Gather feedback. Organizations looking at dashboards can’t make assumptions about adoption without involving stakeholders in the design process. By stakeholders, we don’t just mean dashboard users—you should also involve your designers, developers, and product owners in the evaluation process.

Get their input on design, user experience, and benefits early on; then check in regularly to show them how you’ve implemented their suggestions in a dashboard that will make their jobs easier. Ask your audience these basic questions:

• What information do you need from me?
• What form do you need it in?
• What do you need or want to understand about this data?

Get them to draw it on a whiteboard, or lead them through a short example or two. Your audience may not always know exactly what they want to see or how they want to see it. In that case, ask them simple “yes” or “no” questions and then iterate from there.

In the beginning, make sure you’re solving problems your users face now and make it easy to enhance functionality in stages. Start small and focus on just a few KPIs for each of your user groups.

Build a Wireframe

You’ve defined your audience and your users’ requirements. Now, you need to understand how various pieces of information can be displayed—and the way to do that is through a process called wire framing.

A wireframe represents a draft, not an exact match, of the final layout of your dashboard. It shows what the user interface will look like through rough images or screenshots. Knowing where everything is going beforehand is a huge development timesaver and provides users with a much better experience.

The primary goal of an analytics dashboard is to make sure what you’re showing on the screen is relevant to the people using it. Wireframing allows you to quickly piece together your thoughts based on your discussions with users, bring a visual outline to them, and ask them, “Have I understood what you’ve asked of me and what you’ve asked of the dashboard?”

The best way to understand wireframing is to look at examples. Additionally, the graphic below can help you decide which wireframing and prototyping tools will work best for your needs.

Build prototypes. As you already know by now, dashboard design is an iterative process. Think of your dashboard the way a screenwriter thinks of a storyboard; they are both progressions of data and images that lead the viewer from beginning to end. And like any good storyteller, you develop a story over time, with many drafts, much editing, and a little help from your audience.

In dashboard design, we call these drafts “prototypes,” and they are the logical next step after you’ve finalized your wireframe. You can build prototypes using a rapid prototyping tool such as Axure, EasyPrototype, or iPoltz. Prototypes are ideal for communicating design because they look more or less the same as the finished product (as opposed to the wireframe, which is more of a basic layout/grid). Rather than just asking your users what they think of your abstract concepts or sketches, you can actually mock up on-page interactions for them to try.

Just remember that your prototypes should still look like drafts. If your mockup looks too “finished,” people will tend to simply say it looks good, rather than thinking about whether it really answers their questions.

As you build prototypes, ask for feedback on each version, refine it, and get a revised version to your stakeholders quickly. Repeat this process as many times as it takes.

Regularly test and revise. Even after you’ve finalized your design and successfully deployed your dashboard, your journey doesn’t end. Plan to monitor usage, continue usability testing, and actively acquire feedback from all stakeholders. Let that feedback inform future design plans and revisions.

Consider building a phased project plan that focuses on building up the success of ever-larger groups of users, one at a time.

By the end of the project, your early adopters should feel a sense of ownership and become your strongest advocates for dashboards. Whether saving time, gaining better visibility, or supporting job functions, employees need to feel empowered—and this includes designing their own interactions with the technology they are required to use on a daily basis.