Welcome to Storytelling with Data, the podcast where listeners around the world learn to
be better storytellers and presenters with best-selling author, speaker, and workshop
guru, Cole Nisbaumar-Nafley.
We'll cover a wide range of topics that will help you effectively show and tell your data
stories.
So get ready to separate yourself from the mess of 3D exploding pie charts and deliver
knockout presentations.
And with that, here's Cole.
Hi, this is Cole.
Thanks for joining me here on the Storytelling with Data podcast.
So I was encountering this situation this morning and actually anyone who has kids or
has spent time with kids can probably relate to this where you get the same question over
and over and over and over.
So this was happening this morning.
I was getting a little bit frustrated.
But then I stepped back and I was realizing, "Hey, wait.
I used to do this exact same thing when you really want something and you're maybe not
getting the answer that you're hoping for.
Sometimes we ask again and again and again in hopes that the answer will change, right?
That we'll be eventually able to get the answer that we want."
And there's one particular interaction that I can recall with my parents.
And it sounded something like this, "Hey, mom, can I get a kitten?"
No.
Okay.
That was not the answer I was looking for.
Oh, I have an idea.
"Hey, dad, could I please get a cat?"
Go ask your mother.
Okay.
That didn't work.
"Wait a bit.
Try again.
Hey, mom, could I please have a kitten?
Maybe when you're older."
Okay.
Well, that wasn't a direct no.
Wait a little bit.
Try one more time.
"Hey, mom, can I please have a cat?"
We'll see.
Ah.
Like me, that sounded pretty much like the green light to go for it.
And so I bought a kitten for $5 at a garage sale and took it home to see if my mom would
make me take it back.
She didn't.
I got to keep it.
I bring this up because I've observed this same phenomenon when I teach, where workshop
participants will ask the same question multiple times and from different angles, perhaps
in hopes that the answer will change.
This seems that people would prefer to have strict rules for visualizing and communicating
with data.
You should always do this, or you should never do that.
It turns out, though, that it's usually more nuanced than that.
And actually, the answer to many questions raised in this space is nearly always the
same.
It depends.
So today, we're going to discuss 10 common questions raised related to visualizing and
telling stories with data that can be answered by those same two words.
It depends.
And talk about exactly what it depends on, and the things you should be taking into account,
the considerations you should be making, and the critical thinking process that will position
you for success when communicating with data.
Question one.
What type of graph should I use?
Well, it depends.
For me, the thing it depends on first and foremost is, what do we want to allow our
audience to do with the data that we show them?
And oftentimes, this means iterating and looking at the data one way and looking at it another
way to try to find that magical, the one that'll help us create that magical aha moment of
understanding that graphs done well can do.
Now, when it comes to use cases for different types of graphs, if you're showing data
over time, oftentimes, a line graph will work well.
Or if you have data that is categorical, a bar chart may be a good choice.
And actually, there are a lot of different types of bar charts, and the two I use most
common are vertical bar chart and horizontal bar chart.
And for me, the most common reason I switch between a vertical and a horizontal is simply
to get some more real estate if I have long category names to be able to write those in
a way that's going to be accessible to our audience.
And one thing to keep in mind when you're figuring out which view of the data is going
to work best for your given situation, for your given audience, is recognize that the
view that you used to create that moment of understanding for yourself as part of the
analysis is not necessarily the same view that's going to help you create that moment
of understanding in your audience.
And so oftentimes, this means giving yourself time and looking at different views of the
data to try to find the one that's going to work best for your data, for your situation,
for what you want your audience to see and to know.
And if you're unsure, there's an easy way to test this, which is create your visual
and hand it to a friend or colleague and have them talk you through their thought process.
What they pay attention to, what questions they have, what observations they make, all
of these can be really useful for figuring out whether the visual you've created is serving
its intended purpose, or if it isn't, give you pointers on where to concentrate your
iterations.
So what type of graph should I use?
The one that's going to be easiest for your audience to see what you want to show.
Let's talk, though, about a specific type of graph and a question related to it.
Should I use a pie chart?
Well, it depends.
That might be a surprising answer from me, as I've had talks before called "death to
pie charts" and have a well-documented disdain, you could say, for this type of graph.
Does that mean you never should use one?
No.
So I don't typically use them because in cases where I would maybe reach for a pie, I'll
often reach for something else instead.
But I've softened my views on pies over the years for sure.
When you title a talk called "death to pie charts," sometimes it's just fun to be a
little provocative.
But part of my softening over time was actually some new studies that came out in 2016 by
Robert Kosara and Drew Scowl that actually disproved some of the things that had previously
been held as common knowledge on how people read pies and what sort of tasks are easier
or more difficult with pies compared to some other graph types.
And what they showed is actually that a pie chart is probably the best visual for showing
that one piece of the hole is really small or another piece of the hole is really big.
For me, the challenge is they break down pretty quickly if you want to say much more nuanced
than that.
Because as soon as the segments approach similarity of size, it becomes really hard for us to
wrap our head around how to compare those values.
So our eyes just aren't great at measuring areas, which is what we're asking our audience
to do when we show them data in a pie.
Now does that mean we should never use a pie chart?
No.
Not necessarily.
John Schwabish had a good post from a couple of weeks ago talking about a case where he
said, "You know what?
I'm going to throw caution to the wind and I normally maybe wouldn't use a pie chart,
but I'm going to use a pie chart in this given situation."
And the situation was one where he was considering his audience, he was considering his data
and what he wanted to show and had looked into some alternates and realized actually
a pie chart works for what I need here.
It's not a scary graph type, right?
I'm not going to put off my audience by using it.
And for the message I need to get across, it does a fine job of that.
So I'll make sure I link to these studies and posts that I'm mentioning here in the
show notes, but definitely recommend giving them a read.
Question number three.
Should I keep the axis on my graph or label my data directly with data labels?
It depends.
So this is a common decision point anytime you're visualizing data of do I preserve the
axis, the line and the tick marks and the numbers that go with those or do I label my
data directly?
And now for me, the decision point or the consideration you want to be making here is
what level of specificity does your audience need to have with the data you're going to
show?
If the specific numeric values are important, then you may want to consider labeling the
data directly.
And if you're labeling all your data directly, you don't need the axis anymore because it
becomes redundant at that point.
On the other hand, if you'd rather your audience focus on the shape of the data or relationships
between different aspects of the data that you're showing, then you don't want to clutter
your graph with the data labels and instead can consider preserving the axis.
So your audience has that there to get a sense of general magnitudes, but it's not
cluttering up your graph directly.
Question number four.
Does my axis always have to start at zero?
It depends.
So there is a rule here, which is that with bar charts, yes.
The axis must start at zero because with bars, what our eyes are really doing are comparing
the endpoints of the bars, which means it's important to have the context of the full
bar there in order to make that an accurate visual comparison.
And we see issues with this where people chop off the bars at something other than zero.
And what this does is invalidate the visual comparison.
And actually, I'll use this as an opportunity to mention, Alberto Cairo's been doing sort
of a tour of the States and probably other locations as well, Visual Trumpery.
He's calling it.
And it's a talk on misleading data and visualizations.
And he did this a couple of weeks ago at the Urban Institute, where John Schwabisch hosted
him.
I'll make sure I link to that in the show notes in case you want to check that out because
I actually recorded and have posted that, which is something to keep in mind.
I think both as we are creating data visualizations and as well to be smart consumers of data
visualizations.
Now, it comes back to axis starting at zero.
So with bars, you cannot.
I've actually never heard of a good exception to this rule.
But with lines and with scatter plots, you actually can get away with starting your axis
at something other than zero and doing the sort of chopping and zooming.
And that's because if we're looking at lines or points, we're focusing actually more on
the positions of those points in space.
If we consider a scatter plot or for thinking of a line graph, the slopes and the relative
slopes that connect those points or of the lines that connect those points.
And mathematically, as we zoom, the relative positions and points remain constant.
Now, we still want to take care, though, and take context into account and make sure
we're not over zooming and making minor changes or differences appear like a really big thing.
But sometimes minor changes or differences are a really big thing.
If we think of the efficacy of a drug, for example, basis points of difference can mean
lives saved.
And now, depending on our audience, we may want to think about turning that into lives
saved, something a little bit more tangible.
But when you do need to show more minor changes or differences where those are meaningful
and need to be able to zoom in to be able to see that, using a line graph will be a
way to get there.
And actually, I've made a few different posts on the blog over time related to this that
I'll link to in the show notes as well.
Question number five, what should I do when I have missing or incomplete data?
How upfront should I be with my audience about that?
It depends.
And really here, it depends on how critical that missing or incomplete data is to your
overall message.
Do you know enough that generally, directionally, things are still going to be what you're saying?
Or are there really important things where you're making an assumption and if that assumption
turns out to be false, it actually changes the outcome of what you're going to be showing?
Because I would say, in the former case, where, OK, maybe your data is not complete, but you
have enough of it there, and you can say generally what's going on.
And even if you get the rest of that data, it's not likely to change the course of what
you're recommending or what you're showing, then I think that can be more footnote sort
of material, where it's important still to note, but it doesn't need to be the first
thing upfront that you show your audience.
On the other hand, if you're making some assumptions or if knowing this incomplete data could change
the outcome of what you're showing or change the thing that you are recommending or pushing
for, then you need to be more upfront so that your audience can take this into account as
they're interpreting what you're showing.
Now when it comes to how explicitly and where and how we caveat our data, you want to be
thoughtful about this, because overcaviating, when you don't need to, can actually derail
the conversation.
I can think back to an example where I was at Google and was getting ready to present
some data to senior leadership on the cost of attrition, and there were so many assumptions
that went into this.
How long was a seat vacant?
How much did we spend on recruiting activities?
What was the value lost over the time of the vacant seat?
When I went in, it ended up being, if we picture a slide, half the slide at the top was taken
up with all of these assumptions, and then the graph ended up actually being this sort
of tiny thing, almost an afterthought on the bottom of the slide.
And the exec who I was presenting to you took one look at this and said, "You actually don't
even need to talk to me today because I don't believe anything you're going to show me when
you caveat that much."
And it's one of those things thinking back, "Yeah, I never should have gone in with that
anyway."
And now whether that means not showing all of your caveats upfront, or if it means changing
the way you talk about it.
And these things all have implications on how our audience takes in the data that we're
going to show them, and how much they believe it or don't believe it.
I had an interesting conversation actually a few weeks ago with a client, this was a
pharmaceutical company, and they were doing end notes and footnotes throughout their slides
in a couple of different ways.
They have numerical footnotes that they were using in some cases, where they have a slide
title that would make some sort of claim and then have a footnote, a number at the end
of it.
And then on the page it would have the number and the data source or the article that the
claim was coming from.
There were other cases where they use an asterisk.
And we had an interesting conversation about how people feel when they see a numerical
reference versus an asterisk.
And the conversation was mainly, people were feeling when it's a numerical citation that
it feels like there's some more data to back this up.
And I can look for details and see the article or see where I need to look for more data.
Whereas the asterisk seemed to carry the connotation of saying, but or however, basically making
the claim or the statement that was being made, having it feel less true or less complete
in some way.
And so we didn't come up with a solution of what we should do there.
But it was interesting to be thoughtful about how these different methods of linking to
additional information or caveats, how it changes, how people read what we're showing
them and how they take that in.
So I think when it comes to cases where you have missing or incomplete data coming back
to the question, you really want to think about how important is that going to be for
your audience?
And then how upfront do you need to be about that?
And actually, Nathan Yao had a great post on this recently called visualizing incomplete
and missing data, where he showed a handful of different options to potentially use in
different scenarios, where you need to show that there is incomplete or missing data,
but are struggling with how to do so.
And actually, when I was looking up that reference on his site, I saw he has another post that
I'm in a dog ear, but I'll link here as well, called visualizing the uncertainty in data.
That's sure to also be a good one.
Question number six, where should I put text on a graph?
Now it depends, like always, right?
And for me, typically, the best place to put text on a graph is as close as you can to
the data it describes so long as it doesn't obscure or interfere with the ability to read
the data.
What we want to think about when we put text in a graph or put text together with a visual
is how do we make it clear when our audience reads the text, where should they look in
the visual for supporting evidence, if there is supporting evidence there that they should
be looking for?
And vice versa.
To see the graph, where should they be looking in the text for words that help describe that
or lend more context to it?
So proximity is one way that we can show that, right?
By putting the text close to the data it's describing.
Similarity is another way to make that visual tie, where I can think of highlighting certain
aspects of the data or certain points in the data with a given color and then can use that
same color in the text that describes that component of the data.
So that when my audience reads the text they see the color and associate that with the
same color in the graph or vice versa.
There was actually a post recently that Elizabeth here at Storytelling with Data did on the
blog a few weeks ago where she was going through a makeover and it ended up being a scatterplot
that was divided into four quadrants and there were points within each of those quadrants
and she'd chosen in her final view to label that data directly.
And we actually got feedback through the blog comments from a couple people saying, "Oh,
that actually, for me, that looks a little cluttered and impacts the ability to really
see the data and understand where to look in the data."
So that case we actually ended up doing an alternate view where we use similarity of
color in the way that I just described to tie the text to the data and vice versa.
And actually, when it comes to where to put text for a view of a ton of different examples,
check out the recent Storytelling with Data Challenge recap, 88 annotated line graphs.
I'll be sure to link to this in the show notes, but here you'll see 88 different annotated
line graphs and a ton of different ideas in terms of where and how to link your text
to your visuals.
So where should I put text on a graph?
Well, it depends, right?
When you can put it close to the data that it describes, unless that's going to clutter
the graph or make the data hard to read.
And then you can use similarity or connection, right?
Actually drawing a physical line from the data to the text or vice versa can also be
something to think about here.
Let's take a quick break and when we come back, we'll discuss an interesting exercise
that Neil Richards undertook to help answer the question, "How much text should you include
in a data visualization?"
Hi folks, Randy here.
You might remember me from episode three of the Storytelling with Data podcast and I'm
here to share some exciting news.
Cole has just released an audible version of her best-selling book, Storytelling with
Data.
I was lucky to be able to be there at the legendary fantasy studios in Berkeley, California
where she recorded it, making sure this would be a book on data visualization that you really
can listen to.
Here her read her book to you describing the visuals and teaching the lessons in the way
she wants you to hear it.
If you're like me and enjoy listening to podcasts and audio books in the car or while
out for a run, then you're really going to enjoy this.
Whether it's the first time you're getting to know Storytelling with Data or you have
a worn copy of the book on your shelf, you need to check out Audible or Amazon today.
Welcome back.
So when we left off, we were discussing where we should put text in a graph.
Question number seven is how much text should I put in my graph or with my data visualization?
Now it depends, but in general my view is that there's some text that has to be there.
Every graph needs a title, every axis needs a title, exceptions to this will be rare.
And if you title directly, it means your audience doesn't have to use their brain power to try
to figure out what they're looking at or make assumptions about what they're looking at.
Now beyond that, for me, when we talk about telling a story with data, we also want to
have text that helps answer the so what, right?
Not only what the data is, but why do you want your audience looking at it?
What do you want them to take away from it?
And so I advocate use of a take away title for that, where you say right in the slide
title or if it's the visual in another form, in the graph title potentially, what do you
want your audience to know?
Which primes them so that by the time they're looking at the data, they already know what
to be looking for.
And actually related to how much text, Neil Richards, who has the blog questions in datavis.com,
recently posted an interesting challenge and he summarized it up in a post called how much
labeling should you include in a visualization.
And he created this graph and it, you know, imagine you've got, I don't know, 20 lines
that are probably more than this, where each of them start at the left and there's a dot
and then in the middle there's a dot or two and then on the right there's a dot and you
have these lines progressing sort of downwards and to the right and I'll link to this so
you'll be able to look at what I'm talking about in case this is hard to visualize.
And it didn't have any labels on it, any titles, any words at all.
It was simply the data.
And he posted this on Twitter and said, what do you think we're looking at?
And invited people to guess.
And there's some interesting back and forth, right?
People were saying okay, it's the beginning of something, it's the end of something.
I'm not sure what and I'm not going to give away what it is.
I can take a look at his post where he goes through this and see if you can figure out
what it is that you're looking at.
But it was interesting.
Somebody did end up answering it correctly, but she actually said she wouldn't have gotten
there without reading what some of the others, some of the guesses and other thought process
that people had gone through.
And so really this was to try to understand how much text do we need to make our data
accessible.
And one of the funny things that happens is when we visualize data, we know what we're
looking at.
And so it becomes so obvious to us that labels and titles almost seem redundant sometimes.
But this was a good exercise showing just that thing.
Because once you actually know what the data is that Neil's showing, it seems really obvious.
And you can't unknow that anymore.
But until you know what it's showing, you have no clue what you're looking at.
And at best you're making an assumption.
And so it was just a good exercise and illustration that we need text with our data visualization
to make that data accessible, make it understandable, make it so your audience knows what you want
them to see and what they're looking at.
And now how much text though is going to depend on how you're presenting the information.
Are you there to talk your audience through it?
In which case you can tell them what they're looking at on the different axes and may not
have to title and label everything directly.
Or is it something that's being sent around?
Your audience has to consume it on their own.
In which case I'd really recommend having those words on there to make your data accessible.
Another recent post by Neil that you may want to check out is one called Is White Space Always
Your Friend, where he actually blogs about his recent submission to the storytelling
with data challenge, where he looks at the name Neil over time in kind of a cool way
and does some nice annotating there as well, and addresses this question of how much white
space is enough, how much is too much, and so forth.
Question number eight is one that comes up frequently in my workshops, which is how much
is too much?
How much can I put on a slide?
Or how many graphs can I put on a slide?
This is a question that comes up a lot.
And the answer there as well is it depends.
And actually it depends on maybe some of the same things that we just talked about when
it comes to how much text.
So I think for me, the thing it depends on most is how are you going to be presenting
these materials?
Are you there live to talk your audience through it?
Or are you sending something around that they are meant to consume on their own?
So ideally these two scenarios call for two totally different work products.
Sparse slides when you're there in person because you're there.
You can lend more context.
You can fill in any gaps or answer questions.
You can talk about what your audience is looking at and why versus a denser, almost report-like
document for when you're not there to talk through it because then the document has to
stand on its own, which means you need all the words that you would say in a spoken presentation
written down physically on the page.
Now rarely do we actually end up doing two different work products here, though.
Either we end up with this one combined slide juvant, part presentation deck, part report,
not exactly meeting the needs of either scenario.
Usually it's way too dense to put up on the big screen and sometimes not dense enough for
the version that gets sent around without you there to support it.
Now some strategies that you can employ when that's the case and coming back to this question
of how much is too much.
One strategy is to keep your slides sparse so you can cycle through and focus on one
or a couple aspects of your data at a time, always indicating to your audience where they
should be looking in what you're showing, which you can do either through your actual
gesturing or by highlighting certain things within the data through color or bold or other
pre-attentive attributes.
And then you can end with a final fully annotated slide or two that would be for the version
that gets sent around so that your audience who is consuming it on their own has those
words physically written on the page that help take them through a similar story as
to what you'd be talking your audience through in a live setting.
Because when you have something on your computer in front of you or you print it out on a piece
of paper, we are open to higher density of information when that's the case.
Meaning we can get away with having more content without visually overwhelming our audience.
And now we still want to be thoughtful and create visual hierarchy and push some things
to the background and try to draw attention to the important things.
But you can get away with more in something that folks are consuming on their own than
a live presentation where you're going to put something on the big screen because less
already looks like more when you put it on the big screen and make it big.
So I'll often show this as a strategy where we have sparse slides and maybe use animation
of things coming in or going out or being pushed to the background so that I can direct
my audience's attention to where I want them to look as I'm setting up the data and talking
through the data and the story.
And then can have a denser version that pulls that all back together.
So in a live presentation, I'd only ever have a graph on a slide.
Never more than that simultaneously unless it's that final version where we've already
gone through the pieces and now we can pull them back together in a way that's not going
to feel visually overwhelming to our audience because I've already seen the big picture
piece by piece.
And then when it comes to how many graphs can I put on a slide, it still depends.
It depends how many words and what sort of structure do you need to put around that so
it makes sense to your audience.
And I find I'll often end up with a structure where I have two sides of the slide and this
again is for that final annotated version that can be denser when we're sending it around
to our audience where I'll have some text, a title and some text and a graph on the left
and a similar setup on the right.
It's a nice way of if you have things that actually can be beneficial to see all at once
or are connected to each other.
Now there are cases where you can get more on a slide than that.
You just want to be aware because the challenge in having a page that feels dense or feels
complicated is that some portion of your audience may decide that's going to take too long for
me to figure out what's going on and we'll instead turn their attention to the next thing.
And so it's one of those things that comes back to you of how much time, how much patience
do you have on the part of your audience?
How are you going to be going through the material and then trying to figure out therefore
how much do I put on the slide, right?
How much is too much and that's going to look different in different scenarios.
Question number nine, how much time should I allow?
And this is an interesting question and clearly the answer here is also it depends.
But it's interesting because we often don't allow much time for this part of the process.
If I step back and think about the typical analytical process, I maybe start off with
a question or a hypothesis, then I gather the data and I clean the data and I analyze
the data.
And at that point we'll often throw it in a graph, maybe outline some findings and stop
there.
It's interesting to me because that is the only part of the process that our audience
ever sees.
So my view is it deserves at least as much time and attention as all of those other steps.
Now how much time you should take though, how much time you should allow, it depends.
It depends how important is the data, how important is the thing that you are communicating.
If it's less critical and a quick hit and it's not a huge decision or recommendation
that you're making, yeah, then you probably don't need to spend as much time.
However, if it is something important, right, depending on your audience, depending on the
scenario, then you want to take time on this step because whether it should or not, the
amount of time and attention to detail that you spend on the communication piece has connotation
for the amount of time and level of detail that you paid through all the other steps
of the analytical process.
So you want the piece that your audience sees to say good things about all of the things
that happened behind the scenes that they don't see directly.
And now my general advice is it's always going to take more time than you think it
should take.
So always carve out more time than you think you're going to need.
And get feedback when you can to try to figure out when you're done.
And actually that brings me to our final question in the series today.
How do I know when I'm done?
It depends.
And it depends on some of the same things that we just touched on in terms of how much
time should be allowed.
How do I know when I'm done?
Well, if it's something that's not critical, not super important, then you can do a quick
and dirty and that may be good enough.
On the other hand, if there is an important audience or it's an important discussion that
you're setting up or it's critical that you get folks to make a decision on something
or that they arrive at a certain conclusion, then you want to spend some more time.
And my view is that there is an incredible amount of value to be gained from work that's
already being done if we can more effectively communicate that work.
So how do I know when I'm done?
One way to test it is to solicit feedback from somebody who doesn't have any context
or has very little context and show them your work, talk them through your work, get their
questions and observations and discussions.
And that can oftentimes be an enlightening sort of process that helps us see things in
a way through our audience's eyes.
Because as you get close to your work, which inevitably happens, it becomes really hard
to take a step back and see things through our audience's eyes.
And so soliciting a fresh perspective, someone else to help you do that who's less close
to the work, can be really useful for figuring out whether what you're doing is working.
Whether you are defining things in a way that makes sense, whether your audience is seeing
the same things or coming to the same conclusions that you are or that you want them to.
And can help you answer this question, "How do I know when I'm done?"
All right, so those were 10 questions that we can answer with those two words.
It depends.
And actually, many of the questions that come up in this space when we are visualizing data
and communicating with data, the answer to many of those questions is it depends.
And what it depends on is going to change for different scenarios.
And I think for me, stepping back and thinking about, for each scenario, who's my audience?
How am I presenting to them?
What am I presenting?
Are they coming in with biases that I need to address?
How can I do this in a way that's going to help ensure success?
And it's the critical thinking that goes into that process where rather than just do things
the way that we've always done them, think about what's going to make you successful in
your given situation.
And that may look a little different each time.
But it's by being thoughtful about that and by thinking through, well, what does it depend
on this time, in this situation, that we will be more successful when it comes to effectively
visualizing our data and using it to tell stories?
So there were 10 questions.
Let's shift now to some additional questions in the form of reader Q&A.
So if you have questions, you can email those to
[email protected].
And actually, if your question is chosen for my next podcast, I will gift you a free copy
of the recently released Audible version of storytelling with data.
So if you have a question related to visualizing data or communicating with data, be sure to
send that to
[email protected].
Sia writes, "Hi, Cole, I have a quick question.
Why do you write the titles of the blog in small case letters, as with your book as well?
Is there a rationale with this style?"
This is a great question.
And yeah, it is a stylistic thing that I personally like, but there's definitely rationale behind
it.
For me, it feels less intimidating, more accessible, which is how I'd like my book and the blog
to be regarded.
And in general, stepping back from that, I'd say that case style, do we write caps, do
we write lower case, this is something that's often overlooked and I think is an important
consideration, a decision that we should make intentionally.
As a couple of examples, I tend to title my slides using sentence case, where just the
first word is capitalized versus capitalizing every word in my title.
Because I feel that this helps to encourage key takeaway titles, which is generally what
I advocate, rather than descriptive titles.
For example, rather than a slide title that says 2018 actual versus budget, I'd rather
have something like actual spend so far in 2018 is 12% over budget.
So my audience already knows what to look for by the time they get to the data.
For axis titles, as another example, I'll often use all caps, because I like how these
visually frame the graph, and I'll usually also upper leftmost justify everything, which
puts my y-axis title at the top left and my x-axis title along the bottom left, or if
the axis is at the top left.
Because caps, if we imagine, are all the same height, whereas in mixed case or lower case,
the letters have varying heights.
And so for me, the all caps just creates this nice rectangular sort of box that frames the
graph in a way that I like aesthetically.
The meta point here, though, is be thoughtful in what you do or don't capitalize.
Tabitha asks, "Just had a quick question about your x-axis for annotated line graph
example."
I'll link to this in the notes.
I have the book, but it doesn't show how you create the x-axis with the extended tick
marks.
That must be simple, but I can't figure out a simple way to do it.
Do you use text boxes?
And this is funny or coincidental, I should say, because this question has been coming
up a ton of times for me lately, and I actually should put a blog post together that illustrates
this.
I have that on my to-do list.
But what Tabitha is describing here is where there's an axis that has labels, and then it
has super category as well.
People often do this with dates, for example, along the x-axis where it'll have month, and
then below that, it'll have the year.
The way to do this in Excel has always seemed, to me, more cumbersome than it needs to be,
which is you first must create the graph just with the month.
If you imagine in your Excel, you'd have a column for months, January, February, March,
April, and so on.
To create the graph, I'd select that along with my data.
But then once I've created the graph, then I can go in and say, select data source.
And now, if I go to my x-axis labels, if I have a column to the left of month that also
has the year written just for each January, I can now extend what's being highlighted
and select both the year and the month.
And what that does in Excel is it then applies some really nice formatting where it carries
the tick lines down a little bit further so that you get a nice super categorization with
the years and then have your finer categorization be the months.
It's a way to take out what's often redundant labeling when we have January, 2016, February,
2016, and so forth, where we can pull out the year into a super category.
Another Excel question here, Paola says, "I really enjoyed and learned a lot from the
book that will help me as I start my career.
Can you point me to some tutorials, websites, or templates that can help me become better
at creating Excel charts?"
So I'll definitely refer you to my blog, storytellingwithdata.com.
I do most of my work in Excel and always try to post the Excel files with any of the makeovers.
So if you're ever wanting to click around and try to figure out how something was done,
that can be a good place to start.
I also have some fully annotated posts that are like, "Then you click here, and then you
click here, and then you click here," which would be the most awful training ever, but
works okay in a self-guided function, and I'll be sure to link to those.
In terms of some other Excel resources, I'd say Checkout and Emery's blog, Peltier Tech
is John Peltier's site, and Chandu.
All of these have tutorials and a lot of good content on how to do things in Excel, so I'll
be sure to link to those in the show notes as well.
So big thanks to those who have submitted questions, and if you have a question, email
Ask Cole at storytellingwithdata.com, and like I said, now is the time to submit questions
if you have them, because those that get chosen to be answered in the next podcast will receive
a coupon or a code for a free Audible of Storytelling with Data.
Before we wrap, a couple of exciting updates.
First one I just mentioned, but the audiobook, Storytelling with Data, a data visualization
guide for business professionals, was just released last week, and is available for sale
on the Audible site as well as Amazon.
You might be thinking, "A book on data visualization that's audio, how does that work?"
This actually was a ton of fun, and I describe the graphs.
There's also a PDF that comes along with your purchase where you can see all of the graphs
that you can refer to when you need to.
But if you like audiobooks, be sure to check that out.
I've also added a Seattle Public Workshop date on April 10th, 2018.
Details and registration can be found at storytellingwithdata.com/public-workshops.
There are also upcoming sessions in London, Zurich, and San Francisco.
The Storytelling with Data challenge this month will be announced Thursday, the 9th
of February, 2018, and will run through the 13th of February.
This is a great opportunity to practice flexing your data visualization skills.
There's some fun partnerships this time and a topic that will be, I hope, of interest.
The recap post will be published on the 15th of February, and that's 2018.
Be sure to check these out, follow @storywithdata on Twitter and Instagram.
Stay tuned for next time, where I'll discuss the beauty of constraints.
Thanks for tuning in, and thanks as always for your ongoing support of everything we're
doing here at Storytelling with Data.
[Music]
PodcastTranscript AI