When it comes to telling stories with data, Cole Knaflic is ahead of the curve. In October 2010, she wrote a best-selling book called storytelling with data: a data visualization guide for business professionals. That book led to the creation of storytelling with data, an agency that helps businesses communicate more effectively using data, and she’s since followed-up with another best-seller: storytelling with data: let’s practice! Prior to her current role, Cole served as a people analytics manager at Google, was the owner and chief consultant at Insight Analytics, and held several positions at Washington Mutual, among other positions. In our chat, we covered:
Designingforanalytics.com/seminar Twitter: @Storywithdata. Company website: Storytellingwithdata.com
“I've always really enjoyed that space where numbers and business intersect and enjoy how we can use numbers to get to understand things better and make smarter decisions.” — Cole “If you're the one analyzing the data, you know it best. And you're actually in a unique position to be able to derive and help others derive greater value from that data. But in order to do that, you have to be able to talk to other people about it and communicate what you've done to technical audiences and to non-technical audiences.” — Cole “When it comes to communicating effectively with data, you can't take out the human part. That's the part where things can either succeed or fail.” — Cole “There's no single right way to show data. Any data can be graphed a ton of different ways. And so when we're thinking about how we visualize our data, it really means stepping back and thinking about what sort of behavior we’re trying to drive in our audience. What do we want them to see in this? And then it often means iterating through different views of the data, which is also a fantastic way just to get to know your data better because different views will make observations easier or less easy to see.” — Cole “As soon as we try to draw attention to one aspect of the data or another, it actually makes any other potential takeaways harder to see.” — Cole “Words are very important for making our data accessible and understandable.” — Cole “Depending on the visualization, what you're doing is you're teaching yourself not to assume that the information is necessarily clear. You're being objective. And it sounds like a dumb question, but that's kind of what I usually recommend to my clients: We need to be really objective about our assumptions about what's being communicated here and validate that.” — Brian “The low-fidelity format—especially if you're working with a stakeholder or perhaps someone who's going to be the recipient—enables them to give you honest feedback. Because the more polished that sucker looks, the less they're going to want to give you any.” — Brian
Brian: Alright, welcome back to Experiencing Data. I have Cole Knaflic on the line today. I think probably, some of our listeners already know this name, but you run the Storytelling With Data. Cole: That's right. Hi, Brian. Brian: How is it going? Cole: It's going great. Brian: Cool. I'm excited to chat with you. I know you have a new text, a new book that came out recently. Cole: Yes. Brian: I have your first text and I thought it would be fun to like nerd out to some visualization stuff since like so much of you know this podcast, we tend to talk up a couple of elevations above data viz in terms of design and customer experience and making sure we're designing around human beings. But down in the weeds, where you know the ink hits the eyeballs is where a lot of stuff can fail. And so I thought it was time to have a conversation with someone who knows a lot about this. So, I'm super happy to have you on Experiencing Data. Cole: Awesome. I'm excited to be here and, yeah, looking forward to the conversation. Brian: Yeah. So, tell our audience a little bit, for those that don't know, like tell us about your journey and how did you get to be where you are now. Cole: Sure thing. So, I'll start with today. So, I run Storytelling With Data. We help people and organizations make graphs that make sense and weave them into what we hope are compelling and action inspiring stories. Cole: So, we do that mainly through workshops where we'll go into an organization spend half a day or a day teaching and talking about the foundations of effective data visualization on the one hand, but then also more generally communicating and weaving data into a story to try to get someone to understand something new or drive change. Cole: My path in getting here has touched a lot of different sort of analytical roles over time. I started off in the banking industry, working in credit risk management. You know doing all of the hardcore statistical building models and such, and then spent a good chunk of time at Google on the people analytics side of things there. Cole: And I've always really enjoyed that space where numbers and business intersect, and enjoy how we can use numbers to get to understand things better and make smarter decisions. And being able to visualize data is a way to make it more accessible and hopefully drive better understanding and decisions. Brian: Nice. What's it like jumping to ... I think a lot of people still think that you know what you're doing now is this creative thing, and it's like, "Oh, that's a talent." That's far away from you know the analytics and the math part in all of this. And, as I imagine, you probably will agree with me. I think there's plenty that we can all learn Cole: Yes. Brian: If we decide that it's important enough to learn it. Talk to me a little bit about that, them versus us. Cole: Yeah. And I don't like the them versus us, right? Brian: Right. Cole: Because for me, it's not this fluffy, you know I communicate. It's... This is an extension of the analytical role. Brian: Mmhm. Cole: Where... and I face this all the time, right? Where folks, particularly when they come through a highly technical background, and training, and are in technical roles, that there can be this thought that you know I do complicated things with data and that's what I do. Cole: And you know my audience or whomever I deliver that to can sort of take it or leave it. Which for me, so much value gets lost through that. Because if you're the one analyzing the data, you know it best. And you're actually in a unique position to be able to derive and help others derive greater value from that data. Cole: But in order to do that, you have to be able to talk to other people about it and communicate what you've done to you know technical audiences and to non-technical audiences. So, I think the people who recognize that and invest in those skills, right, because communicating ... Cole: You know I consider myself a quant first and foremost. Brian: Mmhm. Cole: And for me, communicating effectively was not something that felt natural. Right, like anything, it's a skill that takes practice, and trying things out and learning. But when you can bring those pieces together, when you've got both the technical side, the data know how, and you can speak about that intelligently to a variety of people, you actually can turn many more situations into successful situations. Brian: Mmhm. Cole: And not let the value from the data or the great work that you've done with the data get lost or not have the impact that it otherwise could. Brian: Sure. Sure. And I think deep down inside most people ... It's like take it or leave it. It's like, well, do you really want to spend all this time working on something that someone isn't going to use, Cole: Right, right. Brian: Or they're going to ignore it, or they're just going to like kind of roll the eyes and look at you like, "Okay, I have no idea what that guy is doing, but thanks." Cole: Yeah. Brian: Like I don't think most people really want to do that, so we have to acknowledge that the gap exists first and then decide if we want to do something about it. Cole: Yes. Brian: Since you self identify as a quant, like jump me back 10 years. Is there something you would have, the now Cole, would tell the 10 years ago Cole to perhaps shorten the path to get you to where you are now? Cole: Interesting question. So, I mean, for me, I think I needed to go on the path to get to where I am. Brian: Uh huh. Cole: And there were all sorts of different learnings along the way. So, I don't know if I'd really want to cut that short. But if I think of reframing it of what would I tell others today or ... You've caught me on the spot here in terms of thinking through this. Cole: I think it's, you know part of it is just learning from everything, right? And reflecting when you do something, right. When you work on a project, thinking about what is the goal of that. And does that thing, or did that thing happen as a result of the work that you did? Brian: Mmhm. Cole: And reflecting constantly of you know when did things lead to a success? And what did you do that helped with that? And when did things not work out quite right? Brian: Right. Cole: And how can you learn from those things? Cole: Like this ongoing process of ... We become too complacent, I think, a lot of times in the day-to-day work. And so the more we can do to really be thoughtful and sort of critical with ourselves around how we're doing and where things could be better, then I think it can be a great way, you know one, to not let yourself fall into that sort of complacency, but then also to just be getting better all of the time. Brian: Mmhm. Yeah. I mean one of the kind of prevalent themes on this show that I talk about a lot is designing for outcomes and not just creating outputs. Cole: Yeah. Brian: The outputs part is the beginning of the end, but it's not the end. It's the point at which an end can start, and then you can decide, "Well, is this going to end well? Or is it just going to be drop in the floor? Like how is someone going to receive this information, and hopefully take action on it?" Since... Cole: Yeah. Brian: I mean, so much in the business world, right? Like we're not doing this for posterity's sake. It's like I'm helping this team inform the next decision they're going to make, Cole: Yep. Brian: And here's a bunch of data to back it up. Brian: So like what if you made your job focused on did I get them to take action? Even if the answer was no, because the data suggested like keep course, carry on, don't change, don't turn, that's still a decision, but it was informed by my work. Brian: If you look at that as the outcome and not just the, "I delivered the presentation, or I delivered the model," or whatever the heck it is, to me, that's more fulfilling. And I think most people probably don't realize that, that's maybe not always happening because they think the end point is the output. Cole: Yeah, it's an evolution though, right? Brian: Sure. Cole: And I can understand why people get driven by output. It's an easier thing to measure. Brian: Oh, yeah. Cole: Right? If I finish something, I can check it off. Brian: Yep. Cole: You know or add my tally mark. Versus the outcome is a you know a harder, Brian: Oh yeah. Yep. Cole: More ambiguous thing in many cases. But yeah, I agree. That's an important shift to make. Brian: Yeah. Yeah. So, let's go down into the weeds a little bit here about some visualization stuff. So, my general sense is that you know I'm less involved with the tooling and tactical stuff in my own consulting work, but what I do like is that I feel like so many of the tools are informed by more design theory and they remove the need to start from scratch. Brian: So, better defaults are present in the tools, which is great for everyone, right? Because you can spend more time working on what I call goal time, Cole: Mmhm. Brian: Which is really your particular problem, not tooling stuff where I just need to get this freaking font change. Cole: Yep. Brian: Like, you know "Get the bold text out of there." Whatever the heck it may be. Do you feel that we've come a long ways there or there are still ways to go still on that? Cole: I don't know. Brian: I mean and again, taking the human choice out of it, Cole: Yeah. Brian: But just the tooling defaults. Where do you think we are with that? Cole: I mean I think, the pendulum swings, and it's swung mostly away from you know 3D and- Brian: Right. Cole: Crazy colors and those sorts of things, which I think is a good direction. Brian: Uh huh. Cole: But there aren't magical tools out there that make all of this stuff easy, right? Brian: Sure. Cole: When it comes to communicating effectively with data, because the tool that you really need in order to make that happen is your brain, right? Brian: Yeah. Cole: You can't take the human part out of this, Brian: Mmhm. Cole: Because that's the part where things can either succeed or fail. Because a tool is never going to be able to, or at least not in the near term, able to you know your context or know the story or know where you want your audience to focus and take steps to make that happen. Or figure out what might not be necessary, what clutter can we get rid of. Brian: Mmhm. Cole: And those are the steps that irrespective of the tool and the starting point that a person needs to make when we're communicating for explanatory purposes. Brian: Mmhm. And so, when we think about getting the tool, like so there's like tool defaults, right? Cole: Yeah. Brian: Which is like let's not ... Like for example, like axes, colors and grid lines, like they shouldn't be black ... Almost generally speaking, they should not be black. Cole: Yeah. Brian: Like they should recede into the background. Cole: Exactly. Brian: And so it's nice if tools just default and do that. Do you think there's like a communication, like there's an equivalent side to the non-data vis part? So, like the presentation part, Cole: Mmhm. Brian: The storytelling part, are there like some defaults that people should know about? Or some like or maybe that you've seen change over time where people are having a better like basic skillset? Where whatever the black grid line equivalent is on the storytelling side. Cole: Yeah, I love the analogy. I think, for me, it's audience. It's the always thinking critically about who your audience is, and what matters to them. Because it's actually really easy to design something for ourselves, right? Brian: Right. Cole: For my project, for my data. Cole: It's a much harder thing to step out of that and try to design things first and foremost for the people on the receiving end, which is why we're doing all of this in the first place. Brian: Right. Cole: But I think when we can do that, when we can pause and think critically about our audience. Who are they? You know what do they care about? What motivates them? What keeps them up at night? What context surrounds their need for the data or whatever we're providing them? Cole: If we can be thoughtful about that, it means we can frame things in terms of what's going to work for them, right? And when it comes to everything. What's their level of technical expertise? How does that mean you're going to communicate to them? Brian: Mmhm. Cole: What kind of graph you might choose, or how you walk through the detail. Cole: The more thoughtful and, I guess, the more planning we can do around that part of the process, the better aligned we are to ultimately do something that's going to meet our audience's needs. And it's through doing that, that we're able to then meet our own. Brian: Mmhm. Cole: So, I think for me, it's coming back to audience always with pretty much every design decision we make when we're communicating with data. Brian: Absolutely. Yeah, I mean, the self reflection thing is something you have to learn to keep in check and always be objective, asking questions about your own choices, Cole: Yes. Brian: And you know not coming in with a bunch of assumptions that... you know how great is this bar chart here? Could you... there's [crosstalk 00:12:50]. Cole: Well, and leaning on others to get that feedback along the way, right? Brian: Sure. Cole: Because you know if you make a graph, or if I make a graph, I know exactly what it means, and what everything is, Brian: Mmhm. Cole: And how things are being encoded, and what somebody should take away. Cole: The challenge is, nobody else lives in my head. Brian: Yeah. Cole: So, for other people, I actually have to explicitly make those connections and you know put words around it, or do things to emphasize or de-emphasize, or maybe even choose a different way to depict the data for somebody else. Brian: Sure. Cole: That's where getting feedback from someone else, because we lose that perspective when we get close to our work. Cole: So, getting that perspective from a colleague or a friend who's much less close to the details can help us identify where things are working and where they might not be, and give us pointers on where to iterate. Brian: Got it. Got it. Can you... you know, so, if we take that down a level to like tactically, like well, how do I do that? Typically, when I'm working with a client or something like that, we would talk about this potentially, depending on what phase of the "design" they're in. We may run a usability test on it or we may still be doing some more research and rough level design where we don't really even know where we're going yet. Cole: Yep. Brian: But a way you could do that, for example, is questions like, give me ... First of all, what's a summary of what this chart is telling you? And just open-ended question to let them see if they can get the story. But you can also answer questions like, "Which category performed the most, and which one did the least? And about how far apart were they?" Brian: And that might sound like a simple question, but depending on the visualization, what you're doing is you're teaching yourself not to assume that, that information is necessarily clear. Cole: Yep. Brian: You're being objective. And it sounds like a dumb question, but that's kind of what I usually recommend to my clients is that we need to be really objective about our assumptions about what's being communicated here and validate that. Is there a process you use like to go through that with your students and that type of thing? Cole: Yeah. I mean, I think in general, it can always be helpful in a you know less structured environment where you've got a colleague where you can just say, "Hey, can you take a look at this?" Brian: Mmhm. Cole: And you know don't give them any context, Brian: Mmhm. Cole: And have them talk through their thought process out loud. Cole: What do they pay attention to? What questions that they have? What observations do they make can help you figure out generally is this working or not? And then I think depending on the scenario, what you described can work remarkably well, where you actually give people particular questions to answer that you can use to help assess whether what you've created is providing for the tasks to be done that you need it to do. Brian: Right. Cole: So, being clear about, "Well, what do I want to enable my audience to compare? Or what do I want them to do with this visual? And is it facilitating that?" Because there's no single right way to show data. Any data can be graphed a ton of different ways. Cole: And so when we're thinking about how we visualize our data, it really means stepping back and thinking about what sort of behavior are we trying to drive in our audience? What do we want them to see in this? And then it often means iterating through different views of the data, which is also a fantastic way just to get to know your data better. Because different views will make observations easier or less easy to see. Cole: And so you can actually get to learn your data and the nuances of it better as you allow yourself to iterate through different views. And doing so can also help you realize which one, or which set of views might work to help create this sort of aha moment of understanding with your audience, or with the users of your data. Brian: Mmhm. I thought it was funny when we first talked on the phone and you said, "I don't self identify as a designer." And you know when I look at your work and the output of what you do, I'm going to give you that crown, because I think you have all the ingredients to make a designer, whether you call yourself that or not. Brian: And I don't care about the name. Cole: Sure. Brian: I'm a big fan that if we're all in the maker community, and we're making for others, then in spirit, we're designers. Cole: Yeah, it's fair. Brian: It's about our deliberate choices, right? Cole: Yes. Brian: So, but I do want to ask you about a little bit on the software side of things, not on the tooling side. Cole: Mmhm. Brian: But what's different about when we're ... You know a lot of people that I work with were developing applications and software products Cole: Mmhm. Brian: That may have a visualization element inside them. Brian: And so the unique thing here is we're not putting this into a PowerPoint and delivering a linear story that has a clear ending. We need these charts and graphs to live alone in a dynamic environment. Cole: Yes. Brian: So, do you have like a rules of thumb or guidances for perhaps how might I change my approach to visualizing when the human narrator is not going to be there to accompany every user interaction, right? Every user session. Cole: Yeah, absolutely. So, I tend to make a distinction between the exploratory process and the explanatory. Right, I spend more time on the explanatory where you've already analyzed your data, you have something specific you want to communicate. Cole: But before you do that, you have to explore the data. And the data exploration piece for me is what the sort of tools you're talking about. They should make that easier, right, because the exploratory views of the data, right, any sort of dashboard or you know dynamic sort of graph is something that the user should be able to look at and figure out really quickly you know where are things in line with my expectations, where are they not. And basically use the exploration of the data to start to identify what may eventually be interesting stories. Cole: So, the sort of tools that allow us to do that actually need to apply some very different lessons than we would use in the explanatory space, right? Because if I am there to talk through the data, I can do things like focus your attention with color and outline specific takeaways. Cole: Whereas if we're designing something that's meant to be used more for an exploration of the data, which it can't do any of that, right? Because one, it's dynamics, so things are changing. So, the area of focus or story might change from month to month. Brian: Right. Cole: But secondly, and more importantly probably is as soon as we try to draw attention to one aspect of the data or another, it actually makes any other potential takeaways harder to see. Cole: So, I think really coming back to what are you trying to solve for, what are your users going to be trying to solve for, and how do you design something that's going to help facilitate that? So, in the case where you're designing something dynamic, you know there's no storyteller there. You want to really understand what are your end users, what sort of stories are they eventually going to want to be telling with this data? And how do you design things so that they can uncover those stories more quickly? Brian: Mmhm. This made me think just as you were saying that, of ... I'm sure you've been in this situation before where perhaps you have a chart or graph and it has a title that is supposed to ... The title, the text, and perhaps there's a lead in sentence or something is kind of the story part, Cole: Mmhm. Brian: But the data that's being presented is in different units. Brian: So, a good example of this is like how do we ... Like designers, how do we name icons? Do you call it envelope? Or is it the email icon? Cole: Mmhm. Brian: So, functionally, it's about representing email. Like that's a common pattern that we use, but the design is an envelope. Brian: And I've seen the similar parallel of that analogy makes sense where your chart, it's like the units are dollars and cents, but the title might be like, you know "Where is lost revenue?" Or that's not a good example, but something. You know what I mean? Cole: Yeah, where there's a mismatch. Brian: Yeah, and you don't want to just say like, "Change in dollars over time is ..." Like yes, that's literally what you've plotted is change in dollars over time. Cole: Yep. Brian: That is not fulfilling the need of the user. Can you talk about that friction a little bit, maybe how you approach that? Cole: Yeah, I mean, in an ideal scenario, right, pictures and words can work beautifully together. And you know I think of a graph as a picture of the data. Brian: Mmhm. Yep. Cole: And so you want to think about how you can have those things reinforce each other. Where if somebody reads the words, they're getting primed on what they're going to see in the graph. And if they read the graph, it illustrates for them some things that they read in the words. Cole: When those things work together seamlessly and it doesn't feel like there's mismatch, that's when it's magic, Brian: Yep. Cole: Because it's good design. And the person who's looking at it probably doesn't even realize it's good design, because it's just easy for them to consume. Brian: Yep. Cole: When that doesn't happen is the issue. Right? Where you've got a title that you know talks about change when you're plotting the absolutes, or you know whatever the mismatch may be. Because what happens is that means our audience now has to do work. Like you can imagine the furrowing of brows that's happening when somebody now reads this and looks at the graph. They're trying to figure out how do you relate the words to the graph. Cole: And anytime we show data with a graph, you want to try to ... Or excuse me, words with a graph. You want to try to make it clear to your audience how those things relate. Right, if you're describing a certain point in the graph, think about how you can connect the words to that point. Right, use similarity of color, or draw a line between the two. Do something to connect them visually. Brian: Mmhm. Cole: And on the topic of words with graphs, there's actually been some interesting studies that show. When you title the graph with the main takeaway, people are more likely to remember that takeaway when they try to recall the graph later. Brian: Mmhm. Cole: So, it's this important benefit that we can get when we use words wisely with our data visualizations. Brian: Yeah. Cole: This is actually a common thing that's raised as well in our workshops is this idea that, "Well, do I need to put words with my data? Shouldn't my graph speak for itself?" Which I think is unfortunately a really ill advised sort of direction that people go. Brian: Oh, yeah. Cole: Because words are very important for making our data accessible and understandable. Cole: And so yes, your graph needs a title. Yes, your access needs a title, unless it's something that is so obvious. And this is one of those cases. We lose perspective on this, because you know when it's the data you plotted, you know exactly what it is. So, you don't need to label it for yourself. But if you're showing it to anybody else, you definitely do need to take some of those steps. Brian: Right, right. Well, and too if we abstract away some of these like words, we're really talking about ink on screens and pages hitting the eyeball and being processed, whether it's like a bunch of curly things that are actually letters inside words, or it's like bar charts on a graph. It's all ink. Brian: So, think you know think about the text as a visualization medium. Cole: Yep. Brian: It's just a different one. But together, it's like use all the right flavors. Cole: Yes. Brian: Like not just, "Oh, I'm not allowed to use any salt." You know? Cole: Mmhm. Brian: So, I'm a big fan of using text. Brian: Even especially on the software side, like being able to generate text conclusions or opinions Cole: Mmhm, mmhm. Brian: That are software generated, and then they're backed up by evidence. Cole: Mmhm. Brian: So, in this case a lot of times, the data is simply evidence to back up a software conclusion that's created. Brian: And a lot of times what I see is there's no conclusion. There's just evidence plotted and then the user has to extrapolate. "Well, what was the desired conclusion that this application is trying to tell me?" That's a lot of cognitive load. And that's where a lot of times people think, "Oh, the visualization is wrong." Brian: It's like, "Well, it might be just fine." But you haven't told them why it matters yet. Cole: Yes. Brian: Like, what paint have you filled? Or what problem, gap, and knowledge, decision? Like, it's... the gap is too wide, let's put some words here. Cole: Yup. Brian: [crosstalk 00:24:17]. Cole: And that's an interesting parallel, because one of the things that I see happen so often is that on the data side, people stop with just showing the data. And then the conversation becomes about the data of like, "Oh, did you look at this? Or can we go get that other data? Or what about this you know crazy corner case?" Cole: Whereas when you take it to that next step, right, in your software analogy, this is telling them the so what. Brian: Right. Cole: It shifts the conversation, where now the conversation is no longer about the data. It's more about the context, and what does the data mean in light of that context. And you know does that mean we do things the same or we should do something differently? Cole: And to your point earlier, even if you don't get the action you need or the decisions different from what you thought it should be, when we're visualizing data while I'm communicating with it effectively, we get the right sort of conversation going. Cole: And that's a conversation that often gets missed when we stop at simply showing the data and don't take it to that next step of not only what is the data tell us, but what should we do with that? What discussion should take place or decision should be made? Brian: Are you tired of building data solutions that don't get used or they're undervalued by your customers, whether its internal customers, or maybe you have a software product, and the customers aren't seeing the value of the data that you're presenting? Brian: If so, I'm really happy to announce that I'm going to be running a new seminar called Designing Human Centered Data Science Solutions. It's an online seminar and seats are limited. We're going to try to keep it small. Brian: And this four-week seminar is going to help you learn how to work on the human aspects of making your solutions really easy to use and making the value of them really obvious. As many of you probably know, you can get all the data and technical pieces right. Brian: But if your intended customer doesn't understand what it's for, and how to take that data and make a decision, then it doesn't really matter what kind of plumbing and data pipelines you created in your warehouse and all the infrastructure that you might have stood up. It doesn't matter if that last mile isn't really solid. Brian: So, I want to get your customers from saying, "So, what? And what do I do with this data?" And kind of get them to a place where they look at your work as being really indispensable, and they really understand the value of what it is that you're able to do with your technical skillset. Brian: Whether you're an analytics translator, a data scientist, an advanced analytics practitioner, or perhaps you have a team of people who perhaps need some help with these non-technical skills, I hope you'll check out the seminar. And you can go to designingforanalytics.com/seminar to learn about the dates and the pricing and all that good stuff. So, hope to see you there. Brian: Can you tell me, maybe you sort of covered this, but like can you tell me maybe a time either in your personal experience through observation of others or maybe just yourself where the visualization was right, but the story was wrong? Like the behavior changed, Cole: Mmhm. Brian: The outcome you wanted didn't happen, and it wasn't a visualization problem. And the reason I'm asking this question is I want people to see how and where this matters. So, you can get all the technical part right. Cole: Yeah. And you can, right? You can have the most beautiful data visualization in the world, Brian: Right. Cole: But if the story is wrong, or if you're not relating it to your audience in a way that they can process, yeah, that's going to fail. Whereas, you know you can have an ugly graph that kind of only 80% gets the job done or not even, but if you've got the compelling story around it, that scenario can still work. Cole: Just thinking through. A recent example that I had with a client where the visual was right in terms of the graph depicted, what it was meant to. They got the story wrong though. And what happened was they were looking at something in aggregate. And in aggregate, everything was fine. There wasn't anything interesting. And then the graph showed that, and so they sort of stopped there. Cole: But what happened was when you dug several layers deeper, the story wasn't the same everywhere, right? There were some ... And I'm generalizing here to preserve confidentiality. Hopefully it doesn't end up so general that it doesn't make sense. Cole: But there's something really interesting happening in this one subgroup that had they not recognized that and gone through this next layer of questioning and analysis of the data, they would have completely recommended the wrong thing, or would have sort of lost sight of this underlying phenomenon that's happening that actually drove them to change the recommendation that they made, and help them get people on board in a way that wouldn't have happened if they'd stopped with the initial graph and story that were fine. They just weren't robust in the way that they needed to be to have the full understanding of what was going on. Brian: Got it. Got it. I don't know if this dovetails the next question or not, but the field of data science and advanced analytics is growing, right? Cole: Mmhm. Brian: We're talking a lot about this. And I'm curious, has this created any types of changes and the type of things we need to be aware of as people who visualize information when we're talking about looking into the future more, right? Cole: Yeah. Brian: Because a lot of these are about predicting and prescribing actions based on past information. Cole: Yep. Brian: Has that changed anything? Are you seeing a need to focus more on X, Y, and Z because people are coming in the door with you know AI projects and this type of thing? Or are we still grappling with the same stuff, different story? You know. Cole: Yeah. So I mean, I think the thing that we encounter is that just so many more people are being ... You know there's so much more data out there. And so many more people are being asked to do things with data. Brian: Mmhm. Cole: Right? Where it may not be a core part of their job, but basically everybody needs to visualize and understand data at some point in their work. Cole: And so for me, the core principles for doing that effectively, are not things that are changing fundamentally. Right? When I think of the lessons we teach in our workshops, they're the same lessons, and they will continue to be the same lessons. And when I get people who come back and say, "When is there you know the 201 version or the expert version?" Cole: For me, the question is not the right question, because they're the same lessons. You can just get more nuanced in how you approach the different pieces where it's like you know understand your audience and context. Choose a visual display that's going to get across the information you needed to. Identify and eliminate clutter. Focus attention where you want it when you're trying to explain something and tell a story. Right? Don't just show your data, do more than that with it. Cole: And so for me, those fundamentals haven't changed. But I think what has changed is the growing need for people who can do those things. Right? Lots of people can make graphs, and there's another set of people who can communicate. But the skills in a single person for being able to do that together effectively, I think, have lagged the growth that we've had in the amount of data that's around us. Cole: And we talked about this earlier, but people who recognize that and invest in both sides of those, right? Both the analytical prowess, but then also the ability to talk about their data in a way that makes sense and can be used to drive understanding and action. There's a big skill gap there, I think, generally. Brian: Yeah. Cole: That... Yeah. We should be able to do more with I think in terms of you know getting people. It's exposure to best practices, but then it's also practice is just a huge, important thing for getting better and pushing yourself to do things that are different from what you've done historically. Brian: Mmhm. Cole: And that's always one of my underlying lessons is you know if you think about for each specific scenario, right, what are the constraints of this scenario? You know tool constraints, time constraints. How are you presenting the information? What's at stake? Who's your audience? Cole: The pieces of the puzzle are different every single time. And yet so often, we just communicate with data the way we've always done it, because we've always done it that way. And that's not the recipe for success. Cole: We want to think about you know what's unique about this scenario. How can I learn from the patterns I've seen in the past? But how do I combine things this time to be successful here? And I think the more thought we can give to that and you know using colleagues to promote good conversation, and play devil's advocate, and try to help us be robust in how we're thinking about the data, being clear in the assumptions we're making about it. That all of this helps sort of raise the boat when it comes to helping everyone be better. Brian: Got it. And so, do you see...have you seen... You know, when I talked to ... Again, a lot of my solar system includes people coming from the data science side of things and advanced analytics and a lot of in this space. They're like, "Oh, we're happy just to find a data scientist, let alone a good one who can do that other stuff." And I'm often like, "Well, you can get all that other stuff right, but if they can't communicate the results of their work, that model may never get into production." Cole: Yep. Brian: And so, do you think it's... Are we at that point yet where it's like, "No, this is part of the job?" And I realized there's probably big places where it's big enough where you can afford to have certain types of people really focused on their hyper-specialization working just on math and models, and maybe they never get in front of a client. Cole: Yeah. Brian: But I tend to think that people that are going to ... Especially the ones that are going to move up into management and director levels, you got to have this. It's not like this extra thing. Cole: Right. Brian: Go take Cole's workshop, because it will like, "Oh, it's a nice extra thing." It's like no. It's part of the core. Cole: No, it's part of the core. Brian: Yeah. Yeah, it's part of the whole cake. Cole: Yeah. For me, it's always been really interesting. Because you think about the typical analytical process, you start off, you have a question or hypothesis. You go gather the data, you clean the data, you analyze the data. And oftentimes, we stop there. Brian: Right. Cole: You know we put it in a graph, maybe outline some findings, but that graph is the only part of that entire process that anybody else ever sees. Brian: Right. Cole: And whether it should or not, it says things about the level of detail that you paid and the rest of the process. And also, that graph is the opportunity for all of your hard work to either succeed or fail. Brian: Right. Cole: And yet, too often, we put the least amount of time and attention or you know we let the whole rest of the process take up all of our time. Cole: So, we're out of time by the end of it and don't have sufficient sort of brain power left or time to be able to make sure that communication is effective. Right, the communication is not a nice to have add-on that the communication is ... You know if you can't do that well, you may as well not have done the rest of the process, because it's not going to have the impact that you need it to. Cole: Yeah, I'm a huge believer that there's an incredible amount of value to be realized from work that's already being done that just isn't being communicated as effectively as it could be. And that's what we're trying to help change. Brian: Yeah, I 100% agree with that. It's like sticking in rehearsal, as I say. You can just stay in rehearsal all day. Cole: Mmhm. Brian: But like there's, the performance is where someone is going to hear what you're doing and decide if it matters and all of that, and you have to jump in and participate. Cole: Well, and recognize that it feels uncomfortable, right? If you haven't been putting a stake in the ground and saying, Brian: Right. Cole: "Not only here's the data, but here, audience, is something you should do with it." That feels uncomfortable. Brian: Yeah. Cole: So, I'm always a fan of you know try things out in low risk spaces helps build confidence and credibility over time. Brian: Mmhm. Cole: You know focus on small things that you can do, and try stuff out, and iterate from there. Brian: Yeah. No, that actually gets to my next question. Like, I'm a big fan of and we talked on this show a lot about working fast and low fidelity. Cole: Yes. Brian: Generating stuff quickly, getting the feedback fast. This probably ties in. Like, do you use markers and pencils in your work? Cole: Yeah. Brian: And I did see in your book you do some ... I guess it's a leading question a little bit, but talk to the audience here about working low-fi fast. Cole: Yes, this is super critical. And I think it's especially critical when you're pressed for time. And it's the thing that most often gets skipped when you're pressed for time. But yeah, picking up a pen and a blank piece of paper. Or I love sticky notes, because they're small, which forces me to be concise in my ideas. They lend themselves to being easily rearranged. So, if I'm planning something out, they can be a mix of words and pictures, and I can be moving them around. Cole: And the earlier on you can get feedback from others in this sort of low tech fashion ... Right, I'm a big fan of storyboarding, where if I'm designing whether it's a dashboard or a presentation of putting the ideas out there. And I typically storyboard in three distinct phases where I start by brainstorming, then I edit, and then I get feedback. Cole: And so the brainstorming process is just you know get the ideas out of my head, out into the physical world where I can consider them at a later point. Where I don't have to think about you know what order do they end up going in or are they going to end up in the final thing. I can just get the ideas out of my head, and that usually takes five minutes or so. Cole: Then you start editing, which is step back and figure out you know what structure can I put around this that might help me make sense of it to somebody else. Or, you know how might I bucket things together? What can I get rid of? And that's one of the really important things we get when we do this low tech that I think we skip when we go to our tools. Cole: So when we build something in our tools, it feels like whatever we create needs to answer every possible question that might come up. Whereas when we're working low tech, we can consider something and decide, "You know what, it might be relevant or interesting, but I actually don't need to have it as part of my communication." Or whatever it is you're working on. Cole: And so, one big benefit of planning fast and in a low tech fashion up front, is you, a lot of times, end up with a shorter thing at the end of it, which means you have more time to then make the visuals and the communication of something that's shorter to make that really quality work. Cole: The other thing we get when we work low tech is you don't get the same sort of attachment. Right? If I've just spent a bunch of time making this beautiful thing in my tool, I'm going to be attached to that. And if somebody tells me like, "No, that's not right," I might fight for it, or not want to change because of the time it's already taken for me to get it where it is. Brian: Yeah. Cole: And that's what you can let go of entirely when you're working low-fi. And you know sketch five different views of your graph. And then you know I can figure out that this crazy graph that I really thought would be fantastic that I should actually just let go of it. It doesn't work for this data. Whereas if I've done that same crazy graph in my tool, I'd be much less inclined to let it go so easily. Cole: And then getting feedback at that point, because if you can get feedback from a client or a stakeholder or a manager where you can say, "Hey, this is rough, but here's what I'm thinking." And either get the feedback of, "Yeah, that looks great. Execute." Or, "No, let's actually go in this other direction." You've not invested a ton of time in order to get that feedback. So, it just helps the rest of the process be so much more streamlined. Brian: I 100% agree with you. I'd also add one other thing about the sunk cost bias, right? Cole: Mmhm. Brian: When you fall in love with the you know your baby that you've created- Cole: Yeah. Brian: Is that, that low fidelity format, especially if you're working with a stakeholder or perhaps someone who's going to be the recipient, is it enables them to give you honest feedback. Because the more polished that sucker looks, the less they're going to want to give you any ... Cole: Yeah, that's a good point. Brian: "Wow, he spent a lot of time on that." They're just not going to want to give you it, but if there's a whiteboard, and a marker, and an eraser present, it's like, "No, it's not this. It's this. No, let's just erase it and show me. I don't care. Take a picture of it and then move on." Cole: Yep. Brian: It really fosters an environment of like, together, we're working on it to get to the right thing, and it doesn't ... You know just because I started the first version doesn't mean it's right. Cole: Yeah. Well, it invites them to be part of the process, right? Brian: Exactly. Cole: Which means they're going to be more bought in to the solution as recently, Brian: Right. Cole: Which is actually a really smart influencing technique. Brian: Yes, absolutely. Yeah. You know we talked about designing applications and products. There's a lot of collaboration there. Right? It's more together than it is self. Cole: Mmhm. Brian: The more you're throwing over the wall, the risk just tends to be bigger, because you're not connecting early. Brian: And this also gets into the old trust thing with models that especially when you get into advanced analytics and prescriptive models and all this kind of stuff too. It's getting those people involved early such that it may even be the case sometimes where the visualization means even less, because they've seen what your process has been the whole time Cole: Mmhm. Yep. Brian: That you don't need to like sell them so hard on the visualization ... Brian: It's not like, "Oh my god, are they going to believe it or not? It's like down to the wire." It's like they already know what's coming. Like maybe there's a formal presentation, Cole: Yeah. Brian: But like they kind of know what's coming, and that's a good thing. They were part of it. Cole: Absolutely. Yeah. If you could have that every single time, you'd want that every single time. Brian: Right. Yeah. Cool. Moving kind of back up a few higher elevations here. Are you finding that ... I feel like you know every business is talking about, "Oh, we need you know data literacy, and we need people to work with data and all this kind of stuff." Cole: Mmhm. Brian: Are you feeling that management and executives are aware of this as a skill gap, where you can't just get people that know R, in and out, or some statistics, or whatever it may ... Brian: You know some software technical skills that this is critical to that, and so training in this needs to be looked at as not extra. Is it still this kind of like, "I got to sell my boss on taking your course?" Or is it more like, "They're telling me I have to take it, because they know it's so important?" Like where are we now with ... Cole: Yeah, it's a good question. And I think there's growing recognition that this is a specialized skillset, right? We don't just come out of school knowing how to communicate with numbers. Brian: Right. Cole: And I think it's mixed still in terms of company's willingness to invest time and resources in it. Cole: One of the interesting things from our workshops is we work with clients across all sorts of different industries, and locations, and job functions. And so it's really interesting for me and for the team to see how even though you know the metrics are totally different that we're looking at or the industries are totally different, everybody is struggling with basically the same stuff. Cole: And there's still a ton of low-hanging fruit in most organizations when it comes to simple things that people can do that will help make their work more effective. Right, basic things like using color effectively. Brian: Yeah. Cole: Or choosing a graph that's going to be intuitive for your audience. Cole: And so, there's a huge appetite for learning these skills. And I think we're certainly ... Yeah, as more data is out there, this keeps growing, right? Brian: Yeah. Cole: Because I think one of the things we haven't solved yet that is getting better, but you think of data visualization has only been a field for not very long in the grand scheme of things. And it's actually even more recently that courses around communicating with data have started finding their ways into universities. Right? But most people come out of ... Cole: You know if I think back to me coming out of MBA school, like I should have learned this stuff there and I didn't learn any of this stuff there. Brian: Yeah. Cole: I think we're starting to make progress in terms of having there at least be some programs and some courses here and there. But I'm a strong advocate. These are things that, one, everybody should know and everybody can make use of, but then also that we should be trying to teach sooner. Cole: You know I have three little kids. And for me, watching them learn the faculty of language has been so interesting. Right, it's through repetition, and you know being sort of immersed in something. And if you think of you know visual language, it seems like something that we could teach as kids are learning verbal language. Brian: Mmhm. Cole: But I don't think anybody has cracked that quite yet. This way of you know thinking logically and asking the right questions, and designing things visually. Because it's drawing and it's thinking in story. And it's doing a lot of these things that we had seeds of and started learning as children, but then didn't get combined in the way that we want to be able to use them today when it comes to adding value in the workplace. Brian: Yeah. Well, I don't know what your childhood was like, but I have this distinct memory of like you need to be looking at books without pictures in them. Cole: Yeah. Brian: Like you had to move to text only and the image will be in your mind. Brian: And I totally get that from a reading comprehension standpoint, but it makes the assumption that together, somehow the text is less. Cole: Hmm. Brian: And it's like I just I kind of remember that even though my formal training is not in design, but I'm just like I'm not supposed to ... You there's something wrong there. Brian: And it just stuck with me, and I wonder if that's been other people's ... I wonder if that's partly why this is like this is that when we learn to read, we're kind of pushed away from illustrations and visuals and this kind of thing. Or maybe that was just my school, I don't know. Cole: Yeah, it's interesting. I mean, my kids are young. So they... you know one of the things they've been learning as they learn to read is this picture power, because they're fully in picture books right now. And one of their powers is they're meant to study the picture. Cole: And then when they read, if they come up with challenges or they're you know trying to figure out what a word is, they look to the picture for clues that might help them reading the words. Brian: Right. Cole: So, when we're learning, the pictures are very important. Cole: But yeah, it is interesting then this shift that happens when we move away from picture books and into just text, and the pictures that are then in your mind as a result of that. Brian: Yeah. Cole: I don't know how we bring that back to the parallel of data visualization. Brian: Well, we could talk about practicing, and since we're- Cole: There must be some connection. Brian: Well, let's talk about practicing for a second. Cole: Yeah. Brian: So, we're kind of, we're getting up on our time here, but practicing is definitely the theme of a new thing you have. Cole: It is. And it's been a theme for me for a long time. Brian: Sure. Cole: But yeah, the idea is the way that you get good at this stuff, like the way you get good at anything is to practice. And you know to repeat and build good habits in that way. Brian: Sure Cole: And so, one of the things that I was recognizing you know out of the first book or out of our workshops is there's still felt like a disconnect between you know people getting the lessons and feeling comfortable applying them in their day-to-day work life. Cole: And so, my new book, Let's Practice, is really trying to bridge any gap there, where the lessons are the same. But it's really focused on getting the reader involved in a few different ways. So, each chapter is organized into three sets of exercises. Cole: There's practice with Cole, where you're posed a scenario or an exercise that you're meant to work through on your own, but then I also work through my solution. So, it's a way of interjecting a ton more examples and corner cases right where things get stickier. Everything was pretty straightforward in the original book, and just giving insight into the thought process when it comes to designing effective data communications. Cole: Then the second exercise section within each chapter is practice on your own. And this is similar sort of canned exercises, but without any prescribed solutions. So, these are meant to be used for university instructors who are teaching the material, or you know managers who are wanting to upskill their team, or individuals who are just wanting more practice in a safe environment. Cole: And then the final exercise section within each chapter is practice at work. So, okay, you've done this in theory, you've done it with some canned examples. Now, let's take a project that you're facing in the workplace and break it into component pieces and give you really concrete exercises and things that you can do that will help make sure you're asking the right questions. Getting the right sort of feedback at the right points, and so forth. Cole: And so, super excited to have it out there. It was published just last month, and the reception so far has been extremely positive, which has been fun to see. So, I certainly recommend folks who are interested in honing the sort of skills that we've been talking about here to check that out. Cole: And actually, dovetailing on that, we're actually working on and have been working on a really exciting resource called the Storytelling With Data Community. Because, again, there's a need, I think, for people to have a safe outside of work environments to practice and get and receive feedback, and talk with other people about the challenges they're facing or the successes that they've had when it comes to this stuff, and discover. Right? Find great work that can be used to inspire the way that we look at things. Cole: And the community has been designed to try to facilitate all of those things. So, we're in beta testing right now. This is an online resource that people can join and take part in to get feedback and input both from Storytelling With Data team, as well as others in the community. But we'll be opening that up more broadly in early 2020. Brian: Cool. Cole: So, I definitely encourage folks who find that to sound interesting to take a look at our website for more details there. Brian: Awesome. And can I assume Storytelling With Data, all spelled out, dot-com is the place to go? Cole: That's the fair assumption. Brian: All right. Nice. And where else can people ... Do you do any social media, or if someone wanted to follow your work, what's the [crosstalk 00:49:51]? Cole: Yeah, I'm @storywithdata. Brian: Okay. Cole: And you can follow on Twitter, Instagram. And, yeah, all the info is on our site at storytellingwithdata.com Brian: Awesome. Well, Cole, this was super ... This is a great conversation. So, I really appreciate you coming on and sharing some visuals with us. Cole: Yeah, it's been fun to chat with you, Brian. Thanks for having me. Brian: Awesome. Well, thank you.
50 episodes! I can’t believe it. Since it’s somewhat of a milestone for the show, I decided to do another solo round of Experiencing...
Tom Davenport has literally written the book on analytics. Actually, several of them, to be precise. Over the course of his career, Tom has...
Welcome back! In today’s solo episode, I share the top five struggles that enterprise SAAS leaders have in the analytics/insight/decision support space that most...
