5 Data Viz Resolutions for 2021
Tidy tooltips, cooler colors, mobile first, and more
In a previous post, I wrote about Gartner’s #2 Data and Analytics Trend of 2020: the decline of the dashboard. Personally, I don’t think dashboards are going away any time soon, but I do think an evolution in how they are approached must happen if we want to slow the spread of death by dashboard.
In 2021, as people focus on increasing adoption of the dashboards they’ve painstakingly created over the past few years, we may see increased focus on pre-planning, clearer organization of information, and more attractive UI/UX.
You, too, can be a part of the Dashboard Revolution! Here are 5 data viz resolutions to level up your data game in 2021:
1. Paying more attention to tooltip formatting.
I’ve been seeing a lot of tooltips like this in production lately. There are 5 super quick and super easy things you can do to improve these in a snap:
- Go “on hover” over “responsive”
- Structure text to be more readable, like a sentence, or at least with cleaner alignment
- Disable the Command Bar
- Better name fields
- Remove extraneous info
You can still read the full article here, with more detail about why I suggest these five.
2. Spending time on better color palettes.
There are a lot of great tips out there on using color effectively in visualizations. One thing I’ve struggled with is even selecting a pleasing palette. Luckily, several quick (and fun) options pop up when you search for “color palette generator” like:
- Canva (to upload a photo and get a matching color palette)
- Viz Palette (specifically built for data visualizations and accessibility)
- Coolors (a super-fast random color scheme generator)
- Colormind (color selection powered by AI)
- and Paletton (which I played with a while back and found so simple, it could be summed up in one graphic)
Find more color resources and best practices in the full article, here.
3. More time on defining requirements and development.
“I am the worst offender of this one.” — Me, just now/last year/and the decade before that
Data visualization is sexy. But the not-so-sexy underpinnings like research, planning, requirements gathering, documentation, testing, and other important steps are often overlooked in development. These steps are standard operating procedure for the age-old software development life cycle (SDLC), but data practitioners in our field don’t always follow this rigor— despite the analytics and dashboarding process having many similar steps and goals as software or product development.
The exact steps that need to be done for your dashboard project can be hard to identify when no standard process specific to dashboarding exists quite yet and with overlapping concepts floating around, like SDLC, systems engineering or systems development life cycle (also called SDLC), technical requirements document (TRD), business technical requirements document (BTRD), user research and/or discovery, functional requirements, non-functional requirements, system requirements, etc.
The so-called data analytics life cycle consists of 6 steps: discovery, data prep, model design, model build, communicating results, and operationalizing (put into production). Others have proposed an 8-step dashboard development life cycle, which seems too many to list in a sentence.
With time, something may crop up as a widely-accepted data/dashboard life cycle methodology, but you’ll be ahead of the curve by starting to think about this as a formal process now, and maybe even starting to implement something along those lines.
Not sure where to start? Check out:
- My original (full article) complete with a data playground depiction, here
- This article and downloadable User Research Guide that highlights how intentional user research is the key to outstanding product design — by RS21
- This Analytics Data Dictionary Template to help you start documenting, culling, and organizing your KPIs now— by BI Brainz, and
- This overview of the different kinds of requirements documents that you might want to consider considering— by Tyler Logtenberg
4. Make it Mobile!
This is another relatively simple act that I’ve found has a high User Brownie Points-to-Level of Effort ratio: making sure that the mobile or tablet views of the dashboard look good and display correctly, even if the dashboard is not designed or intended to be viewed on anything besides a desktop. This may mean that the non-desktop version has its own view entirely, or “disabling” the mobile view and directing a user to instead view on desktop (which I prefer less, but mobile may not be an option for many of these very complex and large dashboards).
An example of my own doing:
The Before picture below is the “default” mobile view that Tableau generated before I created a custom Phone view for it. Even in this small slice of the dashboard’s contents, a title text box was cut off, some text is completely truncated (the notorious “###” when the text is too large for the frame), and data labels are displaying differently for bars in the graph that are long enough to house the data label inside the bar versus those that aren’t.
You can see in the After picture how these same elements looked after I manually modified the Phone view. This included resizing worksheets, lengthening the total height (which makes for more scrolling but less scrunching), and evenly spaced blocks.
There is a time and a place for mobile versions, but it should still always be top-of-mind.
People are paying more and more attention. In fact, when you publish a new workbook to Tableau Server, it now pushes the option to preview it on 3 different devices upon publishing.
And don’t forget about tablets and non-widescreen monitors, or take the “Automatic” layout for granted!
When in doubt, make it mobile. Read more in the full article, here.
5. Clearer naming conventions.
The last resolution in this 2021 kick-off series is about renewing commitment to how we use language in analysis/data storytelling and even in our data viz — particularly when creating titles, field names, and labels.
I didn’t have time to write a short [chart title], so I wrote a long one instead.
If that sounds familiar, then this resolution — and the full article on the dos and don’ts of naming — is for you.
Poor naming conventions lead to more data interpretation fatigue.
Analyst and dashboard developers are so excited (and under the gun) to get the data published reliably and accurately — and to tell the story of their findings — that naming conventions and succinctness are often overlooked or done in haste, resulting in chart titles and field names that are nonsensical, incongruent to the data, raise more questions, or flat-out don’t describe the content and end up causing more work for the viewer to understand and interpret.
Try to remember that our viewers and stakeholders are incredibly overwhelmed, busy, and our analysis or dashboard is one of multiple that they’re charged with not only making sense of, but acting upon. They often don’t have time to re-analyze the information that we were charged with analyzing for them; so I consider it my [our] responsibility to lay the groundwork of understanding and head any confusion off at the pass. Crystal clear naming is one way to help do that.
The less time and thought that it takes my viewer to understand what I’m trying to say, show, or imply, the better.
Who knew that data analysts and dashboard developers were not only expected to create art, but also expected to write clearly and succinctly?
These are just a few ways we can upskill our data game in 2021.
Join me this year as we shift from simply building dashboards to building meaningful, intuitive, and actionable tools and solutions.
Stefany Goradia is VP of Health Analytics at the RS21 Health Lab, and has spent her career on the front lines of healthcare analytics. She writes about how to interpret healthcare data, communicate to stakeholders, and to support informed decision making.
