Building People-Centric Data Visualizations with Tableau Visionaries (Zen Masters)

Transcript

Jess Carter: The power of data is undeniable and harnessed. It's nothing but chaos.

Speaker 2: The amount of data was crazy.

Speaker 3: Can I trust it?

Speaker 4: You will waste money held together with duct tape.

Speaker 3: Due to failure.

Jess Carter: This season we're solving problems in real time to reveal the art of the possible, making data your ally, using it to lead with confidence and clarity, helping communities and people thrive. This is Data Driven Leadership, a show by Resultant. I'm your host, Jess Carter, and on this episode of Data Driven Leadership, we're diving into data visualization. We will kick this episode off with our solution on the spot segment and that's where we bring in thought leaders and ask them for solutions to relevant data challenges.

Today, we're going to look at the issue of data visualization and where to begin and maybe how to fix some of it to help a solution on the spot is Anna Peterson, our BI practice lead at Resultant. For those who don't know you, can you tell us a little bit about yourself? Who is Anna Peterson?

Anna Peterson: I lead the business intelligence team at Resultant and I've been with the company for about three and a half years and I do all things BI tools, so Power BI, Tableau, all the front end fun visualization efforts through the company my team gets to work on.

Jess Carter: We can work together here. The solution on the spot where we got to figure out what we do is a client comes in and they are really excited, innovative, data forward, they really want to go change the game in their industry. And as you and I sit down and start to understand and unpack what they're doing, we're realizing too that there's no standards here. They're trying to totally innovate and so they want that data driven insight and they're excited about it, engaged, but they're really not sure where to begin. So if we were to walk into that situation, where would you begin in that conversation?

Anna Peterson: What you or I would do in that situation is try to understand the motivating factor and why they're trying to get those data driven insights. So oftentimes you'll hear somebody say, "Well, I've heard about Power BI, or I've heard about Tableau and I want a dashboard." They don't know anything like what they would want on it or what questions it's trying to answer or.

Jess Carter: They look cool. That's a cool dashboard. I want one.

Anna Peterson: It's cool, I want to see the dials, I want to be able to click on something and maybe it can be on a monitor in my office and there's nothing wrong with that. That's totally understandable. They are really cool. But I would want to understand from a bigger picture, what is it that you do? How do you make decisions? Who are you benefiting? What makes you tick to be able to understand better what are we doing here versus just we're going to build something really cool?

Jess Carter: What about those CEOs or CIOs who are really into the flashy dashboards, they do want all the really cool stuff and they want to click and drive. If they don't have any of that yet, how do you keep them from being stifled by this is a process? How do you help them understand where we have to begin?

Anna Peterson: Definitely. And there's this idea that we're going to adopt this tool and that's going to solve everything and we're going to be better because of it. But I mean we talk about this a lot at Resultant, but this starts with people and we can introduce this new tool or this shiny dashboard, but we need it to actually be useful and to be adopted and to have people understand it because we do not want this dashboard graveyard where dashboards unused go to die and live forever with no one looking at them. We need to start with the why and make sure this is something that is really going to be able to be adopted by the right audience and be useful and then be maintained because anything, this is not something that you build once and never touch again.

Jess Carter: When you're building out a visualization solution for a client too. I imagine you'd have some thoughts on best practices and even beyond best practices with data breaking down the project for them to appreciate what it does take to get to a really cool front end. Can you explain some of that too?

Anna Peterson: What it would take from a developing a project perspective?

Jess Carter: If they really have that image in their head of the super cool dashboard that's on TVs, that all of their team can look at and see what they need to do differently this hour, how do you help explain, "Here are largely the blocks of work we have to do to get to that outcome?"

Anna Peterson: Some clients do have an understanding of this is a big lift, this is not something that's a couple hours, you sit down and you build out something that's going to change the way you work and some don't. But I do think understanding why we're doing this but then breaking things down into a small enough digestible chunk of work so that we can get something out there and work iteratively and add on. Because even the best data visualization engineers or dashboard designers are going to make something that may not be the best way to visualize the data.

Anna Peterson: And we're going to lean on people like the business, they know their data best. We're not going to have a hundred percent of the answers, but that's why the partnership is critical. We are really trained and being able to understand how to ask the right questions to be able to say, "Why are you doing it this way?" And not from a point of saying, "Well, this is all wrong, but why are you doing this way? Let's think critically about it. Is this the right process? Can we change that?" Sometimes they just need to see it to be able to say like, "Oh yeah, that does work better. That does look great."

Jess Carter: We talk about data literacy a little bit when we're working together. So there's also clients we meet and consultants that we meet that aren't quite as data literate as you might be. So I remember working together and there are times where you're like, "Why do we think that needs to be a bar graph?" And you can walk people over and explain here are the best visual tools for the kinds of things that you're trying to point out.

Anna Peterson: I was actually just on a call the other day where the idea of overengineering something where so much thought goes into something and to the point where we might be making this more complex than it needs to be. And I had a call where someone said, "Well, we have this filter or set of filters that are applied to a report." They said they want to make a rule where you can only pick three. And I said, "Okay. How did we get to that number?" And the idea was, "Well, I just think it'll be confusing," and you have to take a step back and think, they probably put a lot of thought into this and there may be a legitimate reason, but had you considered how much more complicated it may be or frustrating to a user that you can only pick three And was it for a suppression reason or was it for a technical limitation or a data limitation or something like that. So trying to get beyond that initial decision is something that I really enjoy.

Jess Carter: That's amazing. And what happens when the client has clear specification about the exact things that they want and you're like, "The data isn't there." What do you do when that's the case?

Anna Peterson: I mean, that happens all the time. Whether that be from a governance perspective, an issue with the data. For example, we worked on an epidemiological project in the past where it was ramped up really fast and there were no standards for this data. And everyone's in this boat where we just have to continue moving forward or we're going to sink. And there little things like poor quality and data, whether that be a text field where it should be a dropdown or missing information because whatever system we're entering this into, it doesn't require the field or something like that causes visual gaps in data. I think in this epidemiological example, we would have missing dates where we couldn't track it for this period of time for X, Y, Z reason, legitimate reasons that we're missing data. And they say, "Well, we need to put something there." We can't just show that there's no data.

Anna Peterson: And you hear that and you totally understand where they're coming from but at the same time, you have to work with those limitations that you have and you can build assumptions. And if there's no standards, that can be really hard to do. And that's where research comes into and working with the actual scientists who know this data and what that information means. But you can't leap to say, "Well, there was maybe no data that day because we don't know." It's just missing. So being really intentional in setting those assumptions and making it clear to the user or the consumer of that information, what that means so that people aren't left to draw their own conclusions.

Jess Carter: Sometimes if you're trying to pump out insights or data and then you are left in a wake of it for whatever reason, your pipeline didn't work, the data wasn't available or whatever, it almost can tell a worse message. And the other thing I think is really challenging about some of the examples you're bringing up too is in those moments there's a little moral compass too where people are like, "What could we do and how can we make it..." And you have to be like, "You got to find your north star." I don't know if those analogies aligned, but the fact that we have research and we have data scientists that we partner with who can make sure that what we're doing is statistically significant and you do that too.

Jess Carter: But that partnership of best practices, creative thinking coming from outside the box, thinking about other things that we can do and making sure we're bringing the right data that's really relevant and meaningful. And I can't tell often when I'm looking at a bunch of data anywhere on the news, online, if it's just not well cleansed and analyzed in a statistically significant way. I imagine you see that and it probably drives you crazy, is that right?

Anna Peterson: You're totally right about that moral compass. And I have been put in positions before where I've had people straight up ask me, "Can you make it look like this?" And the answer is no. I think understanding where is it that you're coming from or what decision is it that you need to make or what policy is it that you're trying to push or something like that to be able to maybe show something that can help tell the story that they're looking for. But purposefully knowing the answer you're trying to show and forcing your data, it's so easy to do, but I think more often than not, people are doing it unintentionally.

Jess Carter: They have no idea. No one's the villain that's like I need it to look like bad or good here. They're just like, "Could it?" And you have to be like, "No. We're here. We could do it this way. We can get to what you need, but we can't change the data to be what you need it to be."

Anna Peterson: We do a lot of work where we're measuring populations and comparing that against taking a look at a chart or a table or some bit of data information out of context can also unintentionally lead the user to make the wrong assumption about that information. And it can be problematic. And I think that responsibility falls on us to make sure that what we have put together is easy enough, intuitive enough to understand, but also has all the information so that we are not enabling people to make these leaps.

Jess Carter: Yes. There's this sense of you have to make sure that you have a team that's full enough with appreciation for data integrity that what we're pushing out, really we're thinking all the way through. Does it drive the right behaviors in the first place? Because you could put together a graph that is accurate and it is also wildly misleading when it comes to the meaning of that data and the way you visualize it.

Anna Peterson: Dual access charts, I think it's the number one reason they don't align and you can make anything look like... I could probably make a line chart look like draw a face or a stick figure if I wanted to. There's some pretty cool things you can do. But you also, to the same point, we've seen clients who will come to us and will say, "I need to convey this story to my leadership or whatever the audience is to be able to get this done." And I don't think that that's an integrity thing at all. It's a data storytelling thing, which is all of this goes into communicating something with data, which is all very interesting to me.

Anna Peterson: But I had a client where they were a team within a broader organization and they needed to convince their leadership that the work that they were doing had a much greater purpose, served a bigger purpose, had a much greater return on investment long term. We were able to build a really compelling story for them that convinced their leadership that hey, actually we should invest more into this team. We had no idea. I think that is probably one of the most fun parts of my job is not just building a dashboard but being able to communicate that entire story to the audience.

Jess Carter: So that sounds like if I put you in a box and said data visualization, actually it's so much more than that. It's about accurate data storytelling that can lead to meaningful change.

Anna Peterson: Absolutely. The data visualization is just a part of that.

Jess Carter: I think that you've solved the solution on the spot, and so I want to thank you for your time.

Anna Peterson: Thank You.

Jess Carter: It's really nice to be with you today. Now for the deep dive on data visualization, the two experts you'll hear from our Tableau Visionaries, Joshua Milligan and Bridget Cogley from a previous webinar my colleagues did. They'll touch on some key points Anna made and also mention what every executive needs to know when it comes to visualizing data. Let's jump into the conversation.

Speaker 6: Joshua, I'd like to start with you, if you could talk to me a little bit about the approach that is Zen Master takes when starting a project, the very beginning, where do you start? What should you be thinking about?

Joshua: Yeah. That's a really good question. Every project is different and so it's hard to say that there is a one size fits all approach to starting a project. But I think the most helpful that the ones that are the most successful are the ones where I have a big picture of what's going on. So it's not here's a data set, analyze it for us, or here's a data set, visualize it. It's how does this fit into the entire business process? What does the data mean? Who needs to understand the data? And once I start to understand that, that allows the project to unfold somewhat organically. I mean there is a structure to it certainly, but having that big picture and understanding that it's not just a set of numbers that we need to get to, it's not just a set of requirements, it's real people who need to understand real things going on in order to make a difference in the organization. And having that big picture I think is key to any project and allowing it to be successful.

Bridget: And I'm going to go ahead and piggyback off of Joshua a little bit because a lot of what he is talking about is very much that 29% problem that you were showing earlier. It's a problem I'm really passionate about in which we have this data, but how do you make it useful for humans and how do you make it so that aa a business user, I can get in, still do my job, data is a very small part of it and the report and everything is accessible to me as a business user. So I really like Joshua approach of, you want to really start scaled back here. You really want to understand everything that's going on. That way you can really get in and start building with people in mind first, simple alert things. You definitely want to avoid the swoop and poop. It's really easy, particularly as a consultant, I can come in and do my thing and pop right out, but you really don't want to get in and wreck those show as you get in.

Bridget: But you also want to make solutions that help people build on what they already have, build on the things they're already doing well and go from there. So it's definitely an understanding of here's all the assets you have, not just, "Hey, this is the data, here's the cultural artifacts that matter, here's things we know about our people." A lot of these cultural assessments, it's been great fun and insight to see how people are using data and how their culture plays into it. And that includes things like the data but it also includes data governance. How do you share data to the masses appropriately?

Joshua: Once you have that big picture and you understand the people who are involved in the decisions that they have to make, then things like data governance and the structure of the data, those do become very important things very early on in a project because you have to know what data do we have, who has access to it? And the structure is very important because the structure enables you to do certain kinds of analysis or makes certain kinds of analysis very easy or makes certain kinds of analysis very difficult. The data is the data, but we may have to reshape it, restructure it in order to use it in effective ways. And I think that becomes very important early on in a project because you can lock yourself in to a certain structure and then find out that doesn't meet our needs at all. I love it.

Speaker 6: I'm really interested in talking about a methodology or a framework for visualization and love to start this time with Bridget. Bridget, if you could talk to this one a little bit.

Bridget: So this again goes back to that 29% problem. We often have the data, we often spend a lot of time shaping the data. You see a lot of investment too on data pipelines and preparing the data. The challenge is, okay, I have this data, I'm starting to make sure it's starting to find my way towards this ideal of insight. And the question is, how in the world do I get there? This is not a new problem, but this has been an ongoing problem.

Bridget: So part of what we're trying to do through some of our solutioning is starting to shift that paradigm. And what we're doing is we're trying to build a full program and looking at how do we start doing discovery and planning? How do we understand your current state? If you think about design thinking, this is that whole what is, before we get to that, what if. All of this is really laying down that foundation. Very much like what Joshua was saying, we have to understand the whole picture before we get in and start making changes. And this is really a broad picture. This isn't just, "Hey, you want this thing and I'll get you there." No, no, no, no. I need to understand the cultural artifacts. I need to understand how people talk about numbers and what is their understanding and comfort with the abstraction of numbers. And when we do abstract, how do I help people get there?

Bridget: So with that, we start making that roadmap. We start saying, "Okay. Well, you want to be here. Here's where you are today. Here's some of the cultural barriers. Here's communication barriers that come into play." From there we design and present those recommendations and that way we really build that stair step to start getting to insight.

Joshua: What I really like about this framework is that it does give some structure to the ideas that I think we've all had about, we need to understand where we are, where we're going, how to get there and who's involved. But this does provide some of that structure and it goes back to transformation. Sometimes that's just a buzzword and we just throw it around and we say digital transformation or data transformation, what does that really mean? I think this a framework actually points out, where do you need to have that transformation? There are places where you may be doing really well, some of your people are very data literate.

Joshua: So we start to uncover what's going well, what's not going well. I think that a framework actually does facilitate true transformation, not just a buzzword or not just we implemented some technology, but we truly equipped everyone in the organization to have access to the data they need and to be able to ask the questions and get the answers that they need to make the decisions that they need to make.

Bridget: One thing that we sometimes think is, okay, we're rolling out data and we come up with this idea of one size has got to fit them all. And very much like t-shirts, one size definitely does not fit them all. So part of what we do is we start this paradigm matrix and we say, "Okay. These are the types of deployments that you can have." And within organizations we don't find one deployment solve that we find it's typically at least two and oftentimes many. So we start outlining. Okay. You want a data democracy, you want people to be able to solve service, but then you still need that escalation point. You may still need certain canned reports, you may need starter packs and templates and things like that.

Bridget: So we really start plotting people out on this paradigm matrix of this is what based on culture, based on literacy, based on all of these factors that we understand within your organization because we've benchmarked and we've also located you on a maturity model. We've said based on your visual presentation, based on consumption, we can actually say, this is where you're at, here is how you get here because we've done it. But not only have we done it, we can actually measure the trajectory and understand what the signs and maturity are.

Speaker 6: What I'd like to do is shift gears a little bit from the framework. What are the most common mistakes that you guys see people making as they go on this visualization journey?

Joshua: A lot of times when people ask that, I think they're expecting answers like, don't use a pie chart with 100 slices or good visualization practices and the mistake would be not using them. And I think that that's true, but that's at a very in depth level. The bigger mistakes I think that will almost certainly guarantee failure in a project are things like being stuck in a paradigm that isn't working and being unwilling to change. I think the idea that we're just going to implement this new technology and it's going to solve all of our problems. If you don't evaluate your approach to data first, and if you don't evaluate who needs to be involved and not just what technology should we apply to it, there will always be new technologies, but never has a technology alone solved a problem. It's always people who solve the problems.

Joshua: And I think that's the key, is figuring out where we are in that maturity model and figuring out where we need to go and those are the mistakes that we don't want to have. Another big one is the idea that we're going to have a one size fits all solution. I see this commonly with dashboards. Someone says we're going to have a dashboard that the salesperson can log in and see what they need to see and the sales manager can log into the same dashboard and it's going to be a little bit different because it'll roll things up and then the CEO can use the same dashboard, but it's have all this other logic that changes the chart types and it rarely works because you've introduced so much complexity thinking that one thing could meet everyone's needs and rarely is that true.

Joshua: Much better would be very simple, lightweight things that communicate exactly what the salesperson needs, exactly what the sales manager needs, exactly what the CEO needs. And at the end of the day, if you're going to deploy that a lot faster, you're going to come to decisions a lot faster rather than just trying to dump it out for everyone and hope that they can make sense of it.

Speaker 6: And I always say I want one dashboard to rule them all. It's like that I want one t-shirt that fits everybody. All your super skinny people have this thing that looks like a dress or a nightgown. Anybody above a certain size is squeezing into this thing. And then a very small share of people are actually comfortable and happy. So it really creates this tension that doesn't need to be there. And you can make everybody a lot more successful when you size appropriately.

Speaker 6: The other mistake I typically see is what I call the Pokemon effect, I've got all these reports, I got to port them all. It sounds like fun. It's a great metric to have because it's like, "Hey, I've got 99 reports over here, none over here. I'm going to port them all and we can track it. It's tangible. It's a clear benchmark, but it's awful because you made those reports on a very specific paradigm, much like Joshua was talking about, you move to a new platform and you're not embracing the reason that you purchased the platform in the first place, like you bought this so that you could achieve certain things. And then if we're porting over everything just as is, the shoe doesn't bit, and typically you're ending up having to break this platform in order to achieve a certain effect.

Speaker 6: It's very much like language is. When you learn a language, each language has its own grammar, all the words work within that grammar construct and everything flows smoothly when you follow the rules and it's hard. It's really, really hard. That would be my big ones is that, "I'm going to lift and shift them over," really, really ends up being very stressful and not as fun. It's much better to take that time, understand why I bought this, understand my key goals, have those rules. I mean any type of process or cultural change, we have these rules, no dry holes, we're not going to do this. When I deal with reports, I'm going to have these very clear roles of this report needs to meet the needs of two users or it needs to do this. So you want to make sure you're setting yourself up for success.

Speaker 6: I have one more question for you guys that I want to ask, but Bridget, you mentioned earlier data literacy and the importance of data literacy. Could we dive a little bit deeper into that?

Bridget: I have an article that talks about the whole scale of data literacy. So you've got inputs, you've got how we point it into the database and store model it. You've got the ETL transformational processes for my analysis, but then there's this really key part down here that we never touch and that is defining. And that is where I start going okay, I got this from Salesforce, I got this from this dropdown, I've transformed it so it's now five columns instead of one because maybe I wanted those five columns, maybe because multiple things can be true. So now I have five columns and I need to track that as I analyze it, as I output it. So that's that whole circle.

Bridget: And oftentimes we think one person can fill it all and that's a unicorn. That's somebody that's high ticket, high value. But again, what we want is where it's easy for people to go, okay, I know this field in Salesforce and I can find it here. Sometimes we call that data governance, but that's also data literacy. And data literacy is an ethics issue because if I can't find my data, I can't make the correct assumptions. And that defining piece is super key.

Joshua: It's one thing to be able to read a charter or graph, and sometimes that is the full scope of what people think of when they think of data literacy. And while that's a key skill, everything that Bridget said is true because all of the assumptions that go into looking at that charter graph, those are assumptions that are either right or wrong. And having the literacy to know what those assumptions were, are they right, are they wrong? That's just as essential, maybe even more so than the fact that I can look at a trend line and say, "Hey, sales are up." But where did that data come from? How did we collect it? How did we transform it? All of that is just as essential because anywhere in that process we may have introduced something that, "Oh, sales actually we're down."

Bridget: So particularly too with that, I mean we've seen this play out now where we are using charts more out in the public media. We are deploying more visualizations more broadly. So we are expecting audiences to be able to navigate that. So when you're not clear on these terms, it's a navigational issue. Just like health literacy is not, "Can I read and understand medical terms?" No, no, no. I have a broken leg. Do I go to urgent care? Do I go to the er? That is a navigational issue, and data literacy is truly a navigational literacy rather than a reading and writing literacy.

Speaker 6: Well, that's amazing. Thank you both for answering all the questions. How do you officially earn the moniker Zen master?

Bridget: So you're nominated, there is an open call. Usually these days it's closer to the end of the year. So about January there's an open call, you go out to the Tableau blog and you're typically nominated by your peers. You can also self nominate, but it's a pretty exhaustive form to defend, how are you collaborating? How are you teaching? How are you really making Tableau more accessible to others?

Speaker 6: Any tips for us assumed unicorns to deal with the well, how everything about data so fix it from the C-suite?

Bridget: I've been in that role. So some of this is a bit of what I would call bad behavior. And again, that requires a level of comfort. I worked at a place, I had a boss, I reported directly to the C-suite that was my boss. So COO would come into my office and be like, "Well, I need this thing in an hour." And it got to the point of me, I kept a con on board so that he was aware of these are all the things I'm working on and this is how long it takes. So there was a lot of very effective communication. But the other thing was, but a humor goes a long way. So yes, I did keep a hollow doubt grenade in my office because he would come in and throw the proverbial grenade in my day, and I made that clear.

Bridget: And we had an understanding of you aren't asking for something small, you are asking for something large. I'll do it but it may not be A, as fast as you like or B to that level because it I don't have the data. So there is that pushback. The other thing is I write a blog and you are free to share. Now keep in mind some it may be rendered as passive aggressive, but I mean I have even a post. I mean, it's a super silly post of full stack anything. And I recommend people send that because it just so that they understand you are unicorn, that is rare and the things you can do are not easily accessible.

Speaker 6: What would be the most underwhelming skill to have in terms of data analysis? Would it be more of communicating your findings to stakeholders? So I think the question is focus towards maybe where is a good valuable starting point skill that doesn't take a ton of time to acquire.

Bridget: I would say communication's actually a really key part because part of when you're doing requirements gathering, you've got to be able to get their mental picture. You've got to really be able to draw from them what they have in mind and what they have in mind it's not so much I want a line chart of I want this. It's more of understanding how they use it. So I'm going to do this decision. One of the things I've done before with people historically is, okay, I'm going to give you your report that you use today. What numbers do you circle? What numbers do you collect? What numbers do you highlight? And that helps me understand this is how you're using it, these are the types of decisions, and also following your orders. So you started here and everything is up here, but you're starting at the bottom because that's actually more important.

Joshua: The soft skills are just as important as the hard skills. So knowing Tableau is great, but as a consultant, we have to understand that communication and the interpersonal skills of reading someone and sensing, there's another question behind that question and thinking through how do we meet the needs and who's the true audience that we need to communicate to. I mean, there's a lot there, but skills that I think get neglected so much.

Bridget: I would actually argue the soft skills are more important than the technical skills because quite frankly, I can Google the technical skills. I can't Google soft skills.

Speaker 6: It's interesting. What are the key technical and soft skills to be a data analyst? I just want to talk to that a little bit.

Bridget: Backend data skills are, I would say particularly coming from the business side. You've got to have a certain level of depth with understanding the shapes of data, the many, many shapes of data and how data can be basic level. I mean, I took an online course that was free through Stanford. I mean, it was a real quick, here's your intro to databases and it was free, so I can't recommend that one enough. But then understanding what charts are and beyond just, okay, here's the charts, but then how they play together and how to make them work together. And that's part of what I'm writing my book on is how to make them work together so that people can draw a better meaning.

Bridget: And one of the types of guardrails you can put in and the soft skills, I mean it really is down to, can I hear between the lines? Can I really get to what you're doing? Design thinking and this term gets bandit about, but there is a Darden University course, and I strongly recommend that where they really go through this is design thinking. This is a process, it works. I literally have taken it and replicated it into Trello and run with it.

Speaker 6: What are some tips for communicating data literacy between business departments when each department collects and stores data in different processes before they eventually are funneled into Tableau? Joshua, do you want to start that one?

Joshua: That's actually a really good question, but a tough one too, because I've been in that situation where you've got different departments or different people, even individuals who are doing their own thing. And I think it goes back to that whole idea of understanding organizationally, what's the paradigm that we want to adopt or transition to or have everyone think about? So part of it could be training, part of it is adoption of common good practices, a common platform of technology. Those can be key things, but I think it is. Ultimately it's that communication of here's what we're going to do, here's why it's important that we're going to do it, and here's the ultimate result that we're driving towards. And I think once you give everyone that vision and that breadth, that's when you'll start to see people really buy into it that, "Okay. I shouldn't just keep my 2000 Excel documents in my own personal computer. I really do need to have this accessible and in a format that can be used because I understand why it's important and how it's going to be used elsewhere."

Bridget: And I would jump in and just say, the more you can put things towards a standard database, the better your life will be. As long as you're living in the Excel shop, it's really, really hard because you don't share definitions and it is that defining piece. So data governance covers a part of that, but a big part of that is really coming together, making sure that we share the same language and that we're collecting data and storing it in a way that makes it easier for us to get along and not harder.

Speaker 6: How do you emphasize the urgency and need of good data quality? For example, uniform registration, et cetera. Who wants to tackle data governance?

Joshua: Well, so coming at it from a data visualization standpoint, one of the most effective ways is just to show what the results are of bad data or missing data. So if I show someone, here's what sales looks like, but we have these gaps, here's what patient care looks like. But because everyone's putting in their own funny comments in this freeform text field, here's why we can't really use it effectively. And I think all of a sudden that starts to really illustrate. And if I take that to the key people, then I can affect change on that end. And all of a sudden a freeform text field becomes a dropdown with standard choices, or there's another way of possibly inputting that data so that it's usable. To me, that's the most effective way I've seen it. It's communication. I do it visually, but in one way or another, you have to take it back to the source and say, "Here's what it's causing. Here's the problem it's causing, and why we can't use the data the way it's coming through."

Speaker 6: All right. One more good one here. Did it take a lot of time and effort to develop a process of your own for understanding the data and presenting it? And how did you figure it out?

Bridget: So I learned to work with data trial by fire. I worked for a startup. I reported to the C-suite and very much learned on the job. So I would get a call, "Hey, can you find out this? And I'm going into this meeting in five minutes. Can you..." And so it was very much, I learned to do a lot of quick analysis so that by the time I rolled to consulting, I was very comfortable in the speed and I actually had to learn to slow down and I was given a whole window. I would go from, I have 30 minutes to make a dashboard, to I have a whole week. And I didn't know what to do with that. I was so tickled. I'm also very much a process driven person. I am the person that backs my car into the parking lot. So I'm always trying to figure out how do I build better? How do I do this better?

Joshua: I would say yes, it did take a long time. Just in the last couple of years, we have started to really formalize this process because I think up until now we thought we have the skills, we have technical skills, we have soft skills, we can do it, but we're each doing it our own way. So Bridget comes in and says, "Well, what if we really thought about some of the research that's gone on behind the scenes? And what if we formalize that and we put a structure and a framework that's reusable, that is efficient, that really helps us."

Joshua: So yes, it's taken a long time to get there, and then it's taken a lot of collaboration and a lot of work, especially on Bridget's part, to think through how do we really put this together as a process that works well and effectively and consistently. But I'm excited because I think we're actually at that point where we've got a process that it's exciting, we can take it places and we can really use it to help people.

Speaker 6: Do you have any thoughts on how to future proof against biased readings? Avoid common cognitive biases from users of interactive dashboards?

Bridget: I call that putting in guardrails. And probably one of the best examples I've ever seen was Layla Manheim did this scatter plot. It's the Hans Roslyn scatter plot, but then she put in beautiful annotation and all this detail on demand to really help facilitate the understanding of this is what this means. Part of what we're writing about in our book is around ambiguity and part of how those biases happen is ambiguity. So the more we translate, the more we make things a little bit more tangible and share those definitions.

Bridget: So it's back to that whole data literacy piece and defining and making sure that when I say this thing, I understand what it means, but that too, I'm also understanding where that person's efficacy level truly is. So that as they see the line chart, line charts are actually fairly abstract is what I've found. So helping facilitate people and understanding what's going on with that line chart.

Bridget: So those are some of the tools. Sometimes it's annotation, sometimes it's extra charts and really looking at this from the end user side, how are they interpreting this? I also road test. I am a big, big fan of, "Okay, I'm going to give this to you, you and you and I'm not going to teach you how to use it. I'm going to let you click. I'm going to watch you, and I'm going to have you verbalize what you're thinking and understanding so that way I can say that's where the problem is."

Joshua: And communicating the uncertainty is key. If there's something where we have 90% certainty that the data tells us this, we can't show it in a graph as 100% certainty. We need to visually or otherwise communicate that level of uncertainty. If there are gaps in the data, we need to make it clear that there are gaps in the data and not present it as this is absolute truth and absolute certainty when it's not. And that builds trust that also avoid some of those biases that can creep in when I'm looking at something and I assume that it means something that it's not so certain that it really means that.

Speaker 6: All right. One more, we'll wrap it up. What are the most essential soft skills you have found to help to implement positive change?

Bridget: So it's a combination. I actually rely a lot on my interpreting skills and it's analyzing mood intent, looking at the setting itself and understanding those cultural barriers because the reality is how change doesn't happen is because either I'm scared, I'm overwhelmed. A lot of times when you think about Six Sigma, I mean they go through a lot of training is really the worst way to make change because by the time you're training, everything else has failed. So you really want to fix everything before you get to training. You want to make sure your visualizations have appropriate guardrails, that you don't have to train on them. This doesn't mean you can't make complex visuals. It means that if you make something complex, people have enough ways to learn how to use it without you there.

Bridget: The other thing is there is a book Switch by Chip and Dan Heath. I cannot recommend that book. I have three books I recommend often, and that is probably the number one book I recommend. And the reason is because it talks about how do you make a change? It talks about directing the writer, it talks about motivating the elephant, but the other part is it talks about shaping the path. And I really like that book because you can really look at your organization and understand where is the problem. So do you need to motivate the elephant? I worked at a place I had to make people raging to get anything, and so I learned. But your organization may not be that way. It may need the path shaped, it may need more logical appeals.

Speaker 6: All right. I know I called the last one, the last question. If you guys have time there's one more. It's really how would you tackle a situation where you have a predefined prototype coming from your customer and stick to that? Less scope for innovation, very limited time, facing challenges with a gauge chart which isn't built into Tableau. What do you guys think about that one?

Bridget: So I call that design to spec, and it's really hard when you get these design to spec, particularly when they are not designed in the tools. So it's very much, "I want this type of business structure." When we do architecture, we do these land surveys and you go and you make sure that the ground can hold the structure you're putting on it. So you don't want a super tall structure on a really sandy area. And I consider this very much the same. I'm architecting a solution on a platform it rarely wasn't designed to work on. I spend a bunch of time trying to arm wrestle people the other way. Josh was probably a little bit more forgiving. I really try to get people off of it, and I will sometimes do bad behavior of, "Hey, here's a bullet chart. I can make this. Here's this, I can make this and here's this, I can make this." I really, really try hard not to.

Joshua: Yeah, no. I really like that approach of giving options. So yes, I was asked for a gauge, but here are some other ways you can see the data. Eight times out of 10, they'll look at it and say, "That does make more sense, or that does work." There are times when it's not going to be flexible, and I think that's one of those soft skills of understanding when is there some flexibility and I can push back when is there not going to be flexibility and I'm just going to have to make it work however I can make it work. Sometimes the answer is it's not going to be possible. If I have a limited amount of time, a limited amount of budget, and you want this, it's not going to fit in that time and budget. And it goes back to that communication again of just being open and honest and saying, "I can't do it. If you want to add 40 hours, then sure, then I can make a gauge for you," but otherwise we're stuck with this and this is better.

Bridget: And I find analogies help. So the more you can find comparable analogies of in architecture, we have to do a land survey, we have to do these things so the building doesn't fall over. You don't want that. I try to find these comparables particularly that work with the industry they're working in because then that's speaking their language.

Jess Carter: Thank you for listening. I'm your host Jess Carter. And don't forget to follow Data Driven Leadership wherever you get your podcast, and rate and review letting us know how these data topics are transforming your business. We can't wait for you to join us for our next episode.