Treemaps are a data-visualization technique for large, hierarchical data sets. They capture two types of information in the data: (1) the value of individual data points; (2) the structure of the hierarchy.

Definition: Treemaps are visualizations for hierarchical data. They are made of a series of nested rectangles of sizes proportional to the corresponding data value. A large rectangle represents a branch of a data tree, and it is subdivided into smaller rectangles that represent the size of each node within that branch.

A hierarchy showing four levels of the S&P 500
A hierarchical tree diagram, showing the structure of the S&P 500.  This structure is the basis of the treemap shown below.
Four views of the same S&P 500 treemap, with four levels of the hierarchy of the data set highlighted
FinViz Map of the Market uses a treemap corresponding to the tree structure of the S&P 500 dataset depicted above. The items colored in yellow and marked (A), (B), (C), (D) correspond to the items labeled with those letters in the tree diagram above. (A) represents the entire S&P 500 and is the same as the root of the tree. The rectangle (B) is the Technology sector. Within the Technology sector, a smaller rectangle is Communications Equipment (C). Finally, within the Communications Equipment rectangle, all the smaller rectangles represent individual companies within that sector, such as Cisco Systems (D), Qualcomm, and so on. The color of each rectangle shows if the value of that stock is moving up or down – very bright red indicates a big shift downward, and very bright green indicates a big shift upwards.
Two zoomed in images of a treemap, with the relative sizes of items shown, to compare their quantitative size
The size of each rectangle represents the market capitalization (value) of that stock, industry, or sector. At the lowest level of the hierarchy (individual companies), Google (E) has a larger market cap than Facebook (F), and so their relative rectangles are sized appropriately. One level up in the hierarchy (Industry), the entire Internet Information Providers (G) category is larger than Application Software (H), and their rectangles are appropriately sized to show that differences as well.

Key Uses of Treemaps

Treemaps are commonly found on data dashboards. Designers often choose them to add visual variety on a dense dashboard. However, treemaps are a complex visualization and present many obstacles to quick comprehension (which is the main requirement for any information displayed on a dashboard).

Treemaps are often used for sales data, as they capture relative sizes of data categories, allowing for quick perception of the items that are large contributors to each category. Color can identify items that are underperforming (or overperforming) compared to their siblings from the same category. This is why FinViz’s Map of the Market is an enduring example of treemaps: it allows users to identify companies that are doing better than their industry peers, even though their overall stock value may be quite small.

Treemaps work well when your hierarchical data has 2 main dimensions that you want to visualize:

  1.  A positive quantitative value, which will be expressed as the area of the rectangle (Because area cannot be negative, you cannot use treemaps for visualizing variables like gain/loss, which can have both positive and negative values.)
  2. A categorical or second quantitative value, which will be expressed as the color of the individual rectangles. If color is used to express a quantitative value, it’s strongly encouraged to use only one color (if all the numbers are positive) or two colors (one for negative and one for positive), and vary the intensity of the color to express precise value. As humans don’t perceive colors to have an inherent order, we strongly recommend that you do not use multiple colors to represent a range of numbers.
An overly colorful treemap
An example of poor use of color in a treemap: several different colors are used to show the percentage of the population that is over 65 in various regions of Europe; each color indicates a different percentage range (with blue marking the low ranges, yellow the middle, and red the high). Unfortunately, there is no universal natural mapping that says that blue is less than yellow or than red. Instead, it would have been better if the intensity of single color was used to indicate percentage.

If color represents a categorical variable, it is okay to use different colors for different possible values, as there’s no need for users to interpret a specific color as being “higher” or “lower” than another. However, as with any use of color in a data visualization, restraint in the number of colors is strongly advised!

Regardless of how you use color in a treemap, make the following accessibility accommodations for color-blind users:

  • Avoid using both red and green in the same treemap (especially for values that need to be differentiated quickly).
  • Use color palettes that are safe for color-blind people.
  • Test your design with a tool that allows you to simulate a color-blind user’s experience
  • Use a secondary signal (such as text within the rectangle or appearing on hover) for the data aspect captured through color
A version of the S&P 500 treemap as shown in a color blindness simulator
 (Left) FinViz’s map of the market uses red and green to encode the change in the stock value (green is up and red is down). (Right) The same visualization is shown as perceived by someone with deuteranopia: the red and green colors are hard to distinguish. In this design, some (but not all) rectangles do contain the recommended alternative cue: for example, the AMZN rectangle in the upper middle is annotated with “+1.28%”, which informs users that this stock is up even if they can’t tell that it’s green. (The second image is from a color-blindness simulator).

Here are a few more guidelines for creating usable treemaps:

  • Visually distinct borders around higher-level categories help users identify the top-level groupings.
  • High-contrast text ensures that people can read the labels inside the treemap rectangles.
  • A visually distinctive selected state, reached when users hover (or tap) a rectangle, helps users confirm that they are looking at the right data point.
  • Additional detail about a selected rectangle (appearing in an overlay), such as the name, value of the variables allows users to drill into the data.

 

A hover state with a clear border and popup window with additional details
A good example of using a visually distinct border around a selected section of the FinViz treemap, along with additional details about the sector in a popup window.

Treemaps’ Downsides

Comparisons Are Difficult

Human brains are able to process certain visual information preattentively: attributes such as length can be grasped quickly and accurately, and values for such attributes can be compared with almost no cognitive effort. Unfortunately, area is not one of these preattentive attributes. Treemaps rely on area (and possibly color) to encode the value of a variable, and therefore, although treemaps can convey overall relationships in a large data set, they are not suited for tasks involving precise comparisons.

A dashboard that includes a treemap.
This dashboard includes a treemap that shows the production levels for various products produced in four factories. Color is used to designate the different factories and size is used to show the production outputs. While this visualization compresses a lot of data into a small space, the information it conveys efficiently is very high-level — for example, it’s easy to identify the top performers in each category. However, it is difficult and time-consuming to determine the top five overall performers. A bar chart would communicate this information more accurately and more quickly than the treemap.
A dashboard treemap zoomed in to show the very similar area of two regions. This is an example of how treemaps are poor tools for precise comparisons, due to the visual similarity.
Zoomed-in view of the dashboard image above: Which is larger, (A) or (B)? Since this visualization uses area to communicate the size of the variable, it does not easily allow for specific comparisons between items. Making this comparison requires hovering over a section, waiting for a tooltip with that value to appear, and then keeping that information in one’s short-term memory while repeating the same process on the other section.

Inefficient for Data that Is Not Hierarchical

Treemaps should not be used if your data is not hierarchical: in those situations, they are functionally equivalent with a pie chart — simply showing a parts-to-whole relationship. (Pie charts are not great visualizations either — like treemaps, they are based on area and angle, attributes that are not preattentive. They should be used only to communicate that one or two items are much larger than the rest, and not for comparing relative sizes of the pie slices.)

Visually Overwhelming

Treemaps are often used to visualize very large data sets, with hundreds or thousands of items. This quantity of information can visually overwhelm users — the treemap becomes a sea of tiny rectangles, many too small to bear a text label. Furthermore, in complex treemaps, the overall hierarchy can easily become undiscernible. The solution is a cushion treemap, which uses texture to make each rectangle look “raised” in the center like a cushion and tapering off to the edges. This visual effect takes advantage of humans’ tendency to interpret this type of shading as a raised surface, making it faster to identify the different rectangles.

A "cushion" treemap, used to help users see rectangles more easily.
In a cushion treemap each rectangle has a slight gradient from the edges to the center. This effect helps to visually identify small items as well as larger categories comprised of several rectangles.

Not for Balanced Trees

Treemaps are also poor choices for data sets with items close in size (i.e., balanced trees). In these cases, the main purpose of a treemap (quickly identifying the largest items in a given category) becomes very difficult. Finally, the standard algorithm used to create a treemap attempts to make the rectangles as square as possible, in order to make size comparisons slightly easier and less error-prone. However, in interactive visualizations where change is shown over time, an artifact of this algorithm is that the rectangles may move around as their size changes. As a result, keeping track of a particular item over time becomes very difficult.

Alternatives to Treemaps

In many cases, treemaps can be replaced with bar charts (for data that have one quantitative and one categorical variable) or scatter plots (for data with two quantitative variables) that represent the variables of interest.

This process, however, requires an understanding of your users’ top tasks; for executives attempting to identify the products that have both a high sales volume and a large profit margin in order to advertise them most aggressively, a 2D scatterplot would be better than a treemap. But if the user cares primarily about the overall sales, a sorted bar chart is a better choice than a treemap. (Sorting is often underappreciated, but is one of the simplest ways of making it easy to identify those items with the biggest and smallest values.)

Scatterplot showing three variables.
A scatterplot is often a better choice than a treemap for visualizing data with 2 quantitative variables, as the human visual system can quickly and accurately detect 2D position. This scatterplot also adds a third, categorical variable, expressed in color.

Summary

While treemaps can be useful for visualizing certain types of complex, hierarchical data sets, they often hard to interpret. If using a treemap, visually separate the different high-level categories, avoid using multiple colors to express numeric values, and design with color-blind users in mind. Last and foremost, understand what your users need to do with your data and consider whether other visualizations (such as a bar chart or a scatter plot) could replace or augment the treemap.

References

Ben Shneiderman: “Tree visualization with tree-maps: 2-d space-filling approach,” ACM Transactions on Graphics, 11,1, 92-99. (1992)

 

Jarke J. van Wijk and Huub van de Wetering: “Cushion Treemaps: Visualization of Hierarchical Information,” IEEE Symposium on Information Visualization (INFOVIS’99), San Francisco, (October 25-26, 1999)