If there’s a holy grail project for product designers—it entails being able to design something from scratch.
My most recent holy grail project at Drift was also one of the hardest things I’ve tackled this year: reporting.
There are designers who have created entire careers dedicated to the science of creating and curating data visualizations. It’s hard. There are rules that need to be followed and multiple preferences that need to be accommodated.
That being said, I had to learn the things that some careers are built around in less than 2 weeks. And because there are so many nuances to designing a good report, I wanted to summarize the things I learned along the way—and hopefully provide a few shortcuts for other designers. Here we go!
Picking the key metrics is hard. And “key metrics” change depending on who you talk to.
A VP of Sales cares about something totally different than what a BDR or Account Executive cares about.
Let’s take an engagement funnel for example. It may seem straightforward, but there are so many ways to show that data. Should it be daily counts? Cumulative counts? Is it helpful to show a comparison? Or a projection? Overall conversion? Or conversion by steps? If you’re talking to the right mix of people, the answer is Yes. All the above, please.
A VP of Sales needs to see the full context of historical data and projections so she can tell if her team is on track to hit their goal. Whereas a BDR needs to know if she’s hitting her daily number, and wants to see how much activity is occurring day by day.
It’s the same data, but it needs to be organized 2 different ways to actually be considered useful.
One of the biggest mistakes I see teams make (and I’ve made this one before, too) is to build a report around available metrics. I would like to stress how important it is fight this tendency.
If you don’t put in the time to discover, track, and expose the right metrics, the odds are that your report will only be partially useful and therefore only partially adopted.
Takeaway #1: Talk to all the personas who will be looking at a report to understand what they need to learn from the data.
Designing with with real data is the key to picking appropriate graphs
If you only take away one thing from this post, please make it this: designing with real data is so important.
I messed this up on the first iteration of Drift’s Playbook report. Here’s what happened:
I had been designing dashboard cards to display playbook funnel conversion. After 2 days and some light internal testing I came away with a lovely bar graph that had “great colors!” and “looked tight!”
Fast forward 5 days to when those dashboard cards were live in the product and I realized they were absolutely useless.
That’s my co-worker Will. Will is incredibly smart, he’s also a numbers guy. He looks at our engagement funnels and conversion rates. All. Day. Long.
“Designing with real data is imperative to picking appropriate data visualizations.”
Guess who I didn’t get some real data from?
If I had slowed down to talk to Will the Numbers Guy, he would have given a real funnel to consider that when picking a visualization.
This is the super hot bar graph that was actually totally useless because when I was designing I made up the data.
Instead, I had taken a fantastic conversion metric and made it utterly underwhelming by putting it in a bar graph which would end up being more of a sliver, and less of a bar.
Takeaway #2: Designing with real data will help you pick the right data visualizations.
Color theory 101 (AKA learn from others’ mistakes)
I’m writing this post so you don’t have to hunt anyone down for help.
But the person I hunted down to give me info on reporting color theory is Drew Condon.
My biggest concern was making sure I was picking a palette that would look HOT, but not distract from the data. It’s a bit of an art and a science. I knew Drew had spent months picking colors for his last reporting project. So instead of trying to pick them on my own and doing a poor job, I was able to learn from his journey.
Here is what I took away:
You are going to need 2 color palettes: comparative vs. sequential.
For your comparative palette (dog, cat, horse, pig, etc.), pick different hues of similar saturation. Example : Blue, Green, Red.
For your sequential palette (open, click, booked), try to pick a palette that goes from light to dark. It could be one color—Light Blue, Medium Blue, Dark Blue. Or a color fade—Green, Green-Blue, Blue, Blue-Purple, Purple.
Use HCL or HSL color scale. Don’t try to use your brand color.
Use a color scale that will make your reports stand out, but not overwhelm. Stick to middle hues. Avoid pure hues or super light or dark colors when it comes to charts.
For Drift I ended up using the HSL color scale and this cool little tool to curate our colors.
Avoid using your brand color in reports. It might be your first instinct to work that fun bright color into your reports, but fight that urge. Pick colors that are actually appropriate for data visualizations and don’t dilute the impact of your brand color.
Takeaway #3: Colors matter. Pick a palette that won’t distract from your data.
So let’s recap…
- Just because it’s a metric, doesn’t mean it’s useful. Everyone on your team cares about different things, which means your personas probably do too. You need to touch base with each of your personas in order to discover what they care about, and design around those needs.
- Designing with real data is imperative to picking appropriate data visualizations. Remember the Numbers Guys, Will? Always talk to *your* Will and get some real data before you start designing. Otherwise you’ll be redesigning your report as soon as it ships (like I had to do).
- Learn from others’ mistakes. You’ll get much farther if you seek out someone who’s done this before. None of us are any good on our own. When you include your village, you get the best results.
There are SO many more things that could be added to this list. And even 10x more things that I have yet to learn about designing data visualizations.
In the meantime, though , I hope these 3 takeaways are useful for you when you’re faced with the challenge of designing reports.
And if you liked (or didn’t like) this post… or if you have some great data visualization tips, I’d love to hear from you. You can shoot me an email at elyse [at] drift.com.