- SAP Managed Tags:
- Part One - Context
- Part Two - Chart Types
- Part Three - Standardisation
- Part Four - Putting it all Together
Good design means never having to say... "Click Here"
In Part One, we explored the challenges that emerge from a lack of context in your charts and how this affects the insights derived from them. In this upcoming segment, we will shift our attention to the importance of choosing the right charts and tables for effectively building your visual stories.
Dashboard design, as the title suggests, is primarily a scientific discipline rather than a creative endeavour and selecting the right type of chart or table is crucial for maintaining these principles. We do not opt for a heatmap merely due to its absence in our recent work; rather, we select it because it effectively addresses the specific question presented by the business.
To begin, I would like to present a brief quiz that highlights some frequent errors I observe when individuals select arbitrary charts to convey business insights. We will start with one of the most prevalent mistakes in dashboard design, which I encounter frequently.
The first question is: Can anyone identify any issues with one of the two charts displayed below?
Both charts illustrate the composition of a Stock Portfolio by Category, utilizing a straightforward bar chart for the visualization. However, one of these charts is improperly executed - to rephrase the question, what role does colour play in Chart #1? The answer is that it serves no purpose, as the distinct colours assigned to each dimensional value fails to provide any meaningful insight.
Visual perception is highly sensitive to differences, just like all our senses. When we notice a difference, our brains instinctively wonder, "What does this difference signify?" In the context of graphs, if we change colours without a clear purpose, it can lead viewers to overthink and miss the main message. Unfortunately, many software tools make it easy to create random variations in graphs, such as automatically altering bar colours.
While SAP Analytics Cloud allows users to assign different colours to dimensions, doing so here is not suitable, as the colours only distract from the overall message.
Let's look at another example:
What graph type makes it easier to determine the largest share, the pie or the bar?
Developers might assert that "both charts provide the answer"; however, it is crucial to approach this matter with care, as we are developing a narrative to tackle a business question. This question arose during the discovery phase concerning the essential elements for the dashboard. In this case the inquiry specifically asks, "which graph type identifies the largest share," and it is clear that a bar chart is the most suitable option, especially when sorted to showcase the highest value at the top.
The Pie chart serves as a useful tool for comparing a limited number of values, as it clearly shows the size of each segment in relation to the whole. However, its usefulness diminishes when there are many different dimensional values. If you need to use a Pie Chart, I suggest opting for an In-Line legend (see below) that labels the chart directly, rather than relying on a separate legend, which is a common practice among many developers. Personally, I find that answering the exam question "What's the biggest" is more effectively accomplished with a Bar Chart.
Here are some additional examples that highlight why choosing the right chart type is crucial. The question we need to consider is:
"Which chart helps us determine the Total Sales for the Year, the line or area chart?"
When I present the question to a live audience, I often receive responses like "Both the line and area chart work". However, the reality is that neither of these options actually addresses the exam question, which requests "Total Sales for the Year." In the line chart, we can observe total sales broken down by month and region, but the chart does not display the Total Sales figure. To find the Total Sales, we would need to sum the three lines together, and then add up the monthly totals to arrive at the yearly total.
The same applies to the area chart; it doesn't show the yearly totals despite combining the three regions. While it's an improvement, it still doesn't address the business question.
A stacked bar chart would be the right choice here, as it display the sum for the three regions each month, and enables users to drill down by Month, Quarter, Year, etc., effectively answering the business question.
Certain questions lend themselves more effectively to tables rather than charts, and we often have a clear understanding of when to opt for one format over the other. Nevertheless, acknowledging the necessity for a table doesn't always mean we create it flawlessly. Elements such as formatting, embellishments, precision, borders, and font choices play a significant role in the table's clarity.
Check out the two examples below:
Both the data and column positions are the same, but one version is definitely more reader-friendly than the other. If you think the Top Table is the clearer option, you might want to skip the rest of this blog. We’ve eliminated the thick lines, applied the Alternating Row template, selected the appropriate column scales, added conditional formatting, and included Totals to present the data more insightfully. All these adjustments aim to highlight the key insights quickly and effortlessly. However, I would suggest one more tweak: I would eliminate the Yellow RAG status in the first column. I might even think about removing all the Green RAG items too.
I previously pointed out that I believe our dashboards should primarily use just two colours: green to indicate positive outcomes and red to signal negative ones. In the Profit column, the focus is on the one area that requires further scrutiny. However, in the Revenue column, we have three different colours, which creates unnecessary distractions. If everything is fine, that's wonderful - let's keep moving forward - but Red indicates something that requires our immediate attention. An overload of colors can obscure the clarity and insights that a dashboard should provide.
Think about this example:
Does adding more colours enhance or complicate the decision-making process?
I would argue that a lack of colour helps the process of identifying those KPIs that need attention - in this case Abandonment Rates and Rep Utilisation. However, I hear you saying, "My corporate style guide insists on 11 different colors for the dashboard; it's crucial!". The truth is, an overload of colour can hinder insight and make interpretation more difficult. Excessive colour can distract users, so it's best to simplify.
To demonstrate this idea, take a look at the following image:
There’s colour everywhere - at least 10 different hues in this picture (I’ve seen much more chaotic ones). But where does your eye go? What grabs your attention first? The truth is, you can focus on anything because nothing truly stands out from the rest. Now, think about a slightly altered version of the same image:
Where does your gaze land this time? Is it on the traffic light? To put it simply, apply colour where it's essential for the science, not for artistic flair. Use colours judiciously, and as we will explore in Part Three, I just stick to two colors: Red and Green.
We've looked into choosing charts, formatting, and colour usage, but there are more elements to consider for a successful dashboard design. One important aspect to keep in mind is that the dashboard should not lead users to make biased decisions. Although the developer showcases the data, it's crucial for the intended user to interpret it independently, to make well-informed business decisions. Sadly, this isn't always the case.
The chart on the left suggests that most respondents believe their Member of Parliament is performing well. In contrast, the chart on the right presents a different perspective, showing a much narrower difference between those who think the job is good and those who think it is poor. It might surprise you to learn that both charts are based on exactly the same data; the only distinction lies in the Y-Axis scale (did you spot it?). One chart ranges from 2,000 to 2,500, while the other spans from 0 to 2,500.
Altering the scale without a valid reason can create confusion with the chart, making it easy for the viewer to overlook the key insights in the data. I saw a fantastic(ally bad) example of this on Instagram recently.
The Dow Jones appear to 'plummet' just as the owner of the account would have you believe. The actual message was "When Trump said he would lower prices he meant stock prices actually" - now I don't do politics on this platform, but people might see the data and think - that's BAD.
However, the delta between the start of the drop and the last price was less that 0.61% - hardly any movement at all and certainly not the intended message that the poster wanted to convey. Here's the same data plotted in a Numeric Point chart in SAP Analytics Cloud:
However, sometimes we may find it necessary to deviate from these principles. For instance, adjusting the scale or colour can be exactly what we need for a particular purpose.
The page above features four charts that display the top speeds achieved by F1 cars during testing in Bahrain for the 2023 season. The first chart presents the raw data, showcasing top speed by team, organized according to the team dimension. Currently, the top speeds of F1 cars are closely matched, with the fastest vehicles only marginally quicker in a straight line compared to the slowest.
The second chart sorts the data by speed instead of team, highlighting Ferrari as the fastest team at 325 km/h, while Haas lags behind at a leisurely 308 km/h.
In the third chart, I adjusted the axis scale to range from 305 to 325, rather than 0 to 330, to provide a more realistic view of the differences, which I believe is appropriate in this context.
Lastly, the fourth chart features each team's colours for their respective dimensions. Since each F1 team has its unique colour scheme, this choice of colour was a fitting approach for the intended audience, rather than strictly adhering to the one dimension equals one colour rule.
So far we've looked at choosing the correct chart, colours, axis scale & formatting but there are more things to consider here. One important aspect is the orientation of the chart, which follows a straightforward guideline.
Use a horizontal layout for all data types except those related to time or date. For charts displaying time-based dimensions, the orientation should be vertical; otherwise, it remains horizontal. SAP Analytics Cloud simplifies this process by automatically adjusting the orientation to vertical whenever you select a date or time dimension - it's giving you a big hint here, don't change it back just because you can.
The chart above has many problems - only one of which is orientation as the developer has chosen a vertical layout that has had the effect of truncating some of the labels. Non-time dimensions should always be displayed in a horizontal order allowing for labels to be displayed correctly and allowing proper interpretation of the data.
The chart above displays the same data but with the correct orientation, use of colour, formatting, context (the variances), chart type and makes for a much easier interpretation of the underlying data - and what elements the user should focus on for remediation - notably manufacturing.
The chart above effectively illustrates the correct way to orient time-based dimensions. It's essential to keep in mind that time flows from left to right, and all charts should convey information accordingly. Regardless of whether you're using a Line, Column, or Time Series chart, we must always display the data with a vertical orientation that reads from left to right... no exceptions!
I came across the first chart on CNN a while back and thought it was a prime example of terrible design. I mistakenly believed I wouldn't encounter such a poor example again. However, this year, my colleague discovered this gem on Slovenian television, and it features the same glaring mistake - can you spot it?
When we embark on creating a dashboard, it's essential to think about how we present the data in a way that meets the user's needs rather than the developer's. We should reflect on questions like "Is this the most effective way to communicate the information to the business?" It's also important to consider whether our choices might lead the business to make poor or biased decisions. Additionally, does the information provide the necessary context? (Refer to Part One of this series for a discussion on context).
It's important for us to think carefully about each decision we make on the dashboard, including the type of chart we use, providing context, emphasizing performance, eliminating what isn't needed, and ensuring the scale is appropriate. Consistency in these choices is key, so that when users navigate to the next page or story, they won't have to relearn how to understand the information all over again.
I hope this series of musings will equip you with some of the skills to make your dashboards more effective in helping the business achieve their aims - as the title hints at, it's not rocket science, but it is science. Stand by for Part Three where we'll start to look at Standardisation and IBCS in your visual stories.
Happy Story Building
We invite you to deepen your understanding through our upcoming events. Andrew and I are pleased to announce that we will be conducting four public visualization webinars in 2025. Registration links will be made available below and will activate after February 12th. We encourage you to check this page regularly for updates. Please be aware that these links will enable you to indicate your interest in participating, and we will notify you of your acceptance status once registration is open.
- 12th March 2025 - Register your interest here.
- 13th May 2025 - Register your interest here.
- 9th September 2025 - Register your interest here.
- 9th December 2025 - Register your interest here.
Throw your questions and comments below and I'll always attempt to answer them as soon as I can.
Daniel
1 Comment
