• It’s full of terms like “dashboard”, “infographic”, and “data storytelling” that different people use in different ways (heck, experts even disagree on what “data visualization” means…).
• It encompasses a dizzying variety of different types of visuals, from data art, to scientific visualizations, to exploratory analysis tools, to maps, to utilitarian bar and line charts.
• It can be used for an extraordinarily wide variety of purposes, from status monitoring, to persuasion, to humor, to education, to artistic expression, to exploratory data analysis, to awareness-raising and advertising.
• It includes hundreds of different software applications and code libraries, each of which is better or worse suited to creating different types of visuals.
• It includes a wide variety of courses and books, each of which covers different types of visualizations and purposes of data visualization.

So what?

IMHO, this messiness is causing some significant challenges in the field:

• Beginners struggle to figure out which software tools they should learn, which books they should read, or which courses they should take.
• Best practice discussions often devolve into endless debates because practitioners try to agree on universal best practices that apply to all data visualizations without fully appreciating the sheer variety of things that are called “data visualizations” and the completely different purposes that they can serve.
• Often, audiences who need data don’t know what to ask for. A dashboard? An infographic? An analysis report? A table? A graph?
• Practitioners get tasked with creating visualizations that don’t line up with their specific data visualization skills. A practitioner who created a successful viral marketing infographic gets assigned to design the CEO’s dashboard, but then everyone is perplexed when the results are disappointing.

Can we do something about it?

These are the types of challenges that prompted me to start thinking about a “map” of the data visualization field that attempts to bring a bit of order to the chaos; to bring together, in a single graphic…

• All of the terms that tend to come up in conversations about data visualization (“chart”, “dashboard”, “data storytelling”, “infographic”, etc.) and how those terms relate to one another.
• All of the different types of visuals that people call “data visualizations”.
• Examples of data visualization software products and code libraries that are better or worse suited to creating each of the different types of visuals.
• Examples of books and courses that cover each of the different types of visuals.

Yeah, good luck with that.

This is a tall order, I know. We’ll see how well or poorly I did when people start reacting to the first draft of the map on social media…

Most of the heavy lifting that’s required to create a map like this comes down to choosing definitions for terms like “data visualization”, “chart”, “dashboard”, “report”, “data storytelling”, etc. When I brought all of these terms together in a single graphic, though, I found that it was surprisingly clarifying when it came to settling on definitions for them. Most of the attempts to define these terms that I’ve come across in the past define them in isolation, without mentioning how they differ from, overlap with, or are synonymous with other, related terms. Putting all of these terms in the same graphic was very helpful in clarifying exactly how, for example, a “dashboard” differs from a “report” or a “visual data exploration tool” or an “infographic”.

My general approach to definitions has always been to hew as closely as possible to how people tend to use terms in everyday conversation, and this is the approach that I took when defining terms for the map. Many experts don’t use this approach (i.e., they come up with their own definitions that don’t consider how people use terms in everyday conversation), but I think it’s defensible for two reasons:

1. If people tend to use a certain term in a certain way in everyday conversation, there are often (though not always) good reasons why, even though those same people may not be able to articulate those reasons, and they may not be obvious to those of us who spend a lot of time thinking about definitions. People tend to unconsciously gravitate toward whatever works for them and, while that’s not always the truly best solution, it often is—even if we don’t understand why at first. Wisdom of crowds, blah blah blah.
   
2. It imposes less change onto fewer people. Asking a majority of people to stop using a familiar term in one way and to start using it in a different way introduces a lot of friction, and they’ll likely ignore the new definition anyway. Yes, inevitably, some people would have to change their usage in order to get everyone using a term in the same way, but the idea is to choose definitions that minimize the number of people who’d need to do that.

At least a few people are going to disagree with at least a few of these definitions or other aspects of the map, but I think that that’s unavoidable, regardless of which definitions are used. If you’re one of those people or if you have any suggestions on how to improve the map, please tag me on LinkedIn or Twitter and include the hashtag #mapofdataviz in your comment to make sure that it gets seen. I can’t guarantee that your views will be reflected in the map, but I’ll try. If you make a suggestion that gets incorporated into a future revision of the map, I’ll list you on the page where the map is hosted (see below).

Speaking of future revisions, I want to underscore that this version of the map is a draft. I’ve given it a version number of 0.1, and I hope and expect to update it based on reader feedback so please pipe up! In the future, the map will almost certainly evolve as technology and the field itself evolves.

Just show me the damn map!

In order to fit everything into a single graphic, the map had to be a large, high-res image with a lot of small text labels, which means that only the big “region” labels are legible when it’s embedded as an image in a web page. To get around this and to enable readers to browse the map comfortably, I’ve published it on a dedicated site (https://www.mapofdatavisualization.com) with interactive zoom and pan controls:

I’ve also recorded a 36-minute “guided tour” video that provides an overview of the different terms and “regions” in the map. If you’re interested in the map, I strongly recommend that you watch this video, especially if you’re thinking of commenting on it or making suggestions:

Have at it!

The post A Map of Data Visualization (For Discussion!!) appeared first on Nightingale.

The Data Artisan!

The Analytics Translator!

The Data Storyteller!

The Analytics Engineer!

And yet there is a role, a skill set, that appears to have remained undiscovered.

Do you want to make information easier to find and identify insights faster? Do you need to transform screens filled to the brim with data vomit into focused and logical information spaces that are easy to navigate and explore? What about a consistent, shared language — for both visual and text elements — that doesn’t get lost in translation between data visualization consumers and creators?

Well…. you just might need an Information Architect.

Information architecture: a definition

The IA Institute defines information architecture as:

The practice of deciding how to arrange the parts of something to be understandable.

Okay, but what do information architects actually do?

In their foundational book Information Architecture for the World Wide Web, Morville and Rosenfeld define four main components of information architecture:

• Organization systems. How content is grouped. This could be at the information level, such as categories and taxonomies, as well as spatial organization of page elements.
• Navigation systems. Elements and features to help users move around and browse content, such as navigation menus.
• Searching systems. Allow users to find specific content using queries, or reduce the displayed content based on user-selected options.
• Labeling systems. The language used to describe content, content categories, options, and links. Matching the audience’s language requires using familiar language with a shared meaning. It includes both text-based and visual language (such as icons).

Before designing the information architecture (or any of its component systems), the first step is to understand your audience, their tasks, and the their information requirements — the information they need in order to complete their tasks. Based on those you can develop key task flows: the most common sequences or paths users will take to accomplish their tasks.

All of these — audience, tasks, information requirements, and flows — are crucial inputs for the information architecture design process. They can help you create organization, navigation, search, and labeling systems that are both usable and useful to your users.

Information architecture work has tended to be more commonly associated with websites, but it’s just as important for data interfaces. For information spaces, especially complex ones, an effective information architecture can provide the structure users need in order to easily move through that space towards finding the information they seek.

Form may follow function, but neither will be enough without a logical and well-thought-out structure.

Information architecture in dataviz: an illustrated example

One of the most common types of business dashboards also happens to be a great example of ineffective information architecture design in dataviz.

The key performance indicator (KPI) dashboard.

If I asked a bunch of dataviz designers to draw the worst KPI dashboards they’ve encountered, the most common variation would probably look something like this:

This dashboard can easily, non-controversially, be put into the please nope category. It has all The Bad Things. A gauge chart. A stoplight color palette. Even the typography hierarchy could use some major help.

Here’s a different take on the same KPI dashboard.

Most practitioners would agree that this design is much improved. The chart encoding is now optimized to communicate variance from target and the color choice helps direct the eye to periods that were underperforming the target.

But, from an information architecture perspective, these two designs are almost identical. They also cause the same problem.

Because information architecture is so tied to users and their goals, you need to define these first in order to evaluate the information architecture design. In this case, since you don’t have access to ask them directly, you’ll be making some educated guesses about the target audience and their goals. So, let’s say your target user is everyone’s favorite: The Executive Leader.

Using the Questions to be Answered framework, I’ve defined the executive’s primary question as: what areas of my business are underperforming?

The underlying task needed to answer this question would be to identify the KPIs that are not meeting targets. This is a search task, based on a numeric value — the difference between actual performance and target.

Once those KPIs are identified, our users may also want to know: why are these KPIs underperforming? Or more specifically, what are the drivers, impacts, and other context related to my underperforming KPIs?

The information architecture of the two example KPI dashboards is simply not a good fit for the executive’s questions and related tasks.

Why? Let’s take a look at the information architecture design. If you abstract out these two dashboards into wireframes, you can see they have similar information elements, arranged almost identically.

The information architecture within each KPI tile is shockingly similar, despite how different they look. In both designs, each KPI card has these elements:

1. KPI name
2. Details about the KPI (such as date period)
3. Actual value for the current period
4. Comparison between actual and target for current period

The second design includes one additional information element — a trend of the variance to target over the last 12 months.

When you step back from the individual tiles and look at the page-level layout, the IA design is identical. Both use the matrix organizational scheme.

The best and worst thing about this type of organization scheme stems from its very nature. It’s designed specifically for optimizing user choice and freedom.

Outside the dataviz world, you’ve probably encountered this information architecture structure when searching for a product, or even browsing categories, at your favorite online retailer. Search results are often displayed in a matrix structure. For that type of search task, it helps users to have as much choice and control as possible over how search results will be displayed.

In the KPI dashboards, it doesn’t work quite the same way.

It might seem like a great idea to put All The Things on a single one-stop page. But consider how a viewer would visually navigate content that is presented in this way. It creates an experience that’s much closer to reading than seeing.

Wireflows are a useful tool for describing the information architecture of data experiences. By combining wireframes with user flows, the wireflow lets you map the paths both within and between pages.

As with their page layouts, the wireflows are pretty similar for both of the KPI tile dashboards. Below is the wireflow I created for the first design. Looking at the structure and the flow together, it’s easier to understand how users would navigate the content of this page. Of course, not all users would follow the exact same path, but most people from Western cultures would start with the title and subtitle at the top, and then move on to scan each row of KPI tiles.

This type of information architecture can also be described as a flat, single-page structure. The single-page structure means that the user is presented with all the available information in this one place. That’s it. There’s nowhere else to go, no buttons (or charts!) to click for more stuff. Of course, this isn’t always a bad thing.

The flat structure can be a problem, though.

Because there’s no grouping or prioritization among the KPI tiles, they are perceived as equally important and equally (un)related. Presented in the matrix layout, each tile competes for attention equally, making it difficult to know where to look first.

Sure, a motivated user may go on to scan each of the tiles, or even try to find all the red underperforming KPIs. But they would still face the initial confusion and need to invest considerable cognitive effort to complete their task.

And just imagine the case where all KPI’s are missing target. It would be hard to see anything but a sea of red, much less be able to decide which KPI to prioritize.

Ironically, the design principles that this type of KPI dashboard are optimized for — consistency and order, within each tile and between tiles — also exacerbate the weaknesses in the information architecture.

Redesigning the information architecture

Selecting better data encodings, color palettes, and even improving other visual details, will only get you so far in improving the data experience for your users. You’ll be able to make much more impactful changes by focusing on the information architecture first.

So let’s take a look at what an information architecture makeover might look like.

Redesign 1

This first iteration goes from one screen with all the possible KPIs to several screens, each focused on an area of the business.

For the purposes of this fictional example, I included four pages: financial, customer, product, and operations. The financial page (pictured below) is now focused on only three KPIs from the original dashboard. They all relate to top-line financial performance — revenue, orders, and profit.

The KPI cards at the top of the page provide the highest level information needed to answer those key questions I identified earlier:

• Did we meet goal?
• How much did we miss (or exceed) the goal?
• Has this changed over time?

Below that, the regional performance section provides additional context, helping users see if any specific market is driving the top-level performance.

The executive can still review performance for all the most important KPIs, but can now do so in a more structured, focused way. If done well, related KPIs should still be available on the same screen. This approach lets you provide a holistic context-rich view of a business facet or topic, while reducing distraction from less-related KPIs.

This is an example of a broad and shallow (though not completely flat) information architecture.

The wireflow for this first redesign shows how the user could complete their task using the new information architecture.

• Within each page, the user would first look at the performance summary for each KPI, and then may proceed to look at the regional performance below.
• Once satisfied with their understanding of financial performance, they would move on to look at other pages.

Of course, some users may follow a different sequence of page navigation, based on their own personal priorities. That is one of the benefits of this information architecture structure. It provides users flexibility and the ability to more easily locate the KPIs of most interest, while also lending itself to looking at each page sequentially to get a view of all business facets.

This is a type of flow that would work well for a periodic performance review, such as a monthly or quarterly business meeting. Think slide deck. You wouldn’t throw everything on one single slide. So why would you confine all your KPIs to one single screen?

When using this structure, it’s a useful exercise to consider how you would structure the narrative of a slide deck. What would each slide focus on? What order would you present the slides? What would the key takeaway be for each slide? What questions would you anticipate, or what discussion would you like to see around each slide?

Use all of this information to help you categorize your KPIs, and identify the elements needed to provide context for each.

Redesign 2

This second iteration also has multiple screens, but it takes a much different approach, using data-driven navigation to provide depth for a more exploratory experience.

The KPIs are organized into a hierarchy structure, with a focus on product performance. The first page is centered around the highest-level indicators of product performance: revenue and profit. This page is designed to help users identify interesting product categories for further analysis — ones that have either significantly overperformed or underperformed.

Using the scatter plot, users can navigate to the second screen, where they can explore performance for a selected category in more detail.

This second-level, drill-down screen includes additional KPIs, as well as a more detailed granularity. It shows individual products in the selected category and the additional dimension of customer segment.

The KPIs on the left of the page can be scanned to see an overview of product performance for the selected category. Users can also select any of those KPIs to explore the more granular product and customer segment-level performance in the beeswarm plots.

There are many ways to organize a KPI hierarchy. In this example, the KPIs are divided into summary and detail level in terms of lagging and leading indicators. If a drop in sales or profit was the ultimate outcome, what are the underlying changes that may have contributed to those changes in top line performance?

This second design iteration is a good example of a narrow and deep information architecture structure.

This structure still answers those primary questions I identified earlier, but with a different focus and goal — understanding the financial performance of products.

Your slightly narrower, reframed question might be: which product categories are driving growth and which are driving losses? Then you can go deeper to explore why a particular product category might be performing poorly (or performing well).

The wireflow, once again, can help you visualize the flow and structure of the design.

• The first page provides a high-level summary of overall financial performance, as well additional detail of product-centered performance with two levels of categories (the broader categories of furniture, technology, and office supplies, as well as more detailed subcategories within those).
• The navigation between the two pages allows users to move deeper into more details of a selected product category.
• The interactive feature on the second page allows users to zoom into details of a selected KPI within the same page.

Notice that all of the KPIs on the second page were in your initial one-page wall of KPIs. It could be argued that this structure and flow would not be ideal for the executive who wants a quick at-a-glance view of the whole business. And yet, how useful and actionable is that one-page view, when it doesn’t provide much context?

This type of deep navigation structure may not always be the best fit for the executive leader — but it certainly has its use cases. Consider your own data and business goals, and whether it makes sense to organize them into a hierarchical structure of summary and detail KPIs.

When using this structure, sort KPIs based on how zoomed in or zoomed out they are. Then consider, what is the most zoomed-out information, that would still be useful? What is the most zoomed-in level? Also think through the path from the user’s perspective. What is the key question, and what are the likely follow-up, more detailed questions?

You can use all of these to define the scope, content, and structure of each page, and how best to enable moving within and between pages.

Redesign 3

So you really, really need to put it all in one page? Well, you can still optimize the information architecture for that.

First, start with a recap of the key question, and the tasks you are aiming to support with this design:

• Did we meet goal for all our KPIs?
• For each KPI, how much did we miss or exceed the goal?

To support answering those questions, users should be able to quickly and easily complete these tasks:

• See which KPIs are missing target
• Identify the KPIs that are underperforming target the most
• Locate a specific KPI

This third iteration uses a table to structure the content on a single page.

It may not seem like much of a change to simply take the content out of the individual KPI cards and put it all into a table, but it will actually make it a whole lot easier for users to complete those tasks you’ve identified.

First, by sorting the KPIs based on their variance from target, users can now scan the table from the top down and quickly spot the worst performers.

To focus on an individual KPI, users can read across a row and see additional details and context, including a trend of variance to target over the last 12 months. With this structure, you could also provide the ability to navigate to more detailed information for each KPI.

To make it easier to locate a specific KPI, users can select to sort the KPIs alphabetically.

The information architecture structure of this design could be described as a shallow (but not flat!), single-page structure.

The way content is organized on the page, using the table layout as well as sorting, creates a visual hierarchy that enables easier visual navigation within the display.

The wireflow highlights the structure and flow in this single-page design.

This type of information architecture is a great solution for cases when stakeholders insist that everything needs to be on single page. However, its strength really comes from the way it supports comparison and ranking of KPI performance. It’s best used when there’s some standardized reference point to which each KPI’s performance can be compared. This could be a goal, a budget, or even a comparison to some baseline, like growth over previous year.

When using this type of structure, first consider whether it would be meaningful to compare performance among different KPIs. It is certainly a powerful way to provide an overview of overall business performance, and to help users quickly see the areas of their business that are underperforming the most. But it’s crucial to make sure that the comparison measure is meaningful and easy for your users to interpret.

These are just three possible ways to redesign the information architecture of the KPI tile dashboard. These iterations highlight how deeply changing the structure will change the design itself. Each of the three structures provide a completely different task flow within each page and between pages.

It’s often said that great design is invisible. I’d argue that out of the three — structure, function, and form — structure is the least visible.

The more visual elements of your design, such as color, charts, or text, may reveal the contours of the structure. But the structure itself isn’t something you’re likely to notice or think about much, unless (or until!) it’s something you do think about a lot.

And then you see it everywhere.

Ironically, a lack of structure is even easier to see (to the practiced eye).

I started out by talking about the need to hire information architects on your data team. But the truth is, anyone can learn to see more structurally, even architecturally.

Or, as Christina Wodtke so eloquently explains it:

“Information Architecture is a way of thinking for me. It is a way of approaching any problem: thinking about products, making sense of the world around me.”

Want to learn more?

Most writing on information architecture does tend to be focused on more general digital products, so it won’t have much specifics to data visualization design. But these are all excellent resources to help you start thinking and designing with an information architecture perspective.

Articles:

• Information Architecture Basics on usability.gov
• 8 Principles of Information Architecture by Dan Brown
• Architects Everywhere by Jorge Arango
• The Difference Between IA and Navigation by NN group

And some books:

• Information Architecture: For the Web and Beyond by Louis Rosenfeld, Peter Morville, and Jorge Arango
• How to Make Sense of Any Mess by Abby Covert
• Pervasive Information Architecture by Andrea Resmini

The post The Most Important Role You’re Not Hiring for Your Data Team: The Information Architect appeared first on Nightingale.

Looking at the wide range of contemporary board games presented there, I couldn’t help noticing how much board games have in common with data visualizations. In fact, at their core, all board games are data visualizations. Data and information are visualized as pieces of different colors and shapes (called meeples) placed on boards specifying coordinate systems. The rules of the game determine how the current situation of the data can be transformed into a more desirable state.

Board game players are willing to pay 30–50 € for standard games, and well over 100 € for elaborate expert games. Players spend hours and hours poring over these visual representations of data. That is a degree of user engagement that would be great to also achieve for data visualizations.

The good news is that many of the elements that make board games so engaging, fun, and accessible, are equally applicable to data visualizations. In the following, I will discuss a few such points. Board games use easily readable data encodings, use overarching plots and metaphors, have graphic design that fits the topic, and represent the data in physical form.

Board games tend to use easily readable encodings of data. Categorical data is usually encoded via color hue and shape. This goes, for example, for the different kinds of meeples controlled by each player. Numerical data is usually encoded via location among common axis, number of elements, and size of elements. Board games seldom include more difficult to discern encodings like shades of a color hue (light to dark) or orientation. Using them would quickly result in misreadings and confusion.

The table shows the encodings used in traditional and contemporary board games. The game of Go uses the simplest encoding with black and white stones (interpreted as categorical color hues here although factually color shades) placed on a grid (position). Modern games very seldom use further encodings beyond those already used in the game of Monopoly, first patented in 1904.

In data visualization, if the intention is to get information clearly across, easily readable encodings should likewise be used. The experimental encodings of data art play a very important role in extending the boundaries of the genre. But for many, such elaborate encodings pose a barrier to understanding. I personally have to admit to often skipping elaborate data art if it is too tiring to decode.

Board games make use of overarching plots and metaphors to integrate masses of complicated information. Typical settings of board games include medieval trade, fantasy adventure, armed conflict, and science fiction exploration. The setting provides the information encoded on the board with an easy to understand and memorize mental model. Entirely abstract board games are much rarer. Chess is the most popular abstract strategic board game in the western world. In 1924, Bauhaus designer Josef Hartwig created suitable abstract pieces for the game. The forms reflected the movements of the pieces. These did not catch on. Today, chess still uses the metaphor of two armies with knights and bishops maneuvering against each other to kill the other’s king. The human brain craves tangible plots and metaphors.

Over the last few years in data visualization design, there has been a strong trend to move from presenting rational arguments towards telling emotionally involving stories. This was especially initiated by Cole Nussbaumer Knaflic’s 2015 book “Storytelling with Data.” Narratives integrate lots of individual data visualizations into a whole to make a clear point. The narrative also makes individual facts much more memorable. A good story usually consists of a three-part structure with introduction, conflict, and resolution of conflict.

Board game publishers go long ways to make the graphic design fit the topic. Often the general mechanism and layout of board games are designed by one person (the board game designer/author), and the final illustrations done by a professional illustrator, who sometimes remains unnamed. Illustrations, color palettes, and fonts are chosen to reflect the content.

A wide range of illustration styles are used from rational flat infographics to realistic and very artistic styles. Photographs are rarely used as image material in board games. One reason could be that the use of somewhat abstract illustrations and icons makes it easier to remain in a mental state of imagining and abstract reasoning. In Germany, there is even an award solely for the visual design of board games, the Graf Ludo. If something is beautifully designed we are much more willing to invest time understanding and engaging with it.

Data visualizations can equally be made more enjoyable by using a graphic design language that fits the topic. Header fonts can be chosen to go along with the topic. Color schemes can set the general mood of a visualization. Integrated illustrations and icons can serve decorative purposes. Many good examples of this can be found in the Tableau Ironviz qualifier Dashboards (not in the quickly prepared finals).

Part of the fun of playing board games is to have tangible objects before you. The quality of the game material plays a big role in the enjoyment of a game. Usually, cardboard, wood, and plastic are used. It is nice to touch and literally walk around visual representations of information.

Most data visualizations are pure digital products for the screen. But for workshops, showrooms, and conferences it can be worthwhile to bring a visualization into the physical world. A low-level method is to print a (static) data visualization out as a large poster. Today, there are many possibilities of turning digital graphics into physical objects by 3D printing plastic, laser cutting plywood, or laser engraving on plastic, metal, or glass. If one is willing to put in some manual work, the possibilities are endless.

In this article, I have demonstrated how many elements that make board games so engaging can also be applied to data visualizations. The points discussed in this article are the use of easily readable data encodings, the use of overarching plots and metaphors, the use of a fitting graphic design, and the physicalization of the visualization. These are the more static aspects of board games. Further discussions would be warranted for the social aspects, the interactivity (think interface design), and the gratification and rewards integrated in board games (think gamification).

After a long day, I left the board game trade fair with lots of new ideas and inspirations. To me, it is clear that data visualization designers can learn quite a few tricks from board game designers and illustrators. But the inverse also holds true. I’ve seen quite a few board games that could have been improved with basic data visualization know-how. And it makes me think: “How would a board game look that was designed from the ground up by a data visualization designer?”

The post What Board Games Teach Us About Data Visualization appeared first on Nightingale.