10 Common Mistakes in Creating an Effective Dashboard

If you have the job of designing an effective, actionable dashboard for your organisation, lots of advice is available. Most of the guidance for dashboard design focuses on what you should do during the process but in addition to all of the ‘should-dos’ related to dashboard design, there are also some ‘better-not-dos’ that you should be aware of. These are 10 of the most critical mistakes commonly made during the process of creating dashboards.

1. Trying to Make All Users Happy

There’s an old and wise saying: You can’t please everybody. That’s a bit of wisdom that certainly applies to dashboard design. But all too often a dashboard design project begins with an ambitious but unrealistic vision: making everyone in the organization happy with the dashboard.

Different users have different goals and needs when using BI dashboards. By targeting a specific target user you can design the dashboard to provide an easy, quick, intuitive, task-driven experience for users.

Trying to satisfy everyone will likely fail and, instead, will make everyone less satisfied.

Instead: Try to narrowly define your target group of users by creating a specific and concise list of goals, tasks, and functionalities that are of utmost importance to your target end-users.

2. Skipping Storyboarding in the Design Process

The most challenging aspect of dashboard design typically revolves around getting all parties on the same page, especially with regards to strategic matters such as:

• What are you trying to achieve with this dashboard/application?
• Who are your end users, and what are their responsibilities and goals?
• What are the tasks users want to perform with this dashboard/application?

Unfortunately, skipping this step also means stripping the dashboard project of a strong foundation. Without a clearly defined scope and strategy, your requirements will grow into an amorphous blob – bulky but without direction. What could be a worse nightmare for developers?

Instead: Storyboarding establishes the goal of the users (what goal to achieve and what tasks to be performed) and the scope of the dashboard (how much data is to be used). Back-end and front-end developers, the project owner, and end-users should all participate in this storyboarding session and form a clear understanding of the wireframe, which should be the outcome of the session.

3. Including Too Many Formatting Details on the Wireframe

As designers, we are under pressure to show a colourful prototype as soon as possible to please business users. But ideally, a wireframe should not use colour. Its main purpose is to provide a visual representation of strategic requirements and the scope of the project. Therefore, colours on a wireframe should only serve to clarify layout or draw a contrast between elements. Including different colours in a wireframe can trigger concerns based on the personal preferences of users. And that can lead to a never-ending argument about colour choice.

Instead: Spend your time harnessing your data requirements and the intentions of the dashboard user. Use different shades of grey and white space to create contrast, separate functional areas in the dashboard, and highlight information.

4. Asking Your End-Users “What Do You Want?”

“People don’t know what they want.” – And yet it is your job to deliver what they want.

Most of the time, what people claim they want is not what they need, and would not solve their problems. Their preferences are often based on past casual or brief encounters with other products, which ultimately may not offer the most optimal solution.

But be forewarned: When your end-users get hung up on one impractical idea, it can be quite challenging to convince them otherwise!

Instead: Ask users about the problems they are trying to solve with the dashboard. Offer your users options for solving those problems, and narrow down the options by asking about their needs and constraints. A bonus benefit to this approach is that users will feel like you really care about them, and that encourages them to be more cooperative.

5. Asking Users What Visualization to Use

The visualization to be used in the dashboard design should not be regarded as a requirement you can “gather.” Instead, it is a solution you need to offer while staying aware of users’ needs. Don’t compromise when your audience gets excited about a flashy chart they’ve seen somewhere. It is your job to know the pros and cons of each visualization, and whether it’s a fit for the users’ needs.

Instead: Ask what insight or knowledge users want to learn from their data, and the informed actions they would like to take. The important thing is to really know your visualization toolsets and to educate your audience about the possibilities.

6. Presenting Data without Context

Numbers are nothing but ink without a context. Numbers also have different meanings for different users. For example, ‘last week sales’ in an operational context might be satisfactory for operational analysts because they meet weekly. But for marketing, that data does not show whether the marketing campaign had any impact on sales, or for tactical managers, it does not indicate whether they have achieved the expected growth, or are behind competitors. It’s important to pay attention to context to make your dashboard insightful and actionable.

Instead: If users have not provided the desired context, ask them: How do they view their numbers? What are the benchmarks that would provide a context for evaluating their numbers? There may be internal or external references that the team did not have the opportunity to discuss.

7. Using More Than 3 Colors on the Dashboard

Whether it’s the colour of visualization or dashboard functional elements, do not use more than 3 distinct colours (hues). No matter how tempting, do not go after flashy looks or copy exactly the styling of your favourite dashboard. Keep in mind that UI elements (buttons, callout, checkboxes, etc.) should not take away the focus from data visualization, alerts, and other insights. Your colours need to serve a clearly defined purpose. The best practice is to use a maximum of 3 different hues in a dashboard.

Instead: Use neutral colours or muted shades. This technique will serve to differentiate areas without making the dashboard appear busy. Use bright shades sparingly to highlight colours.

8. Showing Too Much Granular Detail on the First View

Showing too much can hinder the users’ ability to focus on what’s important, and can slow down their abstract thinking ability. Whether your end-user is a top-level executive or an analyst, give them only the most important information portioned out in an easily consumable, first-glance amount. For example, if a business decision-makers path starts with finding the top regions in sales numbers, there’s no need to show all regions. Instead, just showing the top 10 will suffice.

How do you know if you’re showing too much detail? If the details do not directly support what you are trying to convey to the users, then you’re probably showing more detail than necessary.

Instead: Carefully study the decisions your end-user makes in support of the goals to be achieved (Cutting costs? Increasing sales? Spotting outliers?), and analyze the user’s workflow to determine what snapshot of information they need at each step of the decision-making process.

9. Displaying Too Many Alerts

We’ve all been guilty at times of populating our dashboards with overwhelming numbers of red/green alerts. We do so to help make our dashboards more insightful and actionable. But too many alerts can lead to confusion about where users should start, or what they should focus on. For example, some dashboard users don’t need to be alerted when something is doing well or slightly above average. Depending on the scenario, alerts should trigger an action from users. If no actions are available or needed, an alert is redundant.

Instead: Have a discussion with your business users about the alerts that are truly important in their decision-making process.

10. Ignoring User Acceptance Evaluations

Whether you can afford the time to have this process within your agile cycle or not, user acceptance provides very important feedback for designers. It helps to determine the success of your project but also confirms if your communication with users or project owners is effective. And it’s often the only chance you’ll have to get feedback from end-users – so take advantage of it!

Instead: Have a plan for what aspects will be covered in user evaluation testing from day one. That means focusing on the most critical functionalities of the dashboard. This does not have to be a hectic process; a quick survey posing specific and relevant questions will suffice.

Do Steer Clear of Mistakes

Every dashboard development project will be a little bit different. That’s because each dashboard created has a specific function to fulfil. But ultimately, the job of every dashboard is to help steer your organization to success. And the best way to assure that your dashboard is up to that important role is to steer clear of the common mistakes listed above during the development process.