If you work in sales ops, finance, or any executive-facing analytics team, you already know this. Your vice president  won’t open Tableau Server at 9 a.m. before the board meeting. They’ll download your dashboard as an image or  powerpoint, paste it into slide 17, and present it to the C-suite.

Once I accepted this reality, I started treating this as a design problem. Here are five non-negotiable factors I learned on my Tableau journey.

1. Design for PowerPoint From Day One

Device preview matters exponentially more when your dashboard will live in a powerpoint deck.

In the early stages of redesigning an executive-level sales report, I built my dashboard in Tableau’s default “Desktop Browser” view. When I downloaded it as PowerPoint, it crushed into a single slide with illegible text — a formatting disaster right before a leadership presentation.

The fix here is using Tableau’s built-in PowerPoint layout (16:9 aspect ratio) from day one.

This ensures your dashboard fits perfectly into standard Google Slides or PowerPoint without awkward cropping or white space. Don’t design for Tableau’s default dimensions — design for where your dashboard will actually be consumed.

Pro tip: Always test your export before the final version. Click “Dashboard > Export as PowerPoint” to preview exactly what stakeholders will see.

2. Accept That 80% of Functionality Disappears

This is the hardest lesson: You must build assuming zero interactivity.

What dies in PowerPoint:

• Filters (static view only)
• Parameters (whatever was selected during download)
• Hover tooltips (invisible)
• Drill-downs (gone)
• Dashboard actions (non-functional)

This changes your design strategy. Now you have to build multiple static versions of what each filter setting your users will want to view. For example, my executives were interested in seeing  pipeline performance across sales regions, sales clusters, business units, and product lines. What would have been one dashboard filter is now separate dashboards I had to create:

• “Pipeline_Review_by_Sales_Region”
• “Pipeline_Review_by_Sales_Cluster”
• “Pipeline_Review_by_Business_Unit”
• “Pipeline_Review_by_Product_Line”

Yes, it’s more work. Yes, it feels redundant. But it’s the only way to ensure your stakeholders see what they need without interactivity.

Every critical insight must be visible on page load. If it requires a click to reveal, assume it will never be seen.

3. Use Containers for Layout Control

When your dashboard contains multiple visualizations, containers keep everything locked in place during the PowerPoint export. Without them, floating objects shift unpredictably — your perfectly aligned KPI cards end up overlapping your bar chart in the downloaded version.

PowerPoint downloads don’t tolerate white space. A minimalist Tableau dashboard might look elegant on screen, but it looks unfinished and unprofessional in a deck. Executives expect dense, information-rich slides.

Why containers solve both problems:

• They lock your layout in place (no shifting elements)
• They help you maximize space efficiently (no awkward gaps)
• They give you precise control over how information flows

This dashboard exports with excessive white space, making it look unprofessional in decks.

Best practice workflow:

1. Create a low-fidelity mockup of your dashboard layout
2. Build the container structure first (horizontal and vertical containers)
3. Drop visualizations into containers last

Pro tip: Watch this Tableau container best practices video before building your next dashboard — it’ll save you hours of reformatting frustration.

4. Establish Governance Standards for Version Control and Collaboration

If you’re working collaboratively or managing multiple dashboard versions, implement a simple visual system:

Use the color coding available for dashboards:

• Green : Production-ready, safe to download
• Yellow : Work in progress, do not present
• Red : Draft/testing only

Keep consistent and clear worksheet naming conventions. This will save your sanity.)

DON’T: “Bookings (1)”, “Bookings (1)(1)”, “Sheet 3”
DO: “Q4_Bookings_Final”, “Pipeline_Review_v3”, “Pipeline Coverage_BarChart”

5. Add Company Logos

Align as closely as possible to your organization’s standard slide deck template.

Why this matters: Your dashboard might be internal today, but it’ll be in a client presentation tomorrow. When your VP forwards it externally without asking you first (and they will), professional branding matters.

Where to place logos:

• Top-left or top-right corner (consistent with company templates)
• Footer with date/data source
• Consider adding a “confidential” watermark for internal metrics

The Bottom Line

The moment you accept that your Tableau dashboard will become a PowerPoint slide, you start designing better dashboards.

Stop optimizing for interactivity. Start optimizing for screenshots.

Use the 16:9 layout. Build static versions of filtered views. Lock everything in containers. Name your worksheets like a professional. Add your company logo.

Your stakeholders don’t care about your elegant parameter actions if they can’t paste your dashboard into their Monday morning deck.

Sometimes being a great analyst means accepting that your masterpiece will be Ctrl+C’d, Ctrl+V’d into slide 23 — and designing for that reality from the start.

The post Building Tableau Dashboards for the PowerPoint Download appeared first on Nightingale.

In this context, beauty refers to a practice known as affective design which leverages an emotional response from viewers. Instead of solely focusing on presenting information in a clear and objective manner, affective data visualization uses design to evoke very human reactions such as curiosity, empathy, surprise, even excitement. By engaging viewers on an emotional level, we enhance the impact, engagement, and understanding of the data presented. 

This approach recognizes that emotions play a significant role in how individuals perceive and interact with information. By leveraging affective design techniques such as color psychology, visual metaphors, animation, interactivity, and even typography, we can create deeper connections with our c-suite audience by making our insights more relatable and memorable. 

Engagement and attention

One of the primary reasons affective design is essential in visualizing business data is its ability to capture the audience’s attention and encourage engagement. In a sea of information, visually appealing and emotionally resonant designs stand out, drawing viewers in and prompting them to explore the data further. By incorporating elements that trigger curiosity, surprise, or intrigue, data visualizations can spark interest and keep viewers engaged, ultimately leading to a deeper understanding of the insights presented. Audiences want to keep looking at things that are beautiful, and as a data visualization designer, that can buy you time to communicate deeply with a viewer.

Retention and recall

Emotions are closely linked to memory, and data visualizations that evoke emotional responses are more likely to be remembered by viewers. When individuals feel emotionally connected to the information presented, they are more inclined to retain key insights and recall them when needed. Affective design enhances the memorability of data visualizations, making them more effective tools for communicating complex information and driving action within organizations. This is especially important for audiences that see and make decisions with data visualization frequently. 

Building confident decisions

Critical decisions are made because of insights presented by consultants. But if the boardroom isn’t confident on a course of action, progress will slow, milestones are missed, approvals can be delayed, and eventually the work may need to be redone. By evoking specific emotions such as trust, empathy, or excitement, data visualizations can shape how individuals interpret and respond to the information, leading to more informed and effective decision-making. 

Ultimately, the goal of consulting is to deliver value to clients. Clear, insightful, and visually appealing data visualizations contribute to client satisfaction by facilitating understanding, fostering collaboration, and driving positive outcomes. Our challenge is not just to present insights, but to do so in a way that captivates, convinces, and compels action. This is where the power of beauty, in the form of affective design, emerges as a transformative force. 

The post On Business and Beauty in Data Visualization appeared first on Nightingale.

There are five important elements to consider in the design phase for building great data visualizations. These elements should be incorporated while designing the dashboard and serve as a checklist once the dashboard design is complete. Using these elements help insist on high standards, especially when the target audience are business users. These five elements are:

1. Data Context
2. Visual Flow
3. Color
4. Typography
5. Appeal

Let’s look into each of the elements in detail.

Data context

It is important to make sure that the data is meaningful and aggregated correctly. If “visualization” is a motor vehicle, then “data” is its engine! No matter how fancy the dashboard looks, it serves no purpose if the wrong data is displayed. Hence, display of correct numbers in the dashboard is critical.

For example, consider an analysis of sales data in different countries. Some large countries may have higher overall sales than small countries. However, the sales percentage compared with the entire population of the country could be lower. In such scenarios consider average or weighted average for determining sales performance.

Visual flow

According to research by the Nielsen Normal Group, humans read the pages in a “Z” pattern. This pattern ensures a meaningful and logical sequence. It creates a perfect visual momentum which leads the users to transition from one visual to another in a smooth manner. If “visualization” is a home, then “flow” is its floor plan! Hence having the metrics (KPI’s) as tiles at the top, charts in the middle, and filters on the sides (or at the top above KPI’s) establishes the right flow. This logical flow and consistency from one visual to the next, will ease viewer’s entry into the dashboards. It will encourage them to spend more time on the dashboard, which is one of the important goals for the builder.

Color

Choosing the color choice purposefully is very important. The human brain reacts instantly to color presentation, and this creates an important first impression. If “visualization” is a stage, then “color” is the spotlight! Color draws attention of the audience and focuses on the most important data. Hence this step has to be deliberate, consistent, and meaningful which helps users to form valuable conclusions. 

Let’s look into some more tips on color usage.

• To simplify focus on data and insights, charts should be primarily monochromatic – using one color and a gradient of it. It helps show trends in the data across a spectrum and navigate in a smooth manner. Distinct colors should be used only to highlight key metrics or different categories. It is highly recommended to not have more than 6 or 7 colors in a single dashboard. There might be some exceptions when using bar charts or in scenarios where the intention is to be colorful. 
• When it comes to color, “less is more.” Color is a form of information encoding. So extremely colorful dashboards lose the potential signaling opportunity as the standout data points will get lost in the noise of all the different colors.  A good rule of thumb is to only use color when you want to signal something. Yes, this is ‘boring’ but ensures your signals are obvious. One can also use color to highlight potential actions. For instance, it is a de facto standard across the web that blue is used to signal hyperlinks/action buttons on web pages. This is so subtle most people don’t even consciously register it, yet sub-consciously we all ‘know’ a blue button will do something.
• Be consistent in your use of color across the entire workbook.  If ‘positive growth’ is shown as green on ‘visualization 1’, make sure you don’t use green on ‘visualization 2’ to signal the ‘sales’ category. Your job is to be user/viewer obsessed and minimize the amount of ‘work’ the user/viewer must do to interact with your workbook/dashboard suite. 
• Color is culturally encoded. For example, in China, red signifies winners and green signifies losers in the stock market. In the United States, losers are red and winners are green. Therefore, build the visualizations according to your theme and the audience.

Accessibility

Studies by Colour Blind Awareness have shown that approximately 1 in 12 males and 1 in 200 females are color blind.

Worldwide, there are approximately 300+ million people with color blindness! The most common form of color deficiency is red/green color blindness followed by blue/yellow. To serve this user group, avoid using red/green or blue/yellow color pairs in the same chart where feasible. Use gradients of colors as they are accessible for those who are color blind. For instance, red/green color-blind individuals distinguish between different shades/saturation levels of green or different shades/saturation levels of red, just not between green and red. Use an online color blind simulation tool to test how people with color blindness might see your information.

Note: If the red/green or blue/yellow colors cannot be avoided, use graphic shapes, instead. 

For example, ‘✓’ could be good and ‘X’ could be bad. Avoid dashboards that look like Skittles (too many colors). Some of the effective, accessible, and ‘non-skittles’ built-in Tableau palettes are: Miller Stone, Nuriel Stone, Superfishel Stone, or Winter. If you choose an alternate palette, do not mix palettes within a workbook. Some of the alternates are not fully accessible, so be careful.

Typography

Typography deals with overall lettering and fonts of the dashboard. It impacts the message and tone of the entire dashboard helping visually organize the information. If “visualization” is a photo then “typography” is its filter!

Tip: Referring to magazines or popular websites can help understand good typography.

Example: Using Calibri font in Tableau is a good option as it has a universal appeal. 

Note: The easiest way to be consistent in Tableau Desktop is to choose the Format –> Workbook option.  Then, change the ‘All’ (first option) to Calibri.

Appeal

Appeal element deals with user attraction, attention, and engagement. It adds charm to the overall dashboard. If “visualization” is a cake, then “appeal” is its icing! Hence, it is important to add this element to the dashboard and invoke a positive response. This helps build trust with the end user. Having interactivity with the dashboard also adds to the “appeal” element.

Some of the examples for “appeal” are stated below:

• Custom Branding – including organization/team logo and name.
• Having certain custom backgrounds, images, and simple icons

The post Tips & Tricks to Improve your Dashboard Design appeared first on Nightingale.

After realizing my passion for data visualization, I began looking for books and online resources with the goal of building my new career path. It was in the middle of May 2023 when, almost by fate, I found an Instagram post for the DVS mentorship program. Thank you, Instagram algorithm!

At that point, I wasn’t entirely sure about applying, as I had just decided to pursue my new career path, and I didn’t even have a portfolio or a preferred platform. But my curiosity grew bigger, and I began filling out the application. The application form served as an inspiration for me to craft a career roadmap. I mentioned on the form that I wanted a mentor to assist me in achieving three specific goals:

1. Understand my career path.
2. Develop my personal brand.
3. Create visualizations.

Now, looking back on the whole experience, I realize there were several lessons that I took from the mentorship and the first one was before I’d even been accepted to the program:

LESSON 1: It pays to be proactive.

I was certain that I shouldn’t wait to be selected by the DVS team to start working on my goals. And to maximize the benefits of having a mentor, I needed to have some progress to receive feedback. I decided to be proactive.

I started by building my online presence; I experimented with different domain names, and finally, I created my first website to start showcasing my services and portfolio. Additionally, I needed to start creating some visualizations, so I installed Tableau Public and began teaching myself how to use the tool.

And guess what? Just a few days after submitting my application, I received an acceptance message from DVS. I was JOYFUL about this opportunity, but at the same time, a bit NERVOUS because I was about to meet my mentor and speak in a language other than my native tongue.

But all this worry vanished during the first meeting. The cross-continental group was fascinating. My mentor, Dr. Mahadia Tunga, executive director at Tanzania Data Lab, had two mentees: Jasmin König, a doctoral researcher from Germany, and me, an aspiring information designer from Colombia. I really appreciated the diverse perspectives within the group. Our initial meeting served as an introduction, where we discussed our careers, our experiences in the data visualization world, the program goals, and logistics.

LESSON 2: Believe in the process.

Even though I hadn’t yet discussed any technical details with my mentor, I didn’t stop working on my visualizations. I was feeling SKEPTICAL, CRITICAL, and occasionally CONFUSED. (Is this the right career for me? Did I make the correct choice changing careers?) Later, I understood, these emotions are all part of the process, and that’s completely normal.

In our second session, our mentor provided resources and shared her experience, including insights into the Information Is Beautiful Awards judging criteria. One key takeaway was that it’s not just about the beautiful; visualizations need to be clear, impactful, creative, and inclusive. Also, we discussed the importance of considering the cultural and political context, such as the significance of certain colors in different regions.

I continued creating visualizations over the next month, and to my surprise, one of them was selected as the “Visualization of the Day” on Tableau Public. For those unfamiliar, Tableau features a daily selected visualization to highlight work on its platform. When I received the news, I was SHOCKED. I was still trying to understand the workings of Tableau, and just processing all the emotions from the previous month.

LESSON 3: Connect with your community.

Connecting with Tableau’s Datafam Community and participating in different projects provided me with very good resources and support. Special thanks to #VizOfficeHours (Michelle Frayman, Nicole Klassen, and Zak Geis), who have been like additional mentors throughout this journey.

In the third meeting of my DVS mentor group, we agreed to present one of our visualizations for feedback. I presented the Visualization of the Day and received very good recommendations, mainly related to user experience and accessibility.

Feeling more CONFIDENT at this point, I decided to incorporate the feedback into my next visualization. I decided to represent the elements from the last Grand Prix of figure skating as flowers.

LESSON 4: Learn by following your passions. 

If you’re just starting in the world of data visualization, working on projects aligned with your interests can be incredibly motivating. For me, that includes topics like history, social impact, security, science fiction, personal finance, indoor cycling, and figure skating.

When I published the figure staking visualization, something incredible happened. A week later, I was contacted by a strategic communications consultancy in the UK to create a visualization showcasing healthcare issue prioritization across different regions. What made me so HAPPY was that the client referred to my figure skating visualization as a reference.

At this point, I was both ANXIOUS and unprepared. When I set my goals for this mentorship program, the holistic aim was to find a job in data visualization, but I didn’t expect it to happen so soon. The offer wasn’t finalized yet, I shared my proposal with my client and also reached out to my mentor for guidance. She kindly agreed to a session to share her experiences and advice.

We also had a couple of sessions to learn about D3, a tool of mutual interest for the two mentees. In my overall plan, I aimed to learn at least two visualization tools, and D3 was my second choice. I really enjoyed these personalized training sessions with someone experienced in the platform; it really enhanced my understanding.

A few days later, I received an email from the client confirming their interest in working with me based on the proposal I had submitted. I was feeling very ENERGETIC, my first client! I was so THANKFUL for the insights of my last meeting; my mentor shared with us. We discussed the process of acquiring clients, setting clear scopes, and pricing strategies. At the time of this writing I am happy to share that I have successfully completed my first freelance job in data visualization!

BONUS LESSON

I already mentioned that following my passions helped me enormously. It might not work for everyone, but I’ve been working remotely since 2021. I now consider myself a traveler. I find that exploring new places enhances my creativity. And looking at inspiring work from others, I find that creativity distinguishes great visualizations. Looking back at my visualizations takes me on a journey to the places where they were created. 

In conclusion, my four lessons of the DVS mentor experience are: be proactive, believe in the process, connect with your community, and learn by following your passions. I am very HAPPY to have achieved all my goals during the mentorship program. I now know the path I want to follow in my professional life. I have a website, and I am using Twitter to share my creative process evolution. My small portfolio showcases various visualizations, each representing one of my interests.

I am very GRATEFUL for my mentor Mahadia Tunga, and my fellow mentee, Jasmin König, who inspired me to express emotions through my work. And thanks to DVS for this incredible opportunity.

The post Data Dreams Come True: My DVS Mentorship Experience appeared first on Nightingale.

In the realm of data visualization, especially within the field of business analytics, we extensively discuss dashboards and their internal content – encompassing style, design, colors, and chart selection. We are mindful of the product’s audience and use frequency. 

But what a technical specialist should never forget is what the dashboard format needs to be for the client. Because this impacts all the design decisions the developer will have to make.

Will your dashboard be viewed on a mobile device? Will it be displayed on a television in the hallway? Will it be showcased in a vast auditorium during a quarterly meeting? Or will it be printed on a black-and-white printer and handed to the top executive?

Here, the dashboard designer starts to break a sweat…

• What do you mean, black and white printing? The colors won’t be distinguishable!
• What do you mean, a conference hall? We’ll need a huge font size!
• What do you mean, displaying it on a TV in the lobby? But what about my incredibly advanced interactive with built-in mouse-hover tutorials?!

Can you imagine if this information reached the developer at the end of the development process? Someone might have thought it wasn’t important because the product is digital. Yet, the amount of additional work that could land on the developer’s plate is substantial. Or worse yet, the client might simply not use the dashboard later on because, despite containing great information and having a nice design, the product is delivered in an inconvenient  format. And only tech-savvy folks would bother opening it on a computer once a month. Hello, graveyard of dashboards! 

To be mentally prepared for these issues, let’s explore all possible dashboard consumption scenarios and their limitations. Then, let’s consider ways to tailor the dashboard to specific formats.

1. Computer monitor or laptop screen

This is the most common use of dashboards among office workers – after all, they all have workstations or work laptops.

So, the only thing you should worry about here is the variety of screen sizes among employees. Kindly request the system administrators or office equipment specialists to provide you with data about the monitors of your future users. Perhaps the company follows a unified standard, or maybe each department has its own specifics. In any case, you’ll need to test your dashboard for different screen sizes to ensure there are no issues.

2. Smartphone

Here it’s almost like a computer, but with some limitations. Make sure your layout for the phone works optimally, and elements are arranged in order of importance — users might not scroll all the way to the end. 

• Check the screen size: If you know the required format (phone model), that’s great, but it’s still worth testing on other popular models. 
• Interactivity will be limited: Ensure there’s not too much of it, that the buttons are large, and that all the text fits nicely, without getting truncated.
• Fonts are not straightforward: On one hand, we don’t want to strain people’s eyes; on the other hand, text labels might not fit and get cut off or disappear. You’ll need to find a balance. Use concise category names, and abbreviate where you can.

You can read more about dashboards in mobile format in my article Mobile Dashboards: Small Screens, Big Decisions.

3. TV in the lobby

Not all dashboards are created for internal purposes; sometimes, management is eager to showcase their excellent metrics to clients. Consider whether your product is prepared for such presentations and can assist in this regard.

• If possible, find out the monitor screen size and test whether the dashboard looks good at that resolution. Ensure everything is visible and fits neatly.

• It’s important to use large fonts because televisions are rarely viewed up close. Don’t make people squint.

• You might need to set up auto-refresh or clarify which method or software is used for displaying your dashboard to ensure the data is up to date on the screen.

• If a dashboard is designed specifically for a TV and won’t be used elsewhere, consider a more vibrant and captivating design, but please spare us the over-the-top special effects!

• Of course, nobody will be there to guide the casual viewer on how to interpret the data on the screen correctly. Make sure everything is clear to the general audience. Avoid using complex abbreviations and ambiguous variables.

Interactive screens are a different story altogether. Viewers can approach and interact with a touch screen to explore what interests them. Ensure your interface is as simple as possible, so users won’t be confused by unfamiliar symbols and icons. Make sure the dashboard reverts to a default state after a user is done interacting, just in case they wander off without returning to the main screen.

4. Screen in the auditorium

This format differs from TV in that it’s usually viewed by people who are more familiar with the subject. Some level of interactivity is possible here if the presenter desires. You might also introduce the audience to the dashboard’s specifics, explaining how to read it. However, time constraints or limited presentation skills may hinder your ability to do this. It would be great if your dashboard could speak for itself. You also should prepare for the most basic  scenario: your dashboard could be inserted into a presentation as a static image.

Pay attention to the screen size and shape. If the screen or the presentation slides are different dimensions than the dashboard, then your product might not be easily visible, even if you’ve increased font sizes, as mentioned earlier.

Pro hack from my team: If you’re preparing a dashboard for a projector, then can you can, within your BI tool, overlay a white rectangle with 30% transparency on your dashboard. Test if you can still see the content on the dashboard, and adjust the design contrast accordingly. (Don’t forget to remove the rectangle.)

5. E-mail report distribution

Most often, this involves a PDF file sent regularly or under specific conditions to all interested parties. Your audience for this static product could be a large number of people (which you may not know in advance).

Regarding specifics and limitations:

• Interactivity may not be used at all.
• Since the email may be distributed to a large audience, ensure your product is comprehensible without needing separate training.

Yes, your report might be printed – see the next section.

6. Printing in color and black-and-white formats

It’s not always apparent to a developer that their product might be printed on a printer, but many managers, even in our progressive era, still prefer paper. Plus, during meetings, it’s sometimes convenient to make notes on this piece of paper.

What limitations should be considered here?

• Forget about interactivity. If you’ve discovered that printing is common among your audience, ensure that your dashboard remains informative even if there are no buttons. The default view should also be useful to the user since that’s what they’ll likely print most often.
• Consider grayscale. For color printing, this isn’t as critical, but you never know on which printer your dashboard might be printed. Therefore, ensure that the colors in your dashboard have enough contrast to avoid merging into a gray blur when printed in black and white.
• Test paper sizes. Checking the format is relatively simple; most likely, printing will be done on A4 (letter) or A3 (tabloid) paper. 
• Make it self-explanatory. It’s difficult to train people or offer help if they’re stuck when you can’t rely on pop-up interactivity or instruction links. Make sure that the essential data required for dashboard use is explicitly visible on the paper and won’t get lost or trimmed during printing.

7. Newspaper (what?)

Yes, it’s atypical, but some companies still produce internal newspapers on paper, and if your dashboard becomes part of these publications, it’s worth thinking ahead about the format, whether anything needs to be done with the color palette, and whether everything will be described and laid out correctly there. Forget about interactivity; training might be reduced to a few lines of text description. The key is to pay attention to colors and fonts for accessibility and legibility.

8. Printout on the wall (ha! ha!)

Not everyone is into trendy interactive screens or digital walls. Sometimes, your dashboard lives its own life, and that life is full of challenges! Your product might end up being printed on several A4 sheets (yes, indeed) and taped together with tape or pinned to the wall. Mm-m-m-m! The Progress! Should this happen, refer back to all the complexities of large screens and printouts.

To make it easier to see the differences in these options, I’ve compiled them for you in the table below.

What if… you have twins?!

It’s already quite challenging… 

And now let’s consider a situation where the rules of the game become even more complex: A dashboard is needed for two formats at once! And the client is not willing to pay for developing two different dashboards with the same content.

I believe you can easily imagine all these combinations: Mostly, the dashboard is viewed on a computer, but once a week, a printout is taken to the big boss. Or once a quarter, a screenshot is made for the quarterly meeting. And so on…

The caravan moves at the speed of its slowest member, so it’s better to consider all possible limitations in the main product, so as not to create multiple versions. After all, each version will need to be maintained and updated separately, which requires twice as many resources.

In some cases, it really is worth creating two separate dashboards (but remember about their individual maintenance needs). Remember to ask clients about all the ways in which they may plan to use the dashboard you create, and make sure your contract protects your dashboard from incorrect usage.

And if the company uses three types of formats — then I’ll wish you good luck — just consider EVERYTHING.

What formats have I forgotten or not taken into account? Write to me about your complex situations with dashboard consumption!

Editor’s note: The first image in this story is made with Midjourney, using a dashboard by Alex Kolokolov. All other images made with Figma.

The post From Big Screens to Paper Printouts: Adapting Your Dashboard for Different Formats appeared first on Nightingale.

I like taking a critical eye to data visualizations in articles and educational broadcasts: When I examine someone else’s project, I evaluate its strengths, mistakes, and suggest improvements. I call it ‘roasting.’

But once I had a situation where my own intern showed me my own flaws. I can’t say that I enjoyed it, but I believe it was more helpful than a dozen good reviews. It was difficult to accept criticism, but I believe I did so with grace. As a reflection on my sufferings, I will share this story with you!

Although some of these mistakes were minor, the devil is in the details! And now each of these little mistakes hurts my eyes! Ouch!

So, come suffer with me!

Best practice for the late 2010s

Once, in 2019, we were working on a ski resort project, and the goal was to “wow” investors with an advanced interactive dashboard and everything was going according to plan. The investors, however, came from a large fund, and they were big fans and frequent users of dashboards. Instead of PnL spreadsheets, they required an online dashboard.

We accepted the challenge, and made a set of four dashboards, one of which is below:

What do you think the client said? He and his stakeholders were happy and applauded us. 

Then we anonymized the data, swapped out complex tables for simplified visuals, and started showing this to all our clients as a best practice. All of them applauded as well, noting that it is clear that the designer was at work here instead of just having analysts create dull gray bar charts on a white background.

***

Time passed and then one day last year my intern saw this demo-dashboard, and asked, “Who did this?”

She stumbled after I told her I had done it. 

Once she started pointing out all the mistakes, I was silently screaming inside. I wanted to tell her, “Who are you, and how could you criticize me? I’ve been involved in data visualization since you were a child!” …But didn’t! And, trembling, I watched the editing process.

Red marker

The main page began to shine with red lines and notes, which this brave beginner specialist expertly used. What were those notes?

An outdated design.

The scenery in the background is seen through the layouts, and it simply looks really outdated. Mountains? Seriously, boss? Well, at least not a portrait of a beloved cat! 

Uppercase titles.

Nowadays, it is simply considered impolite. Capital letters should only be used for abbreviations, but definitely not in all headings. The dashboard should not “yell” at anyone, even if at that moment I wanted to yell out the window!

Background color for data labels.

It definitely did not help to perceive the data, but only added visual noise. Of course, Tufte’s image immediately popped into my head—and his data-ink ratio!.. It’s nice to mention the masters in lectures, but it’s embarrassing to ignore their advice.

However, that was just the start of my suffering. I’ll try to tell you more about other mistakes because my intern not only criticized but also suggested a new version of the dashboard, changing the elements that you will see below.

Too many millions!

If something can be removed from the dashboard without losing information, it should be removed. In this example, the metrics are duplicated in both the chart title and the legend. Ah, those little things…

Even with a basic table, I made a mistake!

Three important words: pale column headings!

The rule of information levels applies not only to the dashboard as a whole but also to each visual element. Before seeing the bars themselves, the user must understand what these bars are about. And the column headings need to be clear and visible. 

I regularly applied the hierarchy rule to font sizes and to dashboard elements, but somehow didn’t think to apply it to font color saturation.

Refuse the non-standard chart?! Yes!

The ribbon chart for “Income” had no data labels above the “months,” and this alone made the chart less informative. What was happening in the spring and autumn? Did the hotel rooms remain totally empty in April and November, or did they still generate a little income?

Each month was marked with a column, so we didn’t really need a ribbon chart in this case. Our intern decided to use a standard stacked bar chart here. And I was forced to agree that such an unusual and cute ribbon chart is far less effective than the good old bar chart.

Let’s put all the pieces together! Here’s what my dashboard looked like before and after a redesign by my gifted intern! It began to look accurate and understandable. And information was seen much more clearly through my eyes, which were washed with humiliation tears.

Well, after we have redesigned the main page, as Frank Sinatra sang:

“I prayed that she would finish, but she just kept right on” …and she opened the next page.

However, as I watched her critique the following pages, I felt more calm, and my soul was floating along the river of acceptance in the direction of self-improvement.

This is how the “Services” page was redesigned.

Don’t be afraid to make mistakes and update your frameworks

That was definitely a “roasting.”

And I’m sure that more ideas for improvement will come up if I take another look at this dashboard later.

I shared this case with Nightingale editor Jason Forrest, and he said that it is generally a good idea to reevaluate your approaches every two years and update the working framework. For me, it was the first painful experience, but I feel it will not be the last time I will look back and be ashamed of my work.

To experience situations like this, I remember a quote from Nobel laureate Frank Wilczek: “If you don’t make mistakes, you’re not working on hard enough problems. And that’s a mistake.”

I wish you all to make mistakes and solve difficult tasks! All together, by taking on the difficult, failing, gritting our teeth, getting negative feedback, being upset, losing in arguments, and trying again—we are developing the industry!

The post How I Took Off My Dashboard Crown and Admitted My Mistakes appeared first on Nightingale.

So, can we make the data the guiding light it has to be without shining too brightly?  Let’s closely analyze how data is transformed into visuals, which is where I believe the real challenge arises. Unlike earlier automated stages, this step depends on human interpretation to turn pixels into actionable knowledge. It’s where noise peaks and misinterpretation risks are highest, from superfluous graphics and irrelevant metrics to data integrity issues. We also need to keep in mind that from the perspective of informational theory, which studies how to transmit signals efficiently, a dashboard is a communication channel.

Channels, in our case, dashboards, have cognitive limits, however. This limit is believed to be around 120 bits per second, the brain’s max speed of conscious processing of information. Although our brain can process up to 11 million bits, we can only consciously process 120 bits by design. The efficiency of our brains allows us to filter and compress millions of data points to only a fraction of the most critical information, which we can process immediately and consciously.

Additionally, our attention span is measured in seconds, and with the demands of multitasking, meetings, random work chat messages, and calls, the time available to process incoming signals from a digital canvas is decreasing. While our attention span used to be about 21 seconds, now it is closer to eight seconds.

As we process the incoming signals, spending our precious seconds and conscious effort, we can hold only 5-7 information items simultaneously in active memory. So even when there is time and appropriate attention to process the signals from data, these signals must come in small doses. 

Additionally, noise is amplified when there is a significant mismatch between the sender and user in the domain expertise. Managers are typically subject matter experts while analysts are not. If this mismatch is too great, the dashboard can become inherently noisy, rendering valuable information trapped and ineffective. 

Furthermore, the user often must improve their data literacy when it comes to dashboards, learning to navigate dashboards effectively, including utilizing filters and interactive features. 

Turning data into effective signals

Dashboard-ready analytics and metrics

First,  we need to maximize the informational value per visual. To do that, metrics must have three qualities:

1. Be relative or an index compared to a benchmark
2. Be filtered to the dashboard use case 
3. Be set against a comparable benchmark (i.e. plan, budget, and limit). 

Be relative or an index compared to a benchmark

Our understanding of crafting relative metrics for data-driven decisions has advanced significantly in recent decades. Techniques like the balanced scorecard, unit economics, ratios, and contribution analysis share a common thread: they all reveal how one metric relates to another. Consequently, these metrics offer threefold or more informational value for the same user attention time. For instance, a visual showing margin percent proves more insightful to a decision-maker than standalone profit figures. Across various industries, whether ratios, margins, or unit economics, a common pattern emerges—a numerator and a denominator. As these index KPIs evolve, they accumulate even richer insights by tapping into the values of underlying KPIs and their connections to benchmarks.

Be filtered to the dashboard use case

It is not enough to visualize just one base formula. It is better when a range of derivative measures is present for selection; this allows users to choose different aggregation levels and periods without interrupting the analysis flow. Five to 10 derivative formulas should support a single metric. Here, analytics becomes an instrument that maximizes user experience.

Be set against a comparable benchmark

Expected KPI values are essential to the informational value of the whole visual. They provide context even to the person unfamiliar with the subject matter. Benchmarks, plans, or limits usually come from manual analysis done by the managers. In these simple digits, a wealth of research is hidden. A good dashboard must use this wealth to enrich all data with a straightforward method–comparing the current and planned values.   

Resulting in last-mile analytics

I call metrics that have these three characteristics last-mile metrics. These metrics are delivered and handed to the decision-maker the same way a postal package is handed to the recipient on the last mile of delivery. Akin to the product’s journey, from the warehouse shelf to the back of the truck to the customer’s doorstep, data insight traveled from the source database to the data warehouse and finally to the dashboard. This last leg of the delivery process is the most critical both in the supply chain and in data analytics.   

When metrics have these three qualities, the last mile handover is now likely to be successful. 

Data modeling for best filtering and drill-downs

Second, dimension filtering options allow the user to receive more signals.  For this, a data model must be in place. Data models dictate the table structures and their relationships. The most valuable data model schema, in my experience, is the star schema. The star schema uses a central fact table surrounded and supported by a range of dimension tables. Usually, each business process should have its own star. As complexity increases, stars can become constellations.

This approach takes more time to prepare and model than just visualizing a pre-filtered queried table. Still, because it gives the user greater control of how and when to drill down, it alleviates data overload significantly.  With a digital canvas of visuals built on a star schema model, users can slice and dice the same absolute and relationship metrics across all filters.

As the visuals change, their movement captures the brain’s attention without conscious effort.
This changing canvas also allows us to mitigate the cognitive load problem when we show too many visuals simultaneously. Hence, the user can interact with the channel and request more signs once ready (by choosing filters or pressing buttons). With each interaction, as the canvas becomes a familiar setting of graphs and charts, the variety and volume of visuals can increase gradually without causing a data overload.

Data visualizations maximize the use of the user’s attention.

Third, data visualization principles must play two critical functions per informational theory. First, the visual hierarchy should control which signals (or visuals) will be noticed first and last. 

The pre-attentive attributes of color and size best create a visual hierarchy. Research studies have shown that the brain can process visual information, including color, in as little as 13 milliseconds. Visualizations that are larger and with greater color contrast will get the first milliseconds of attention. The visual system will scan for the next largest and contrasting object as it takes in information. More important signals are placed from the top left to bottom right (when users read from left to right).

Why should there be a difference in the order in which we need the information processed? As we know, the capacity of short-term memory is limited. Hence, the signal sender should not show too many visuals with equal importance simultaneously.

The second function of data visualization principles is to minimize noise. From the perspective of informational theory, noise is unwanted variations or disturbances that can corrupt or interfere with the accurate transmission or reception of information. In our communication system, noise has many ways to introduce itself:

1. Visual noise: Visual clutter is elements that do not add any informational value or distract from the intended message. It could be excessive use of colors, icons, or graphical elements that do not contribute to conveying the relevant message.
2. Data Noise: Data noise is inaccuracies, inconsistencies, or irrelevant data points that can confuse or mislead the user. The sender can introduce this noise even with error-free data if he lacks the domain knowledge to design visuals as signals.
3. Interface Noise: Interface noise refers to design or usability issues that hinder the user’s ability to interact with the canvas effectively. This could include confusing layouts, unclear labels, or intuitive navigation, making it difficult for the user to access and interpret the messages.

One of the effective ways to decrease clutter is to use Gestalt principles. There are four principles: Proximity, Similarity, Continuity, and Closure. Their use makes it easier to delete unnecessary lines, group similar items without using pixels to highlight the grouping, and reduce compleх shapes to their essential forms. Less unnecessary clutter means less noise without compromising the intended message. Using Gestalt principles to minimize noise, we use the existing universal encoding mechanism of the mind to eliminate unnecessary pixels, increasing the pixel-to-data ratio.

UX/UI design principles to customize the design to the use cases

One dashboard cannot send all of the messages, and trying to put all the information on a single canvas can overwhelm the user. Collecting interrelated dashboards and reports can solve this problem and provide insights in manageable doses. In essence, by creating a system of dashboards, we are increasing the channel’s capacity to transmit signals to each user. Each canvas communicates fewer signals, but the user can request more signals once his mind processes the first batch. The user can request more signals through interactive elements such as page transitions, buttons, pop-ups, and drill-downs.

We also can tailor each canvas to the use case of the receiver. The channels’ capacity depends on the use case. The user or receiver could be a busy CEO with 5 minutes to get the most important signals. Such use cases require specific visuals highlighting the current state versus the target. Or the user could be a middle manager tasked with looking deeper into the causes of the recent underperformance of an indicator. In this use case, we can use a table with many filters. Another sometimes overlooked channel is the mobile use case. A simple picture of key metric visuals sent regularly to a group chat of executives and managers can do wonders in terms of sending signals as fast as possible.

Conclusion

The data overload highlighted in the Oracle report can be addressed more effectively if we treat dashboards as communication channels. Here’s how:

• Establish a shared knowledge base between the sender and the user.
• Enable interactive dimensional filtering with star data models.
• Transform KPIs into relative forms by comparing them with expected values.
• Implement an organized system of dashboards with user-friendly navigation.
• Utilize pre-attentive attributes to establish a visual hierarchy.
• Reduce visual clutter using Gestalt principles.

Footnotes

[1] Csikszentmihalyi, Mihaly (1990). Flow: The Psychology of Optimal Experience.

This article was edited by Catherine Ramsdell.

The post Making Dashboards Optimal for Human Brain Processing appeared first on Nightingale.

For me, that means finding creative ways to weave together numbers, charts, and context in a meaningful narrative to help someone understand or communicate a complex topic. 

But I don’t think we all mean the same thing when we use the phrase “data storytelling” — particularly across data visualization creators and our clients, whether we’re in formal consulting roles or supporting an internal team. There’s a demand for data stories even when the team’s analytical needs aren’t demanding narratives.

Over the past year, I’ve observed a spike in blog posts, eLearning courses, workshops, and more, all promising to teach you the secrets of great data storytelling. These are absolutely worthwhile skills to learn. I’ve also seen an increase in demands from clients in my own work around more data storytelling — using those specific words.

How did we get to this peak demand for data storytelling? Why might we want to probe a bit deeper around what someone means when they talk about doing MORE data storytelling, where perhaps the analytical goals are more around story-finding than storytelling? And how might a more nuanced shared language about our analytical products help designers and users alike?

This article is for the dashboard designers tasked with more data storytelling (even when the goal is exploration), the language enthusiasts who are curious how words and phrases evolve, and the data visualization experts who love to get in the weeds of “how we got here.” 

Let’s dive in, and meander towards the questions to ask when we start a new project in this era of excitement for data storytelling.

A decade+ of data storytelling

The enthusiasm for data storytelling isn’t new. 

Go back a decade, and there’s a rich discussion and debate among people recognized as leading voices in the field (Robert Kosara, Lynn Cherny, Moritz Stefaner, Alberto Cairo, and others) about the role of storytelling, narrative, and “punchlines” in data visualization. Dated April 6, 2013, Mortiz Stefaner writes: “Storytelling has been one of the big buzzwords in data visualization the last year.” 

One of the most commonly mentioned “storytelling” books in analytics is Cole Nussbaumer Knaflic’s Storytelling With Data, first released in 2015. Five years later, Brent Dykes authored a masterclass on blending data and narrative in “Effective Data Storytelling” published in 2020. 

But numbers don’t lie: Data storytelling is popping up across social posts, blogs, and client requests today at a frequency unmatched in previous years — and you can see the climb in the Google search trends over the last decade both in the US and worldwide.

Industry analysts also agree that data storytelling is having a moment. Let’s take a peek into reports from a leader in creating reports in the world of analytics: Gartner.  

If you know Gartner and work in data viz and business intelligence, you likely know the Magic Quadrant reports, which position different tools based on completeness of vision and ability to execute. A second group of reports worth your time are the hype cycles for different segments of the tech industry including analytics and business intelligence. Hype cycle graphics (and their very lengthy associated reports, which you can access through a partner vendor or as a paying Gartner subscriber) have five key phases over the long arc of time, as shown below. Importantly, they’re written with Gartner clients (often not technologists by trade) who want to make informed decisions on where to invest resources.

In the early climb up the curve, early adopters in the industry begin to experiment with a technology or practice. Then, at the “peak of inflated expectations,” there’s all-out fervor about the new approach, after which it slides into the “trough of disillusionment” before leveling out in the “plateau of productivity” with stable adoption and use of the technology or tactic.

For Gartner, data storytelling “combines interactive data visualization with narrative techniques to deliver insights in compelling, easily assimilated forms. Analytic data stories aim to prompt discussion and collaborative decision making.” Since 2019, data storytelling has moved through the “peak of inflated expectations,” with an estimated plateau of productivity in two to five years. In 2022, the topic was coasting towards the “trough of disillusionment” (which is perhaps where I am personally in my relationship with the phrase!). 

The rise in interest has come with increased client demands for data storytelling, which brings us back to our original question: Do we all mean the same thing when we ask analysts and designers to do more data storytelling?

Aligning on what we mean by “data storytelling”

In the world of data visualization, we often conceptualize the graphics we create along continuums. Static or interactive. Conceptual or quantitative. Digital or physical. And perhaps most often: designed to enable the user to explore or to explain an analysis finding.

Having a shared language to talk about the kinds of analytical and communication products we’re creating is powerful, and plays out across other kinds of data visualizations. What is a set of interactive charts displayed on one page and designed to explore data? Many people would call that a dashboard. 

Having a term to describe that deliverable helps us envision the same end when we create workplans, collaborate on teams, or hire consultants to build something. While your more narrow requirements for a dashboard may vary, if I ask a group of data visualization designers to sketch a picture of a data dashboard, I’d expect some consistency.

Data storytelling can take many paths and present across many analytical products. Some stories may be more expository in nature, stating facts, while others take a clear narrative arc. Given these different interpretations, we have to be careful and explicit when we use the words “data storytelling.”

Robert Kosara’s definition of a data story from those conversations nearly a decade ago is still one of my favorites and most succinct. A data story…

• ties facts together: there is a reason why this particular collection of facts is in this story, and the story gives you that reason
• provides a narrative path through those facts: guides the viewer/reader through the world, rather than just throwing them in there
• presents a particular interpretation of those facts: a story is always a particular path through a world, so it favors one way of seeing things over all others

The three-pronged definition allow for space to craft both short and long stories. And it’s the last point that aligns so clearly with the declutter-and-focus recommendations of modern data visualization and data journalism.

If we’re tasked with data storytelling, we also have to think about scale. The demand could be for very short stories. We can take the same data (here, sample data on cervical cancer screening coverage), and shape the story with the headline and our design decisions:

Being enthusiastic about sharing a more complete picture, we can also seek out additional context, research, and data to tell a more complete story. 

In the below example, additional text annotations and highlighted timeframes clue the reader into the narrative. Between the descriptive title, the helpful callouts with key bolded words, and design choices including the background color and marked data points, there’s a natural progression—or short story arc—for the reader to follow. (I’ll note that these strategies run counter to my public health training where we titled charts with the indicator, location, period, etc. represented in the data).

But is your analytical product really a ‘data story’?

Words and phrases, like “data storytelling” create opportunities for alignment between clients/users/readers and data visualization designers. When the world is demanding and promoting data storytelling in all cases, it can feel a bit like having a hammer and seeing every data communication challenge as a nail.

I don’t want to squash the enthusiasm for data storytelling. Well crafted data stories can encourage and spark excitement for engaging with data in amazing ways. But I’m also perpetually frustrated by the insistence that every analytical product be designed for data storytelling and the seemingly-endless loop of realigning expectations.

Josh Smith, a folklorist-turned-UXer and former Tableau Visionary, won a spot on the Iron Viz stage with a long format scrollytelling dashboard on farming. Storytelling was on the judging matrix, but Smith argued in an introspective piece, “Is Your Data Story Actually a Story?”, that his submission wasn’t an excellent piece of storytelling: no cast of characters, no clear narrative.

Instead, he points out that “storytelling is often used as a blanket statement to describe how well the information is presented in an interpretable presentation with a logical flow.” Storytelling isn’t always the goal, especially on dashboards designed more for exploration, rather than explanation. Or, designed more for story-finding than storytelling.

Thinking back to our cervical cancer screening data, the single chart with its headline and annotations give me a snapshot of the data. But what if we want to explore and slice the data by location, age, race, or other meaningful disaggregate? What if we want to know which groups saw the biggest drop in screenings during the pandemic?

Then we need a different tool — something interactive to drill into the available data. That’s where a dashboard can help, enabling you to explore and find the stories in the data. The often data dense displays that we see on highly effective dashboards aren’t designed to export beautifully into a slide deck, but they can be great for identifying trends, outliers, causes for celebration, and data points of concern. 

The role of data storytelling in modern analytics

Gartner’s advice: “Task members of your analytics team with investigating data storytelling as an extension to their use of interactive visual exploration and analytic dashboarding. This will provide a richer delivery of information by adding narrative and context.”

As data visualization creators, aligning with our clients and end users at the requirements stage or when you’re setting up your design brief is a critical part of the creation process. Next time a conversation opens with, “We need to do more data storytelling!” probe to understand more:

• Why does the client want to do more storytelling with data?
• Who are they looking to develop analytical products for?
• What is their vision for delivering on data storytelling, and is “storytelling” really their catch-all word for a well-structured analysis product?
• Should the product you build be designed for storytelling or is the goal exploration and  story-finding, as a first step on the path towards more data storytelling? 

Data storytelling is here to stay. In fact, it probably predates many of our careers and will outlive any of us (perhaps with a bit of AI enablement added on). The conversation around data storytelling extends beyond our niche data viz community and is a fun and seemingly simple concept to get excited about, expanding the enthusiasm and the (inflated) expectations. 

Let’s make sure we’re crafting a shared language and set of intentions, particularly with our clients and end users, rather than jumping on the storytelling bandwagon. Because not every piece of data needs to be communicated as a story—sometimes we need to start with story-finding or just a well structured chart, rather than a full narrative arc.

This essay was adapted from the discussion on Chart Chat (July 2023), a monthly livestream hosted by Steve Wexler, Jeff Shaffer, Andy Cotgreave, and Amanda Makulec. You can find past episodes on chartchat.live.

The post Has Data Storytelling Reached Its Peak? appeared first on Nightingale.

You may have thought this was an excerpt from a cookbook, but it’s actually a data visualization article! It seems like a prank, right? But no.

Sometimes, spaghetti sneaks onto a dashboard and creates total chaos—splattering everything in tomato sauce, popping up from everywhere, and interfering with data!

How did we end up in this situation? Let me explain from the beginning.

We had a fantastic client—incredibly wonderful—who fulfilled all commitments without delay, proactively negotiated everything, and was open to constructive discussions. The project progressed rapidly, the dashboards shined brightly, and the payments were made on time! A true gem of a client! I was ready to introduce him to my mother.

But then we faced the challenge. “Can you display the dynamics for all my parameters on this line-chart? There might be up to 10 parameters! It’s crucial!” he said.

We designed layouts according to the agreed-upon requirements, and the result was a series of charts that looked like a plate of spaghetti.

The dashboard was a tangled heap of lines and numbers that looked delicious to eat, but impossible to mentally untangle.

The client firmly refused to change the visualization type; spaghetti suited him perfectly. “And, by the way, add trends for each parameter!” he requested. The dashboard started to resemble a sticky, stringy Japanese dish called “natto,” as the addition of more lines created an even greater gastronomical tangle.

But why is this visualization type problematic, you may ask?

Too many elements prevent a person from focusing on data. Our brain can’t handle more than 5 to 7 items at once. Such a colorful display distracts readers from data analysis. So, if you search for advice on working with line charts, you’ll likely come across some strict rules: “Don’t include more than 3 to 5 lines!” and “Avoid cluttering the graph and increasing cognitive load!” However, those advisors don’t tell you what to do when the “spaghetti” has already attacked and the number of lines can’t be reduced.

Let me tell you about the options (or recipes) that we, as a team, discussed and considered for improving this case.

Recipe 1: Highlighted Spaghetti

Here’s a simple tip to reduce color diversity: Emphasize the main element and dim the rest. This is easy to do with a static graph.

For a dynamic dashboard you also could click on a specific data line, the other’s colors are dimmed, and only the selected one is highlighted. Easy and powerful option.

Recipe 2: Untangled Spaghetti

Instead of one tangled diagram, present multiple small ones where each noodle is represented individually. This way, you could still conveniently compare the data and examine them separately. This useful method is called “sparkline.” 

Edward Tufte, who popularized this method, wrote about it here: Sparkline theory and practice.

One of the drawbacks is that the number of diagrams required to show all the data may not fit on the dashboard, and it’s not always convenient to compare them if they are not placed in a single row.

Recipe 3: Average Noodles

The compromising method involves showing several main lines while aggregating the rest of the data into an “average” representation. Additionally, we can outline a “range” of maximum and minimum values. This approach is interesting, but we still need to choose one main line.

A downside is that we may miss out on other data points beyond the primary one and potentially overlook anomalies or correlations.

Recipe 4: Filter, not stir!

When we have the option to filter the lines in various ways, it can improve the situation. For instance, we can showcase the “Top 5” or “Bottom 5” lines. Alternatively, we can allow users to manually filter parameters to reduce the number of elements as needed.

This method can be combined with the highlighted spaghetti recipe, where we either hide the unselected data or dim it (turning it into shades of gray).

When we tried to implement this recipe, we came up with several layout options, including the one below:

Recipe 5: Lazy Noodles

This recipe is a subtype of the filtered spaghetti recipe, with a dash of human psychology. (Spoiler: We ultimately chose this method.)

We couldn’t convince the client to abandon the idea of displaying multiple lines on the chart, but we set an acceptable number by default. Now, if the client really, really needed more lines, he could add them easily.

However, he would only do so in case of a real need because the human brain is quite lazy by nature. That’s why default values represent the most popular and commonly used ones! 

And here’s the latest iteration!

This is the solution we settled on with the client when we transitioned from prototypes to working in the BI package. However, we made a more compact default version, considering that the client can add more lines if desired, and it should still work effectively.

The interesting thing is that the client changed his mind about viewing trendlines. Nevertheless, the dashboard still allowed for displaying not just two but up to ten lines! We’re still waiting for feedback from the client to see how often he uses the full-plate-of-pasta functionality!

Let’s add some ingredients to the spaghetti!

What other techniques and tricks can be used to improve the taste? We used a few to make the spaghetti more yummy while dealing with a large number of lines, because we couldn’t get rid of them entirely.

First sauce — with olives, er, labels!

Add category labels to data points at the beginning and/or at the end of the chart lines; this way, you won’t have to spend time referring to the legend. If the lines overlap and the labels do too, place one label at the beginning of the line and another one at the end.

Second sauce — with persistence!

Make filters compelling for action so that users don’t forget to filter the chart appropriately before working with it and trying to analyze it! To achieve this, put the filter names in an imperative mood and highlight them with bright colors, bold fonts, and a larger font size.

Third sauce — with explanation!

To ensure users fully understand how to navigate through this complex visualization, you can add interactive pop-up instructions. Explain and demonstrate the importance of filtering and highlighting what is shown on the dashboard. This way, users can easily orient themselves in this tangled story (yes, it’s a reference to Rapunzel!).

Every client and every task is different, and sometimes it’s worth working within the rigid frameworks that exist and doing everything possible to improve the client’s user experience!

Sometimes, to defeat the ‘spaghetti,’ you have to think like a chef!

Surprisingly, even the ‘spaghetti diagram’ (which visualizes how systems flow) finds its application in the field of lean manufacturing. You can read about spaghetti diagrams here and here.

So, this is our story! Even a small task can lead to numerous unconventional reflections and experiments because we can’t always simply abandon the complex path – in our case, we couldn’t change the visualization type or reduce the number of lines.

I believe it’s not worth prohibiting certain visualizations (like the universal disdain for pie charts, just because they are often misused) or rejecting a visual if it has some limitations. It’s essential to think and carefully assess all possibilities! I think that in such reflections, breakthrough ideas and interesting concepts can emerge! So, I wish everyone challenging data visualization tasks and intriguing solutions!

And, of course, don’t hesitate to share your data visualization struggles, along with your solutions, amid the conflicting demands of clients. Real-life cases teach us much more than theoretical recommendations.

How did you overcome the ‘spaghetti,’ and what interesting dishes did you create based on it?

The post When Charts Looks Like Spaghetti, Try These Saucy Solutions appeared first on Nightingale.

“Create a dashboard for internal analysts on the media buying team to use to determine which ads are the most successful.”

“Create a journalistic style piece that balances text and visualization to tell the story of the impact of Tony nominations on a Broadway show’s longevity.” 

However, these kinds of specifications are generally less defined when creating visualizations for fun, or for contests, or for a client who has given more open-ended guidelines. If no audience is defined, do you aim to serve as wide an audience as possible? Or choose for yourself who your intended audience is? Do you narrow in on one question, or allow the user to explore and develop their own insights? 

There is no right answer to any of these questions, which—while part of the fun—can make it challenging to find a starting point or direction. 

When the contest opened for the World Data Visualization Prize in December 2022—a dataviz competition run by Information Is Beautiful in partnership with the World Government Summit—I immediately knew I wanted to enter the “Dashboard of the Present Future” category using Svelte and D3.js, my current favorite visualization tools. I always enjoy entering contests because they provide a deadline and limit my ability to entirely overthink.

There was a dataset of more than 30 metrics for each country with the goal for “governments to see how well they, their nation, and their populace are doing.” This provided a loose boundary to work within. However, the prompt of, “What seems relevant or interesting to you?” reiterated that I had total control in choosing the focus. This prompt also served as a gentle reminder to get outside of my traditional way of thinking. However, these are the challenges I love the most because, selfishly, I can try new things and organize the data however I see fit.

The contest description also suggested that I “get into the head of a decision maker.” While it was helpful to know that someone would hypothetically use my creation to make informed decisions, it also left out what types of decisions or in what context the decisions would be made. A president of a country would be making different decisions than the head of a government agency or a worker within an agency, for example. My first reaction to this line of thinking was that the user would need to have a starting point—a specific country they wanted to evaluate. No matter their position or goal, each decision maker had that in common. 

However, I also began to question if that was too specific or isolating. Realistically, this was for a contest where the judges were data visualization experts and not government decision makers. What starting point would benefit them? The country they lived in, or one they were considering visiting? Would it be more natural and intuitive for them to start with a visualization that showcased the whole world and then be able to drill down into a region, and then country? I wanted to keep this broader data visualization community in mind as I figured out my visualization.

Wireframing layout options

After reading through the prompts, I went on a run. I had a podcast playing, but quickly realized I was not listening to a single word and was instead arranging the data into different layouts in my head. When I returned home, I quickly sketched out the different layouts I had envisioned.

Here is a gallery of three of those sketches that illustrate the evolution of my thought process:

I realized that I wanted to further explore layout option 1 because it seemed the most concise and dashboard-like. Additionally, I worried if I layered in a “world” visualization and then a “region” visualization, it would be too repetitive and overwhelming. So, instead of adding these larger geographies as their own steps, I incorporated them into a country’s view.

I also began to think further of ways this layout could satisfy my key audiences—government officials (hypothetically) and the data viz expert judges (in reality). How could I make my visualization focus on one thing at a time while also facilitating exploration so a user could find interesting points to focus on? I thought about this through the idea of context and comparisons. If I took the approach of looking at a single country, how would the user determine what was good or bad? Additionally, if the country were deemed “bad” at something, government officials may want a sense for where to turn for advice. Could this visualization show countries that performed comparatively better? Before making any further decisions, I began analyzing the data to see what it would tell me. As someone who lives in the United States, I imagined myself as a government decision maker to determine what information was most useful to generate action or provide a starting point for further research.

Analyzing the data

I started by looking at a single metric—extreme poverty—and saw how it differed by geography. This immediately helped me realize that viewing data at a regional level would add a layer of context. From the view of the United States government, I did not think it would be helpful to say, “Yeah, we are good because less than 1% of the U.S. population lives in extreme poverty while Zimbabwe’s stands at 13.5%” Instead, a more helpful comparisons would be to see that the United States is only slightly better than Mexico and is actually worse than some other countries in the Americas. 

Next, I looked at CO2 equivalent emissions (also known as CO2e) per capita. Knowing that more industrialized, wealthy countries historically produce more emissions, I wanted to find a way to bring income level in. It is helpful in some contexts to see the United States is one of the worst in the world. However, from a decision making perspective, being able to isolate countries with similar resources and see which have lower emissions could be a useful guide for policymakers who are focused on climate policies or technologies.

My last step in the analysis process was to view all metrics pertaining to the United States. I determined the country’s percentile for each metric. This view seemed helpful because the viewer could clearly see where the United States was falling short and where it was doing well. This helped me verify that I could categorize the metrics as “doing well” or  “opportunity for improvement.”

As I was analyzing the data I realized there were limitations of my own knowledge that could prevent me from accurately understanding or displaying a metric. Was I overlooking some obvious reason why a country was better or worse? Was not weighting by population the wrong strategy? I didn’t want this to hold me back or prevent me from continuing on, but I wanted to make sure everything was as accurate as possible. I went to the source of each metric and read the formal definition (which I then captured to include in my visualization) to ease my worries.

Selecting visualizations

With my layout in mind, and using region and income level metrics to play around, I began focusing on which visualizations to choose. I pretty quickly landed on the idea of using a radial with one spoke for each metric. However, I knew for the radial to be effective, I would need to minimize the number of points on each spoke. I also knew that radials weren’t a common dashboard visualization—instead, one would opt for standard dot plot grids—but I was set on making it work because it gave me the ability to sort and layer in a donut chart on the outside.

My initial thought was the user could choose between two views:

1. World view: for each metric, see the average of each of the six regions or the average of each of the three income levels.

2. Country view: for each metric, choose a country and compare it to countries sharing its income level, region, or the world.

But I struggled with the world view. On the country view, the focus was very clear and each country could be highlighted (and designed) differently than what it was being compared to. However, on the world view, it would be hard for the user to make a holistic assessment of the metric. And despite only having three dots per spoke to simplify the view, it still was a lot of information to take in!

Once I made the low income and middle income circles smaller and the same color, the high income circles popped more.

This solidified my theory that the user should choose one thing to focus on: one country, one region, or one income level.

I returned to my usual running grounds in Central Park and began thinking through how I would turn my ideas into a higher fidelity mockup. I realized that I was overcomplicating things by having the user make a lot of decisions and I needed to simplify (much like my favorite activity is just to run and not have to constantly decide where, what pace, how long, etc.). I wanted there to be no sorting or no choosing between rank versus average versus median. Just choose the focus and go. My hope was that this would make it feel more approachable.

I still wanted there to be the ability to dive deeper—if one chose to. So, I created the ability to click on a single metric and view it for all countries. Whichever countries were part of the “focus” would then also be highlighted to allow users to see outliers or gaps.

Adding interactivity

I still felt like something was missing. How was the user to choose which thing to focus on? Given that this was a dashboard, I wanted the experience to be highly interactive. I already had a dropdown to choose the country, income level, or region to be the focus, but this didn’t feel like enough. The user still had to know what to find in the dropdown. This was sufficient for government officials who wanted to look at themselves, but it wasn’t as useful for general exploration.

My first thought was to use tooltips to switch the focus from one type of comparison to another (for example, the United States could switch to a regional comparison of the Americas or an income comparison for high-income countries). If the user found an interesting data point, for instance, they could hover over it and have the ability to change the whole dashboard to focus on that metric. This allowed for on-the-fly exploration. If a government official were looking at their country and wanted to expand to their broader region or income level, they could. However, this still required the user to engage, interact, and be happy with the default selection.

A shuffle button to bring it all together

To address this problem, I considered a shuffle button. As I was looking for inspiration, I stumbled upon The Climate Pledge. They have a shuffle button written into one of the main headers of the page. My first reaction was to click on it and find out what it did. It instantly clicked that this was a way for people to use my dashboard in a fun, intriguing way that still offered a lot of potential for exploration.

I thought the usefulness of the shuffle button was two-fold. First, it allowed for exploration of the entire dataset. Most of the time when given options to choose, people will choose what is familiar to them, such as where they live or like to visit. However, a shuffle button opens up ways to learn about new countries or regions outside of what is known to them. This could be used to offer new perspectives to government officials, but more importantly, it makes the dashboard more exciting, digestible, and usable for those outside of government or decision making roles.

Would a shuffle button ever be seen in a business dashboard? Probably not. However, finding solutions for a wide audience opens up the opportunity to explore new ways of interacting with data that meet a variety of needs.

Personally, I was very happy with what I created (check out my final project here) and I enjoyed experimenting with taking risks by adding a not-so-common dashboard feature. As I was finalizing development and looking for bugs, I found myself continually hitting the shuffle button. I was so fascinated each time the new data transitioned in and I learned about a different place, that I was digesting the information and diving deeper instead of looking at it from a testing perspective. I had spent weeks analyzing and looking at the data and yet I was still able to find insights I hadn’t seen before! Business dashboards are often crafted with speed-to-insight in mind, however creating this visualization helped me realize slowing down and adding engaging ways to “play” with the data can also aid insight.

The post Finding The Right Elements For an Award-Winning Dashboard appeared first on Nightingale.

Rams describes product design as the total configuration of a product: form, color, material, and construction, which I believe is very similar to things you should pay attention to when designing a dashboard. If you want people to actually use and get value from your dashboard, remember Ram’s words: “Good design is as little design as possible.”

For me that’s what the art of design is all about—it’s basically eliminating the need for a user manual. That means removing all the clutter and noise. You only have a few seconds to grab the user’s attention and inform them of what the product can do for them. So the choices you make when putting it together—whether an appliance or a business dashboard—they do matter.

When Rams set out to write up his ideas around what qualifies as good design, those principles were never meant to be absolute. I believe when he put them into words they were always meant to be updated, but personally I don’t think they have. I believe the times we live in now are very similar to when he wrote them initially. In a world where everything is moving so fast, we are increasingly getting rid of excess and visual clutter, and that’s why I believe his principles (with some fine-tuning) are still very much relevant today.

Here are Rams’s 10 principles of design, and my thoughts on how they apply to dashboards, adapted from my 2021 presentation on the subject, which is available to watch on YouTube.

1. Good design is innovative

Design shouldn’t create novelty just for the sake of it, but to improve the functionality of a product. And while technology certainly plays a role in that, I don’t believe it’s technology alone that drives innovation in how we design better business dashboards. 

We tend to get lost in trying out all the new features of our just-launched BI tool simply to create the next thing. But at the end of the day, those new things don’t always serve your users or give them a better experience; so in that sense they become redundant and almost irrelevant.

My advice here would be to stick to the core functionality of your BI tool, and always test the new and improved version of your dashboard against the simpler one to see if your new solution doesn’t add too much complexity for your audience. In my experience, most of the time the new features are about solving a technical problem for the developer but don’t always keep the user experience in mind.

So how do you innovate without cluttering? It’s usually the simple things that are the most impactful. It could be something as simple as more effective chart headers to guide your user instead of complex overlays to explain how to navigate your dashboard.

2. Good design makes a product useful

A highly functional product ignores anything that doesn’t serve a purpose and works against that product’s own usefulness.

When I think about how this translates to the design of a business dashboard, I think about how you can optimize its utility. And by that, I mean not adding anything that doesn’t serve a real purpose. Make your dashboard easy for your users to interact with so that they’ll actually remember  the experience and want to come back. If the first time they interact with your product they don’t derive immediate value from the experience, you’ve completely missed the mark.

3. Good design is aesthetic

And I’m not talking about making things “pretty” here.

The aesthetic quality of a product (and, by extension, its fascination) plays a role in how we perceive something to be useful or not. And while you could argue that this is very much subjective, it doesn’t take a genius to appreciate that a dashboard that is overcrowded and confusing is going to get onto people’s nerves and not hold their attention for the time that we need it to to be able to draw them in. 

You want to cut down on the cognitive load by being purposeful in your choice of visual elements like colour and fonts. Don’t go for what’s cool and new, but be neutral and focused instead.

4. Good design makes a product understandable

This is where we get into how design can clarify the structure of a product. Good design makes it self-explanatory. 

When I think about putting together a dashboard, I spend a considerable amount of time thinking through the structure and how I’m going to lay out all of the different pieces so that it becomes almost self-explanatory and I don’t need to write detailed instructions for how the user should interact with the dashboard to gain the desired insights. 

Read more in Nightingale: Honing Your Skills in Data Visualization as a Designer

The choices that you make should all be aimed at limiting your user’s frustration so that they can actually enjoy the experience and come back for more. 

And this is how you drive enablement, by the way, by making it easy and seamless for your user to understand the WIFM, or “What’s in It For Me.”

5. Good design is unobtrusive

Being unobtrusive means not attracting attention to yourself in the sense that your dashboards shouldn’t be decorative objects or works of art; they should leave ample space for the user to explore. 

When I think about how the unobtrusive principle translates to the business dashboard design, I consider strategies like leaving sufficient white space so users can explore without getting overwhelmed by redundant details. 

6. Good design is honest

Meaning, it doesn’t mislead the user into thinking a product is something that it’s not; it should not attempt to try and manipulate or deceive.

A dashboard shouldn’t lie in the sense that we, as designers, shouldn’t manipulate certain elements so the visual better fits our narrative. Also, think about how you can add sufficient context so your user is clear on what they are viewing and trust the data they are processing.

If you’re in the business of visualising data, I’m sure you can come up with plenty of examples of what not to do, like cutting off the vertical axis on your bar chart, for example, or writing a chart headline that doesn’t support the data.

7. Good design is long-lasting

I think there are different ways of interpreting this principle. In the world of product design it is more about creating something long lasting versus trendy and fashionable—something that will stand the test of time. 

We should treat dashboards more like products. A lot of the time we tend to create things that serve a singular purpose and then someone else comes along and creates a slightly different version, and then again, and again. This is how we end up with a lot of clutter when we could have easily designed a single product had we invested more time in the scoping of the initial dashboard design. One key to making a dashboard that lasts is to involve all the different stakeholders in the process. 

8. Good design is thorough down to the last detail

I really like the explanation from Rams’s book, Less But Better, so I’m going to quote directly from it:.

“Thoroughness and accuracy in design are expressions of respect—for the product and its functions as well as the user.”

Don’t leave things to chance, but think through how all the choices you’re making about your dashboard design will help the user have a better experience. At the end of the day, it’s really about them and not about you.

9. Good design is environmentally friendly

You could ask yourself, what does the design of digital products have to do with the environment? It may not be as obvious as the whole print-versus-digital discussion, but there are things you can do when designing to reduce your digital carbon footprint. 

I know a lot of people (including myself, until recently) may not be aware of this, but the transfer of data actually requires electricity which in turn creates carbon emissions which impacts our environment. According to an article on digital sustainability (which I recommend you check out), the internet is responsible for 3.5% of CO2 emissions per year, which equals the number for the airline industry. 

By being mindful about things like where you store your data and using more weightless content (meaning less images, icons, video content, etc.), you can make a real impact.

10. Good design is as little design as possible

It’s less, but better.

A well designed dashboard lets your users focus on what’s important by cutting out all the non-essentials. It’s something people actually want to use and see more of. I very much believe that one good design can drive engagement for the other content you’ll be creating, so being thoughtful can really make a difference with driving overall engagement.

For more inspiration and resources on all things Dieter Rams, check out this list of resources I curated as I was doing my research to prepare for my initial talk that inspired me to write this article.

The post How Dieter Rams’s Design Principles Apply to Dashboard Design appeared first on Nightingale.

Since you decided to read this article, you probably already know what a bullet graph is, but, if you don’t, here’s a good introduction and a simple diagram of how one works:

The main purpose of a bullet graph is to help dashboard users figure out how they should feel about a given value on a dashboard. Should they be pleased with that value or concerned about it? Or is it in a normal range, requiring no attention? By comparing the end of the central bar with the Poor, Satisfactory, and Good shaded areas behind the bar, users can answer those basic questions for all the metrics on a dashboard:

Adding this contextual information to metrics on a dashboard is important—perhaps even essential—because, for most metrics, users don’t have enough background knowledge to know whether they should consider the metric’s current value to be good or bad. A user might have enough background knowledge to evaluate some of the metrics on a dashboard, but the others will be largely meaningless numbers without the context that bullet graphs provide.

Bullet graphs were invented by Stephen Few in 2005 and I clearly remember the first time I saw one in one of Steve’s workshops in 2013. It blew me away. So much information… in such a small space! Unsurprisingly, they’ve become quite popular since.

I ended up being fortunate enough to teach Steve’s courses from 2014 until Steve retired from teaching in 2019, at which point I started developing my own courses. While teaching Steve’s Information Dashboard Design course, I taught many data professionals about bullet graphs. After a while, though, both workshop participants and I started to notice that they had a fair number of downsides (bullet graphs, not workshop participants ). When I sat down and listed them all, I realized that bullet graphs had at least 11 significant downsides (see list below), and I began to wonder if there might be an alternative.

After futzing around with a variety of concepts, I ended up with an alternative that I call “action dots” that, I think, doesn’t have any of the downsides of bullet graphs. Here’s the same sample CEO dashboard using action dots instead of bullet graphs:

The color of each action dot is determined based on four threshold values that must be set for each metric on the dashboard:

The four thresholds are probably self-explanatory, but here’s a more detailed description if you want to know more.

What, exactly, are the 11 downsides of bullet graphs that I think action dots avoid? You can probably spot several already based on the sample dashboards above, but let’s step through them one at a time, beginning with the fact that…

1. Bullet graphs don’t make problematic metrics “pop out” so they can be easy to miss.

Have a look at the bullet graph version of the CEO dashboard above and try to quickly spot which metrics require attention (i.e., are in the Poor range). Sure, you can do it, but it probably felt slow and effortful.

The underlying problem is that a bullet graph with a current value that’s in the Satisfactory range still has a lot going on visually, since it always shows all three background shaded areas, even though that metric requires no attention. This makes it hard for metrics that actually do require attention to stand out in the crowd, increasing the risk that dashboard users will fail to notice those problematic metrics. This is why dashboard designers often feel the need to add alert icons to bullet graphs with values that are in the “Poor” range, i.e., to make sure that dashboard users actually notice those problematic values:

Now, try to spot the metrics that require attention in the action dot version of the same dashboard:

On dashboards with action dots, problematic metrics “pop out” because metrics that don’t require attention don’t have any alert indicator graphics at all (no shaded areas, no dots, etc.), so they don’t visually compete with metrics that do require attention. Action dots essentially are alert icons, just a much more informative version than simple “flag if poor” icons.

2. Bullet graphs don’t show crises.

Have a look at the two bullet graphs below. Which one looks like it requires attention more urgently?

While both metrics are performing poorly, it looks like Net Burn Rate requires attention more urgently because its central bar is deeper in the “Poor” range. As it turns out, though, we don’t consider Net Burn Rate to be in crisis unless it drops below four months, so its current value of eight months requires some kind of action, but it’s certainly not a crisis. For Working Capital, though, anything below $4M is a crisis, so its current value of $3.7M is a massive problem that requires immediate action. The bullet graphs, however, made it look like Net Burn Rate required attention more urgently than Working Capital. The underlying problem here is that the “crisis” point for a metric can be anywhere in the “Poor” range, but, in a bullet graph, the crisis point isn’t shown.

In a bullet graph, then, it’s difficult or impossible to tell the difference between a metric that’s “a little worse than Satisfactory” and a metric that’s an all-hands-on-deck crisis that requires immediate action. Ultimately, this makes it difficult or impossible for dashboard users to figure out which metrics to focus on first when multiple metrics are in the “Poor” range on a dashboard of bullet graphs.

Similarly, bullet graphs make it difficult or impossible to tell the difference between metrics that are doing “a little better than Satisfactory” and metrics that are knocking it completely out of the park because the “knocking it out of the park” point could be anywhere in the “Good” range.

Action dots, on the other hand, make crises very noticeable (dark red dots), and crises are visually distinct from metrics that are just bad enough to require some kind of action (light red dots). Metrics that are doing just well enough to require action (light green dots) also look different from those that are knocking it out of the park (dark green dots). Ultimately, this allows users to zero in on the metrics on a dashboard that require attention most urgently much more quickly and reliably.

3. Bullet graphs have a bit of a learning curve.

Most audiences won’t immediately grasp how to read a bullet graph and will require some training. That certainly isn’t a dealbreaker and there are plenty of other useful chart types that also require training to read (scatter plots, histograms, etc.), but, as a general rule, the less training that a chart type requires, the better.

Action dots, on the other hand, require essentially zero training. When presented with a dashboard with action dots, most audiences will (correctly) guess that red dots are bad, dark red dots are worse, green dots are good, dark green dots are better, and metrics with no dot probably don’t require attention. They may have questions about how the dot colors were determined, but users won’t require much training to learn how to read them, if any.

4. Dashboards of bullet graphs are a bit slow to visually scan.

Even when the user knows how to read a bullet graph, the central bar in each bullet graph must be compared with its three background shaded areas, one bullet graph at a time, to determine how much attention that metric requires. Yes, this only takes about a second for each bullet graph, but those seconds add up on dashboards with many bullet graphs, especially when each bullet graph has different “Good/Satisfactory/Poor” ranges, which is the case for the second and third columns in my sample CEO dashboard:

Reading the color of an action dot requires considerably less time than comparing a bar with three shaded background ranges, allowing an entire dashboard of action dots to be scanned in as little as one second.

5. Dashboards of bullet graphs can be visually busy.

There are a lot of graphical elements in a bullet graph: The three shaded areas, the quantitative scale, and maybe a “target” or “previous period” marker or two. On a dashboard with many bullet graphs on it, that many graphical elements can be a bit overwhelming.

Dashboards with action dots contain far fewer graphical elements and so they aren’t as visually overwhelming. This also means that more metrics can be included on a dashboard before it starts to look like “too much.”

6. Bullet graphs don’t work well with sets of metrics that aren’t directly comparable.

A stack of bullet graphs is basically an enhanced bar chart, allowing the user to quickly compare the current values of a set of metrics by comparing the lengths of their bars:

This works fine as long as the metrics in a stack of bullet graphs are all directly comparable. That’s the case for the first two columns of bullet graphs on my sample CEO dashboard, but have a closer look at the third column of bullet graphs. That column consists of a variety of different KPIs that should not be directly compared with one another, e.g., the value for Defect Rate should not be directly compared with the value for Return Rate:

The whole point of a bar chart is to allow values to be compared with one another based on bar lengths, though, so using a bar chart (i.e., a stack of bullet graphs) to show a set of values that should not be directly compared can be confusing and may even cause dashboard users to come to nonsensical conclusions about the data.

The obvious solution would be to not show bars for sets of values that aren’t directly comparable and just show those values as a list. We can’t do that with bullet graphs, though, since the bars must be shown in order to show the background range in which the current value falls.

Action dots, on the other hand, don’t require bars to be shown for sets of metrics that aren’t directly comparable:

7. Bullet graphs get more complicated when higher numbers are LESS desirable.

For many metrics, higher numbers are more desirable (Revenue, Employee Satisfaction, etc.), but, for some metrics, lower numbers are more desirable (Accident Rate, Expenses, etc.). The standard bullet graph design doesn’t work for these metrics, because, if the metric’s value increases, it would look like it’s improving when it’s actually getting worse. The standard bullet graph design must be adapted, then, when showing these “lower is better” metrics, and there are two ways to do this:

Both of these design variants force users to a) notice that the bullet graph in question is different than a standard one, b) figure out what that different design means, and c) “change perceptual gears” when they encounter a flipped bullet graph within a column of standard (non-flipped) bullet graphs. Dashboard users can certainly do these things, but they’re cognitively cumbersome.

When showing action dots for a “lower is better” metric such as Expenses, the order of the four thresholds must also be flipped:

Unlike bullet graphs, though, this flipping is transparent to dashboard users; it happens behind the scenes. From the user’s perspective, all metrics still just get redder as they become more problematic, regardless of whether they’re “higher is better” or “lower is better”. The user doesn’t need to learn a new graph variant or change perceptual gears when they encounter a “lower is better” metric on a dashboard with action dots; they can still just scan for red and green dots.

8. Bullet graphs get more complicated with “Goldilocks” metrics.

Some metrics have an ideal range and drifting either above or below that ideal range is undesirable. For example, we always want “Employee Headcount % Deviation from Plan” to be as close to 0 percent as possible, i.e., we don’t want our organization to have too few employees or too many. I call these kinds of metrics “Goldilocks” metrics since we want the current value to be not too hot and not too cold, juuust right

The standard bullet graph design doesn’t work for Goldilocks metrics, so yet another design variant is needed:

Again, users can read a bullet graph like this, but they have to notice that it’s different, learn how to read it, and change perceptual gears when they encounter it in a stack of standard bullet graphs.

On a dashboard with action dots, the way to determine the dot color for Goldilocks metrics must also be adapted, but, again, this adaptation happens behind the scenes and is transparent to users:

Users can still just scan for red and green dots on the dashboard and don’t need to worry about whether metrics are “higher is better,” “lower is better,” or “Goldilocks.”

9. Bullet graphs get more complicated for “narrow Satisfactory range” metrics.

For some metrics, the Satisfactory range can be very narrow, which can make it difficult to see in which range the end of the central bar falls:

In these situations, yet another bullet graph variant is needed. This variant replaces the bar with a marker symbol, allowing the quantitative scale to start at something other than zero and allowing the Satisfactory range to be wide enough to be clearly visible:

So, users need to learn yet another graph variant and change perceptual gears when they encounter that variant in a stack of standard bullet graphs.

For action dots, the four thresholds can be set very narrowly without requiring a new chart variant:

As usual, users just scan for red and green dots on the dashboard and don’t need to worry about different types of metrics.

The preceding three differences between bullet graphs and action dots explain why the third column in the CEO dashboard is so much easier to read as action dots than as bullet graphs:

In practice, of course, most dashboards contain a mix of different types of metrics, so having a mix of different bullet graph variants on the same dashboard isn’t unusual.

10. Bullet graphs get more complicated when there are several reasons why a metric may require attention.

Say we’re a public company and we want to show our current revenue in a bullet graph on a dashboard. Our current revenue is above our internal target (which is good), but below Wall Street’s expectations (which is bad), and above the previous quarter (which is good). To show all this contextual information in a bullet graph, we’d need to use different marker symbols:

Especially on a dashboard with lots of different measures, having multiple marker symbols could get visually complicated.

With action dots, however, multiple dots can be “stacked” to indicate metrics that require attention for multiple reasons:

Not only is this visually simpler than showing multiple marker symbols, but it also has the added benefit of drawing more visual attention to metrics that require attention for multiple reasons (i.e., that have multiple action dots), which is what we want to happen.

11. The three ranges in bullet graphs are ambiguous.

In bullet graphs, the three shaded areas usually represent “Good,” “Satisfactory,” and “Poor.” You probably haven’t devoted much thought to what these terms actually mean, but it’s worth thinking about them for a moment.

Everyone generally agrees that Good is better than Satisfactory, which, in turn, is better than Poor. At what point, exactly, does a metric cease to be “Satisfactory” and become “Good,” though? Similarly, what, exactly, does “Poor” mean? A minor problem? A crisis? The point at which I lose my bonus? Different people can—and usually will—interpret these terms differently, which can cause obvious problems when it comes to interpreting bullet graphs on a dashboard.

The four thresholds on which action dots are based have specific, unambiguous definitions, which avoid the ambiguity of Good, Satisfactory, and Poor:

• Crisis: The point at which improving this metric would become the user’s top and possibly only priority
• Actionably Bad: Just bad enough that the user would actually do something about this metric
• Actionably Good: Just good enough that the user would actually do something about this metric
• Best Case: The best the user thinks this metric could realistically get

Now, different users may disagree on the point at which a given metric becomes, for example, “Actionably Bad,” but at least they won’t disagree on what “Actionably Bad” actually means, which is an improvement over an ambiguous term like “Poor.”

Do action dots have any DISadvantages compared with bullet graphs?

There are few concerns that people occasionally raise when they see action dots for the first time in my Practical Dashboards course. While I don’t think that these are disadvantages relative to bullet graphs, you can, of course, decide for yourself:

“Action dots don’t communicate as much information as bullet graphs.”

While bullet graphs certainly look more information dense than action dots, I think they actually communicate less information. As we saw earlier, bullet graphs don’t communicate the difference between “a bit worse than satisfactory” and “crisis,” or between “a bit better than satisfactory,” and “knocking it out of the park,” but action dots do communicate that crucial information.

Now, it is true that action dots don’t allow dashboard users to see where the individual thresholds for a metric are, but the question is, does that matter? The main reason to have thresholds in the first place is to determine when to flag metrics that require attention, so users probably won’t need to know exactly what those thresholds are very often. If, for some reason, they do need to see exactly where the thresholds are, they could be shown in an on-demand tooltip, something like this:

Since the actual threshold values probably won’t be needed very often by users, it doesn’t really make sense to clutter up a dashboard by showing them for all metrics all the time, and probably makes more sense to only show them on demand, i.e., as tooltips.

“Action dots don’t show where a metric’s value is within its ‘Satisfactory’ or ‘No action required’ range.”

That’s true, but, again, does that matter? If a metric requires no action, does it really matter where, exactly, it falls within its “No action required” range? If that did matter to a user, it suggests that the “Actionably Bad” and “Actionably Good” thresholds for the metric in question are too far apart and should be narrowed a bit.

If the tooltip solution mentioned above were implemented on a dashboard, users would be able to see where a metric’s current value falls within its “No action required” range by hovering their cursor over it to see a line chart of that metric.

“It’s hard to distinguish between dots with subtly different shades of red or green.”

That’s true, but users don’t need to do that in order for action dots to be useful. The reason why action dots have different shades of red is to allow users to distinguish between minor problems, major problems, and crises. Users don’t need to distinguish between many subtly different shades of red to do that; indeed, action dots work just fine if they only use three or four shades of red and three or four shades of green. In fact, that’s what I recommend in my workshops since additional intermediate color shades add virtually no value.

“Action dots don’t work for users with colorblindness.”

It’s true that people with the most common forms of color vision deficiency (CVD) may have trouble telling red and green apart, which would obviously be a problem for any dashboard that uses red and green indicators. Switching to a CVD-friendly color palette such as orange-blue solves this problem, though, and is generally pretty easy to implement as an optional dashboard setting that can be selected by users with CVD:

“Action dots require four thresholds to be set for each metric, instead of just two for bullet graphs.”

That’s also true, but the four thresholds have specific, unambiguous definitions and more closely resemble how people think about metrics in the real world. That’s probably why, in my experience, users find it easier to choose “Crisis/Actionably Bad/Actionably Good/Best Case” thresholds than to choose “Good/Satisfactory/Poor” ranges.

If you can spot any disadvantages of action dots that I didn’t mention, though, let me know! (Please!) I’m easy to find on Twitter or LinkedIn.

Believe it or not, I think there are still…

A few other advantages of action dots over bullet graphs

Action dots are more compact than bullet graphs, so more metrics can be shown in the same space.

In the sample CEO dashboards above, the “metrics section” (everything except the dashboard title and column headings) of the bullet graph dashboard requires over twice as much space as the metrics section of the action dot version of the same dashboard. This means that, with action dots, roughly twice as many metrics can be shown in the same space without resorting to smaller text sizes.

Action dots are easier to implement.

While tutorials are available for creating bullet graphs in most dashboard software products, they can require some “hacking.” On the other hand, virtually all dashboard software products can be easily configured to conditionally show different colored dots.

Action dots are more versatile.

Action dots can be used with virtually any chart type, not just bar charts:

Using dots for all charts on a dashboard also makes it easy to scan for problems on dashboards that contain different chart types.

Features that bullet graphs and action dots both support

There are some features that both bullet graphs and action dots support equally well and so aren’t advantages for one design or the other:

Showing marker symbols for targets, previous periods, etc.

Both bullet graphs and action dots support adding marker symbols for indicating comparison values like targets, previous periods, etc.:

Now, I should mention that I don’t think that single-value targets are a good idea, and I also think that comparing the current value to a previous period is often misleading. You can, however, include these as marker symbols on either bullet graphs or action dots if you choose to do so.

Showing trends

Both bullet graphs and action dots can be paired with sparklines to show the historical trend of a metric leading up to its current value:

Switching to vertical

Both bullet graphs and action dots can be arranged vertically or horizontally:

Final thoughts

I want to be clear that I’m not suggesting that bullet graphs are a bad chart type or that they’re not useful. They were a huge step forward when Steve invented them. The question that I’ve set out to answer in this article is whether bullet graphs are ever more useful than action dots. I think it’s also important to mention that action dots would never have occurred to me if Steve hadn’t come up with bullet graphs first. The idea of including context for a metric within a small visualization is Steve’s, not mine, and the thinking behind action dots is similar to bullet graphs.

Finally, please pipe up if anything in this article doesn’t jibe with you! Are there any advantages of bullet graphs or disadvantages of action dots that I didn’t mention? Ping me on Twitter or LinkedIn! I’d love to hear any questions or concerns about anything that I’ve written here.

The post Why I Stopped Using Bullet Graphs (and What I Now Use Instead) appeared first on Nightingale.