Today I had the pleasure of interviewing Thomas Watkins. Thomas is a thought leader in the User Experience space, a speaker and industry practitioner located in Houston TX. He is a life-long learner who has a passion for bringing greater clarity to the world. Thomas has made it his career’s focus to combine technology with design psychology in order to drive business success. He specializes in helping his business partners bring their own brilliant ideas to life, by translating complexity into simplicity. The scope of his work has included interface design for mobile, SaaS system architecture, usability research, and data visualization. In this episode we take a dive into the user experience field, we learn about human factors research, and we explore how data analystis and data scientists can improve their data visualization by applying some psychology principles. I hope you enjoy this episode, I know I had a great time speaking with Thomas.
Today I had the pleasure of interviewing Thomas Watkins. Thomas is a thought leader in the User Experience space, a speaker and industry practitioner located in Houston TX. He is a life-long learner who has a passion for bringing greater clarity to the world. Thomas has made it his career’s focus to combine technology with design psychology in order to drive business success. He specializes in helping his business partners bring their own brilliant ideas to life, by translating complexity into simplicity. The scope of his work has included interface design for mobile, SaaS system architecture, usability research, and data visualization. In this episode we take a dive into the user experience field, we learn about human factors research, and we explore how data analystis and data scientists can improve their data visualization by applying some psychology principles. I hope you enjoy this episode, I know I had a great time speaking with Thomas.
So if you're ordering food on Uber Eats, the fact that you're using an app to do it should mostly kind of fade in the background as you're using it and your experience is thinking about restaurants and you're scrolling through the list and these are the available restaurants. Then you tap in, you open one. Now you're thinking about menus. What is on the menu? What's available? And you are kinda making a selection, thinking about food... This episode of Ken's Nearest Neighbors is powered by Z by HP, HP's high compute, workstation-grade line of products and solutions. Today, I had the pleasure of interviewing Thomas Watkins. Thomas is a thought leader in the user experience space, a speaker and an industry practitioner located in Houston, Texas. He's a lifelong learner who has a passion for bringing greater clarity to the world. Thomas has made it his career's focus to combine technology with design psychology in order to drive business success. He specializes in helping his business partners bring their own brilliant ideas to life by translating complexity into simplicity. The scope of his work has included interface design for mobile SAS system architecture, usability research, and data visualization. In this episode, we take a dive into the user experience field. We learn about human factors research, and we also explore how data analysts and data scientists can improve their data visualization by applying some psychology principles. I hope you enjoy this episode. I know I had a great time talking with. Thomas, thank you so much for coming on the Ken's Nearest Neighbors Podcast. You have such an, such an interesting background in UX and and design and integrating that with data visualization is something that I'm personally very interested in. You know, how does a designer build a visualization that can phase useful information? How can more maybe traditional data scientists apply that in their own work? So again, I'm super excited to have you in here and I'm excited to hear your story. Thank you. Excited to be here. Amazing. So the first question I always ask guests to sort of get everyone at a grounding point is, how did you first get interested in data? But I'm also interested in how you got involved with UX in the first place. Was there Yeah, so moment or was there a was it sort of a slow progression? Yeah, so it was kind of a slow progression. I came out of, you know, psychology, so I majored in that an undergrad and was super interested in it. And I ended up taking a route into industry because I happened to when I went to graduate school, I went to a school, George Mason, and it was a human factors program and not just kind of a straight psychology program. And this was become before UX became huge. Usability had been around for a little while, but it wasn't like a huge industry that we see today. And so when I got into that area of the field of, you know, kind of applying psychology to industrial needs, that kind of brought me into UX and I. Fortunate to be introduced to it kind of early. And I would say that my introduction to data was being in graduate school for, you know, kind of a long time doing psychology experiments and things like that. It required me to work all the time with data, right? So you run an experiment, you collect data on a machine you know, back then you're taking off the data with a, you know, on a floppy disc, you loaded into a stats program and you try to gain insights out of it. Out of years of doing that, I got very comfortable with data. Later in my career, I specifically started studying and really getting into data visualization and then from there trying to evangelize data visualization because to me it didn't make sense that so many UX professionals and try to think your listeners know what UX is, user experience design making interfaces easy to use. It didn't make sense to me that UX professionals didn't do data visualization and that seems to. Be something that should fit into the wheelhouse. Cause you're kind of doing the same thing. It's kind of the same goal. Right. So that's a little bit of history on, on my background and that it was heavy on the psychology, the data, and then, you know, kind of, you know, when I started my career and, you know, doing digital products, designing for that, bringing that kind of thinking into it. That's, that's awesome. And thank you for sort of level setting on what UX is. That's something I forget to do. I think. Like, Oh, I know what it is. Everyone must not, I mean, yeah, you never know, it's not always the case. Do you mind doing the same thing for human factors? That, that's a term that I've heard before. I'm personally not familiar with exactly what that means. In comparison to like a field like psychology, you know, is that something inside of it? Is that something that's parallel? Can you just sort of give me more that? Yeah, sure. So human factors has its history. Kind of gets to become really a recognizable thing around, you know, World War II, where the, you know, military realized that when you design things that are for the soldiers and for people who are gonna be using the equipment, submarines and airplanes and things like that, you get a lot fewer plane crashes and a lot greater efficiency when things are actually designed around the person, which contrasts with the previous view. Right? The previous view is you're here, you work for us, you learn the machine and figure it out. Right? But then that... Is this the famous I guess like case study of. World War ii, the jets where they decide for the average person, and not everyone, like, like a small percentage of people, maybe like 5% is actually average size. There's this huge distribution. So rather than having all the seats the same size, they made the seats variable. So that, and like that huge. The whole. Yes, the whole philosophy and approach. It's stuff like that where, yeah, we have this word, we say average, but then like how many people are, you know, average and, and things like that. So you get into ergonomics, right? And ergonomics of, of course this, designing things for the human body. But then the other side to this, the psychology aspect is designing things for how, what we know about people and, and how the mind functions, right? So the sensory, perceptual, cognitive attributes of a human being. How do you design for this so that it's a shift in the mentality. And so you can even look at the word human factors. What is the human factor in this overall setting? Right? So you're, you're, you're looking at a whole situation. There's gonna be, you know, we have a room, you have a machine over here that people are gonna be using. It's got a chair next to it. The human is the, is part of that, of what factors into that. So you've got a human factors expert. The rise of that, which is these are folks who, who know all of those things dealing with biology and psychology that are gonna come to bear when you're designing things. And then that's how you take that knowledge and you engineer it into the things that you're designing and building so that you get better outcomes. That's, that's so fascinating to me. And, and so I understand the ergonomics, like from a conceptual perspective, right? Can you give me an example of like a psychology, the psychology side of that? Like, I don't know if it'd be like, oh, street lights, where we have the top is red and the bottom is green, and it's like, I don't know if there's something cognitive about that. That's a good one. That's a good one. So if we take, if we take street lights for folks who are not colorblind, they can see the difference between the red light and the green light, and then that maps onto a certain meaning. And so but if you have it on the top, One on the top and one on the bottom. Now you have a redundant attribute. So say folks who are colorblind, they have still a way of seeing which light is on. And for folks who are not colorblind, you have an extra redundant piece of information to kind of help you to help you do that. Another thing, while we're talking about street street signs, if you compare the street sign, That are on mostly the West coast and East coast. I don't wanna generalize, but I just took a trip up back up to Boston to visit my parents. And the street signs are very small. They're kind of legacy little green. They're like on a plate, they're on the side of the street. You can kind of barely see them. Whereas I don't know if it's all over California, but many parts of California that at least I've been in, you know, the listeners will know if they're from California. Big hanging street signs right in the middle where you don't have to fight to see it. You could see it from way down the street. Further away it's taking into account like, look, hey, people who are driving down the street are gonna have to see this, so let's put it big and in the middle to where it's easy to make navigational decisions and to see necessary information while you're driving, instead of having it to be something that you have to hunt and look for. That's so cool. There, there's actually a very small tangent, so I've gotten really into, on YouTube. There's this. It's like a sport called, I forgot what it's called. It's like geo tracking or something. And people, they're shown random places on Google Maps, and then they have to go on the map and select where it is. And one of the things they use, they look at street signs, they look at lamp posts they look at license plate, they look at like a lot of different things. And like the street times is one of the most characteristic things to tell you where you are. Which, you know, it's, it's, it's a very interesting thing to see how that's evolved in different places and the meaning, you know, I would imagine in China or in Japan, it's very different because things are read in a different direction and those types of things. Yeah, I would imagine that plays into how they designed them and those types of things as well, from your perspective. Yeah. Yeah, absolutely. Here's another example from what you brought up maps. So you, you know, if you look at Google Map, . The, there's 20 different zoom levels of altitude that you could look at Google Maps, and if you look at the information that's available, different information is available as you're zooming in and out. So what country you're in versus continent versus whether the street signs are showing. And what they're doing is they're managing the amount of clutter that a person is going to be faced with. So they're anticipating what type of information is important at this zoom level and let's provide things for that level. So, so they're taking the giant databases of information. You have a massive amount of information, but they're selectively showing and not showing. Different information based upon what they anticipate will be important at those different stages. And it's not just the names of things, it's the level of detail in, you know, the terrain, the streets and things like that. So by careful use and application of what we know about the human perception, how people are gonna be using this tool and this particular situation, we can create a great experience to where when you're using Google Maps, you don't even, you're not even really that aware that you're looking at a map. You're kind of, you're kind of pull the map, the fact that you're looking at a map kind of fades into the background and your focus goes immediately to the entities that you're looking for. If you're looking up a restaurant or you know what you, you're trying to map out a route for a driving trip, you're fo you're able to focus on that because they've done such a good job at making the less relevant stuff fade into the background and surfacing the relevant stuff for you. It's funny, we haven't even started talking about data visualization., there's a massive lesson in what you're just describing in that it's, it's as much about what you don't include as what you do include, or what you don't show in a visual as what you do show, because you want the stuff that is important to show and the stuff that's irrelevant to sort of fade into the background. So, we'll, we'll save those lessons for a little bit later, but I like how that, that sort of just bled into something that's gonna be very relevant in, in a little bit here. So I'm, I'm interested in how you pivoted the human factors, the psychology, the design, the UX into a career. What has that looked. From when you first started to sort of where you are now? Yeah, so, you know, kind of my path is, you know, I came out of school kind of heavy on the research stuff, went straight into the, so UX kind of has these three big areas. One is research, right? So that's the folks who know how to validate stuff, set up research experiments, and kind of tell the business what is important for us to know about our users, how well is our product doing or not. So that's the whole research side to usability. Then you have on the other end you have visual design, right? So a lot of folks with an art background and they know how to really close the loop on the user experience with making sure that things can visually resonate with their users. And then kind of in the middle it's, the skill set is called information architecture. Basically. That's the problem solving the the taking of. All the concepts and figuring out where they belong. So going to the Google Maps example is, you know what do we show at certain levels? There's a massive amount of information that's available in the backend database at any one point in time, what are we showing and what, where does it belong? So every app that you use, it's someone has to kind of make that decision. Over the course of my career, I start off mostly kind of, Do you mind if I ask that? So between those three sort of different groups, do you know roughly like proportionally across the field, how many d like what percent of the population of UX people fall into each of those? Right. So for example, in in data science we have like researchers who are very, very small portion versus like data science practitioners who are a large proportion and also data analysts who are a large proportion and probably data engineers who are large portion. But I'm interested within your Right. So I think, I think the lion share is gonna be. UX designers in the industry. I think the reason for that is that a business definitely knows that they need the better. If, if they come to the realization that they need UX at all, the first level of re realization is probably going to be that they need better designs. And there's kind of like a stages of realization for a lot of businesses. But for example, before folks understand ux, they think that it's a visual problem. They'll know that, they'll say, Well, you know, our product's hard to sell and, you know, we're getting beaten in the marketplace. But they also know that their product is ugly, like aesthetically ugly, and they think that it's hard to use because it's aesthetically not pleasing, and they don't realize that there are deeper. Kind of problems. So, but there's plenty of interfaces that are ugly and good. So maybe know Craigslist has decent usability. You know, I think that it just links and it is not particularly beautiful, but it gets the job done. And so the vast majority of folks though, are somehow on the design end. So designers, the word designer includes both the visual designers and those information architects that that I mentioned. And so the output of those folks, that's usually the wire frames and things like that that you see where you're working out kind of the high level structural stuff. Like, okay, we have a screen, The screen has a sidebar for navigation, It has this kind of middle area or this tiles of objects that appear in the middle. You know, so if, if you, you know, go to Netflix for example, you might imagine a wire frame for that being like, A screen, and then you've got like the rectangles that represent, here's where the movies are going to play. Right? And then, you know, when you map mouse over a movie, then it's gonna start auto playing a preview for it. And then that would be like an interaction design detail that's mapped out of the specifications. And when you click on a movie, that's when the full screen mode happens. And the now you're in the movie. And if you want to get out of the movie, you can click the three dots on the side and it shows you, you know, or, or episodes in a show, like you can switch to another episode. And so designers have to work all of that out. What is a person gonna see when they log in? What what happens when you click things? Where do you go? Do you go somewhere? Or does something just pop up? And all of that has to be, that user experience has to be thought through to make sure that it's a, that it's a good experience. And businesses realize that, hey, we really, really need this. And it's people who are not ne necessarily experts in the area. So you don't need to be an expert on movies or showing movies online to work at Netflix. They would want someone who has the ability to kind of figure out what are the problems that our users face, and then how do I give them the right kind of solution. And then researchers, there's a lot of researchers, but that's much less. A lot of times they will tend to be more educated you know maybe professionally trained on how do you do kind of research methodology. How do you deal with data? Some folks have maybe a regular college education and their researchers. Oftentimes that means they might have a lot of experience in industry with doing lots of research. A lot of 'em you might see have master's degrees or higher PhD, where they're really comfortable with data, they're really comfortable with. You know, if an expert says, Hey, we wanna figure out why people are not using our service anymore, or we want to figure out we're wondering if a yellow button or a blue button on the front page will drive greater conversions or we're just starting our product and we wanna know what people, you know, what's gonna be right for our users And our target market is you know construction workers are who are gonna be using some app while they're on the road. You know, how, what, what is the thing that's gonna fit their world the best? So you would have researchers who know how to ask and interpret, you know, the right research questions, design the way that you would find the answer to that, and then be able to conduct it and collect the data to process the data. So it's this whole huge field that's really based upon. You know, how do we make things easier to use? How do we make digital products resonate with users better? Part of my story is you know, there's different kinds of work that you could do. You could, as as a UX professional, researcher slash designer, you can work. How set a company, I think this is probably the same, really for data science to a large degree, right? You can work in-house at a company and be a designer working on a product, right? Who's vending and building a product. You can work as a consultant where you are not a part of that company, but you've got a contract that covers a certain scope. I worked for both of those kinds of things and I learned a lot about what companies seem to be kind of doing right and doing wrong, and, and you know, where things fall through the cracks and, and, and the different, the nature of the different designers, right? So you work in, in house at a company, you end up with like very deep knowledge about that use case, about that area of of of the market versus if you're a consultant, you get this kind of nice dabbling and a lot of different types of problems and you kind of get good at like, you know, problem solving, but you may not have as much of the full depth as the in-house designers. So there's this kind of interplay there. So I did a lot of that for my first few years and then I jumped into working for startup. And then that's a whole different animal for those who have, you know, worked for startups. You get a bunch of unique challenges there. And that's kind of like, that's kind of like my happy space. I kind of like dealing with that. So where it evolved to where I eventually I have a consultancy now Three Leaf Consulting where we deal largely with startups and with in cases where it's not a startup, an established company that's doing a digital transformation or trying to build something new or revamp the way they deal with their digital products often internally. So so yeah, that, and it's a great opportunity in those kinds of situations to really apply that kind of design psychology knowledge to the space and, and, and really get to figure out those problems, you know, from the, from the bottom up. This episode is brought to you by Z by HP. HP's high compute, workstation-grade line of products and solution. Z is specifically made for high performance data science solutions, and I personally use the ZBook Studio and the Z4 Workstation. I really love that Z workstations can come standard with Linux and they can be configured with the data science software stack. With the software stack, you can get right to work doing data science on day 1 without the overhead of having to completely reconfigure your new machine. Now back to our show. So what would be your spec, your own maybe design psychology philosophy as it relates to startups or the companies that you work with? Yeah, so as it relates to overall, you know, the design psychology, we wanna remember that the whole purpose of us dealing building technology in the first place is that we're designing it for humans. So that's where you get user center design, humans centric design that a person is at the intersection, at the, at the center of all of this stuff. The. Intersection between the technology world and the human, the psychology world is that interface that you're designing, right? And so one of the ways I look at this is that, you know, humans have this am you know, massive amount of technology and data that's being collected all the time that we've kind of built those systems for ourselves. Well, we have to interact with that data somehow. And so we use it in every aspect of our lives. Now, whether we're ordering food, whether we're figuring out where to go for vacation, whether we're figuring out how to drive or navigate there, we're intersecting with this all the time. And so that interface is what you're designing and what you're really trying to do is make it so that interface is as invisible as possible and that the human, the user is directly dealing with the problem that they're trying to solve. So if you're ordering food on Uber Eats, The fact that you're using an app to do it should mostly kind of fade in the background as you're using it and your experience is thinking about restaurants and you're scrolling through the list and these are the available restaurants. Then you tap in, you open one, now you're thinking about menus. What is on the menu, what's available, and, and you kinda making your selection. You're thinking about food. You're not dealing with a bad user experience. A bad user experience pulls you into thinking about the interface. You're like, Oh gosh, why is this button here? Or where do, Where the heck do I click in order to do this? Or how do I find my, you know, X, Y, and Z? That's when you get pulled into thinking about the interface itself. Good design is that you're making that stuff as invisible as. And you're serving up the relevant things that you want people to think about. This is a direct interaction with psychology. Cause in order to achieve this, you have to know a little bit about how do people notice things. So the sensory process, what do people attend to? If people have to remember something from one step to another, you wanna memorize, you wanna minimize that because working memory is li limited to four plus or minus one items. If you are you know, you don't want people to have to think too much or do too much problem solving that doesn't relate to what their task is. If you're ordering food, all of the thinking should be on what do I want to eat? What do I wanna order? Am I ordering for someone else? All the thinking should be there and not on your interface. And making that fade into the background is really what design psychology is all about. And then, you know, if you're dealing with a startup, you have the additional kind of strategic question of. Where is, you know, going back to that kind of analogy or that, that concept of there's the technology side of, you know, our existence, and then there's kind of the human side, and then there's that interface. That's every time we pick up a phone, every time we sit at a computer, every time we talk to our Alexa or voice interface, you're interacting with some kind of interface between you in that data world. And so for a startup, you might think about, okay, where is there a piece missing? Where is there some friction in that human interacting interaction with this technology interface? Where is an opportunity where I can add value to people's experience? To me, that's such a an overlooked concept. You, you mentioned friction, and I really like that term. Someone described good UX to me as frictionless. Essentially, you're, you're supposed to get from point A to. Point Z Z wherever it is, without realizing you're there. It's an anonymous, it's, it's, I mean, it could be beautiful, but it doesn't have to be beautiful if it gets the job done. And, and to me that's something as we segue into data visualization, I'm very interested in how you apply that specifically to that domain. Can you expand on that a little bit for me? Yeah, absolutely. So with data visualization, I, you know, I like to take the, I kind of think of myself as coming from the school of Edward Tufty and Steven f Edward Tufty. And Steven Few did a really good job. There was a couple of folks, cartographers and things like that who worked things up, you know, before them. But they are I think are the two big shining lights. Who basically said, Look, we're gonna take a, we're gonna take an approach where we're getting at the point of data visualization. The whole point of this is to communicate a lot of times in my data visualization classes, I'll outline these three different mindsets that I've often seen when it comes to approaching data visualization. Some folks approach it as a pure, there's the technologist approach, artist in the communicator. So the technologist approach, and you need it, It's absolutely necessary. The main goal is I need to get this thing working right? I've got this data. It needs to be visualized or rendered on the screen. That's a whole bunch of effort that is just, you know, is required for that. But if we get lost into only rendering it or, or that the big victory is I've rendered this graph on the screen, then we're missing out on some opportunity there. Right? Then there's the approach of the artist. It's folks who want to basically, Express themselves with the data. And it's not, this isn't literal artists, right? So this isn't, I'm not saying this is a problem coming from graphic designers, it's usually coming from like, you know, managers and folks. And they'll, they'll fall in love with a certain type of graph and they say, Well, I wanna see a diagram on this page, or I wanna see we should have, And they're thinking first about like, the visual that they want. And it's, it's, okay, well what's the role of the data in this? Is the data just kind of, is, is it just the paint that you're painting? You know, is, is it just, you're, you're basically making data art at that point? That's a distinction to data art versus data visualization. So telling, because I have, I was thinking of a joke about violin plots and people get falling in love with those, but, I'll save that one for later. I wanna hear about the violin plots, maybe... But some of it's data art, right? Yeah, exactly. Well, the violin plots look a little bit anatomical in, in some ways Correct. They're, they're correct. Yes. Yeah. You why find them very visually appealing? Right. And people just like them, right? There's innate reasons why we find things visually appealing, but, Yeah. But, but, but, so, like data art, data art is, you know, it's beautiful, but it's misguided because that the main purpose should not be to entertain people with an image that's inspired indirectly by data. You wanna communicate it, right? There's a lot of insights. As human beings, we need to constantly benefit from insights in order to make decisions. Our decisions impact ourselves, the impact other people. We want to do the service first and foremost, of delivering data in such a way that people can interpret it, that people can consume with it, and that it actually helps out their you know, what they're trying to do with it. So, I would say that that is kind of the guiding approach to data visualization that I certainly advocate is that, It's that psychology first and the human centered approach first. And so that's the communicator. The communicator. That's right, That's right. Yeah. Yeah. So let me Yeah, do a little bit more on the communicator. So the communicator, the way to think of that is you, you're translating, so you're taking, you're starting from the language of math, statistics, the language that the data exists in, and you're translating that into the language of the human sensory, perceptual and cognitive system. And so when you know some things about that language, like where better at judging the location of dots or lengths of lines, then we are at judging the volume of areas. Then you're able to map that onto specific design decisions about, okay, what graph are we gonna choose if we want people to just compare quantities? Right. It might be just a simple bar graph is, you know, the best thing to do. Or you might say, Okay, if I want people to see the shape of the data, because you know, it might be just a line graph, the shape of a data the data over time, you know, you know, line graph really, really does the trick for the most part. And so that's the translator. That's the communicator. You're saying, what are, what does the person need to hear about this data? What do they need to see? What insights do they need to get? And then how do I take this data and translate it in a way that they're seeing it to support those types of insights and that type of thinking. That's the communicator approach. So, it seems to me like I go through all, all three different approaches, like in at different points of time, right? So when I'm first working with the data, I feel like I'm the technologist. My goal is to essentially get a graph out that works. and then I'm like, Oh, I have this graph. It's probably not gonna convey what I want. I'm either gonna improve it or I'm gonna send it off to get some feedback because I don't wanna do too much extra work. So if like someone can tell me if this graph is, is okay , and if it's okay, great, but most of the time it's like, Ken, really? This is . But, but we get that feedback and then towards the end there's some of this artistry where it's like, Yeah, this, this graph conveys useful information, but how can I make it so that it is like people will wanna read it for longer maybe because some of the details, I think, you know, the artistry is probably, maybe a 5% of the time it's useful where, you know, perhaps you're building an infographic related to related to something you're trying to convey or advertise or whatever it might be. I would imagine artistry, if you're appealing to a broad audience, Who isn't familiar with the, with the data to begin with, there would be some element there. Is it okay to have some elements of all those things in the final product? Or, or, I mean, obviously I think the focus obviously should be on the communication part, but is it, you know, someone might be like, Oh my God, I'm a technologist. I'll never change. To me there there's sort of blurred lines between those things. Does that, does that seem in line? Yeah. No, no, no. So, so they're definitely all necessary. Like, you know, you as a data scientist and you doing the technology, you absolutely have to visit that technology plays, and then you have to care about aesthetic or you want to care about Aesthetics will get to that in a minute. But the focus here is that at least that, that design, that communicator hat exists at a certain point. So if, if you sit down and you at at least some point in there, probably at the very beginning, I would say, because it also can impact what type of data you even choose to collect or what you choose to do to the early stages of treating the data. You know, design thinking before that is awesome. And then design thinking as you're actually deciding, like, Okay, how is this stuff coming together? But no, but you absolutely can, you know, do all three, but as long as that head exists. So if you have a design a data science team, and if putting out visualizations is a big part of your delivery, I would encourage folks to think about at least one person on that team who is responsible for wearing the hat, even if they're not a full time just doing that. Someone on that team who's thinking about, okay, is this communicating the data in the best way that we can? And when we get to aesthetics, oftentimes, you know, you know, what I would encourage people to think about in terms of aesthetics is make. It looked good. That's fine. Without adding noise, that's the big problem. The big problem is that a lot of times when we approach aesthetics, we go to decorating, right? And trying to add piza, and we think that the data's boring. Now, one comment on that is if the data is relevant to folks, they are not gonna think it's, it's boring. I like to give this example is, you know, if you opened up your bank account one day and, and normally is not a very big bank account, but you see a million dollars in there today you don't need the word or the, you know, the letters, you know 1 million to be dancing around or to be flashing or to be colorful. You don't need it, any kind of decoration in order to be excited about that number because it's relevant to you, you know what it means, and it, and it's an impactful thing. So if we're talking about, say, dashboards, Where there's a certain user or job role who looks at this dashboard. If you've done the right job, you know, a good job of curating the right data to show this individual and that it's relevant, impactful data for them, you don't need to worry as much as you might think about giving it possess or making it more interesting. And they're gonna get bored with it. They're not gonna get bored with it if, if it's relevant to them. And folks would be surprised how far a good color palette will go in terms of making things look good. Right? So picking modest colors, simple color palette in order to get the aesthetics that that really gets you there most of the time. So you know, it, I think it's really relevant what you mentioned about if, if the data's relevant to an individual person or the users or whoever it might be. Can you tell me about how feedback or. A conversation with stakeholders and users, where does that fit into this whole data visualization process? Yeah, so this is, this is an interesting topic because when we look at a data visualization there's kind of two mindsets that you could look at it with. There's the demo mindset, and then there's the actual practical user mindset. A lot of times when we're reviewing this stuff with stakeholders, a stakeholder who's not using the data visualization might look at it and has a reaction to it or has ideas about what they'd like to see on the data visualization. This is not a required, this is not a required, this is not a reliable way of judging a data visualization. What you really want to do is get somebody in front of it who would be using this, this kind of data, and ask them questions that they would have to answer as their regular job. Right. So you might say you know, to a sales associate which sales channels are doing the best and which ones need the most attention? Or, you know, you might say to the marketing person, How are our marketing dollars translating to new business opportunities? Are, is it doing a good job or is it not doing a good job? You wanna ask them real questions and see their ability to use these visualizations to help answer those questions. You might find things along the way. You might find that people. Kind of start to interpret the visualization, but they have other questions that are very, very adjacent to the data that's being shown. And you might have an idea like, Oh, you know what? We need to show, We need to show an actual scatter plot to show the correlation of the marketing. Do dollars to the, you know, to the opportunities because this person is a high ranking person with business decisions. They need to see the correlation. Or you might say, Well, this is a tact tactical level person who needs to make these execution decisions and I need to support this, this, and that. So if you've done a good job on it, oftentimes you'll find is that the person will just start using the data, that they'll just start exploring it. You put it in front of them, they'll say, Well, wait a second. Those numbers, they really shouldn't be that high. Cuz if they're that high, you're really in trouble. And then they, they start just interpreting the data. We get to that interface disappearing in the background effect again, right? Where they just start seeing and experiencing the data directly. They're not really trying. They're not spending a whole lot of time parsing the data like that. So so I think to, you know, the earlier point about, you know, careful about stakeholder interpretations who are not gonna be using this, a lot of their comments are gonna be built on preferences, right? Visual preferences about graphs that they maybe wanna see is that, well, I wanna see a pie chart that shows the, you know, X, Y, and Z ah, that's not really the most useful thing to put on the screen, right? And then this kind of, that balancing act, right? We, we, we've all been there if we've if we've had to deliver these kinds of solutions to folks. But I would encourage folks, like in those conversations, try to drive the conversation around the user needs. Maybe if you do some testing before those kind of stakeholder conversations, you can bring the data with you. You could say folks who. Saw this, they were able to make really good use out of this bar chart at the bottom or this dot plot. People were us able to use that to answer key decision questions that relate to their job and, and their work when using this visualization. And then oftentimes that can help to override, you know, somebody has these really specific preferences that don't really, you know, maybe are not as important. Yeah. Well, you know, something I really liked that you said in there was you emphasize the importance of essentially focusing on the use case. So you, you know, you're not asking, do you like this? Do not like it. What, you know, you were, you were focused on, Oh, how are you using this? It's very action oriented and to me that makes it a lot more immersive. It shows you are essentially forcing them to use it and give you feedback from the use case rather than just focusing on the aesthetics. and I think we end users get so wrapped up in the aesthetics, they lose sight of if it creates value or not, and it's really hard to get them off that, that track. So your approach that you're describing there to me is something I haven't really thought of or heard of before, but it makes so much sense. Yeah, and, and, and it, it comes naturally. You know, could, as a UX profess professional, I do usability testing and usability testing on software that in, in that realm of software design, it's much more normal than it is in data visualization as a practice. If you're making a shopping website, you know, and say, Hey, what do you think of this website? And kind of click around through it. No. You sit down a user and you say, purchase a gift for your niece. And then you watch them try to do it, and they click on things and they search for things and they, you watch them and then you find out, Oh, here are the pitfalls. They're not seeing this important thing that they're supposed to be seeing. Or they misick, they were supposed to click on this part of the screen, but they clicked on a, on a different part of the screen. Or there were some stumbling blocks in the checkout process when they were in their shopping card and they had to fill out some fields. And you notice those real objective things. And then you go back to the software and you fix it. You know, taking that same approach to data visualization, we can do the same thing on, on this side of things too. We can test it. Take someone who is a person who's gonna be, you know, who's a proxy user, they represent the target population of users, Sit 'em down and see, can they answer key questions that they realistically would have to answer if they're looking at this at this visualization. So that, that's a really good lead in to another sort of question that I had, which is around unarticulated needs. So that seems like a way to parse out if the user's not necessarily telling you, it's not intuitive, but you're seeing that it's not intuitive. A lot of the times end users will have something that they want, but they don't know that they would want it. And how do you find out those things? Because they're not gonna just tell you. Excellent. So this actually also gets back to a lot of you know, so folks who wanna learn a lot about this, you'll want to see how to interview users. So there's certain ways that you ask questions. So you, you won't necessarily say like, Okay, what are the most important features that this app would need to have in order for you to use it? You might be a little bit more roundabout, you might say in your job role as a person who inspects damaged buildings tell me about a good day. What, what, what, what, what happens if, if the day go? And then you're gonna hear a lot of, you know, stuff about like, well, you know, it's, you know, if none of this happened, now tell me about a bad day. Then you're gonna hear about obstacles. Or, Oh, this, you know, pain keeps popping up. And these will be things that maybe wouldn't necessarily come out of another type of line of questioning or dis or discovery phase of a project that they wouldn't know to list those things. But you kind of want to hear all of those things that a person doesn't know is relevant. You want to kind of triangulate your way to the answer by asking questions to learn about their motivations, things that impact their day to day life. So instead of saying you know, what does your job role. Entail, you know, you know, what, what are your job role responsibilities? You know, you might get kind of, they list sort of a bullet point list of you know, what they think they're supposed to say. Instead you might say like, Okay, so. What what is your job judged based upon, or what, what worries you during the day? And you might hear different kinds of things. You might hear them say like, Well, I really don't wanna look like a fool in front of the clients. And a lot of times when I'm doing these financial reports, the numbers might end up wrong because it's so difficult to, you know, calculate them. Okay. Tell me a little bit more about that. Well, when I go to this table, I have to translate things from the contract terms to the way that the data inputs it, and it, and it's, it's like it speaks two different languages. So I have to spend a whole bunch of time translating it, and then I end up making mistakes and I'm, Oh, okay, great. Now we're learning something. Right? You start to reveal the real problems, the real concerns. And so I would advise folks who wanna get into this, you, you look a little bit into interviews and how folks conduct interviews and ask questions in a certain way, where it's a little bit indirect, a little bit roundabout, but that you get these really. Key nuggets, these really good insights that help you design a way better system. That to me, that honestly sort of blew my mind there because it's something I've been thinking about, but had no clue how to articulate. In data science work in general, a lot of the times your stakeholders, they're not technical people, right? They don't know what the capabilities of data science is or they are because they're just not immersed in the field. So they might think, Oh, like I would love this, but completely impossible. There's no way anyone could do that. And you might come and be like, Oh, actually that's like really easy for us to do. You know, virtually no effort, no lift, but it would create a lot of value. And so by parsing out and figuring out what people's problems actually, , you can start to point to the solutions because the solutions are your area of expertise As a data scientist or as a technical person or as a designer. Correct. And correct. I love the, you know, asking direct questions doesn't always necessarily point to the problems that you can help with. Because of the bias of the individual person, they might not know that that's a capability. They might not understand the field. They might, they might have all these different things swollen around in their head that are right. Preventing them from getting to that. Oh, making from, from making the connection that, oh, these data scientists or these designers or these UX people, they can help with this specific problem that I have. It might not even be on that radar. And so to me that that line of questioning or that ability to interview, it's probably one of those secret skills in a technical domain that, that it can like 10 x your career. Right? Oh, totally. It's a secret weapon. It's totally a secret weapon. Yeah. And I think that that's something that really effective you know, CIOs, ct CTOs are, are very, very good at a, as they, as you go up and because those are the types of things that make true impacted organizations, is being able to match the technology solution to the problem that the person didn't even know was a feasible thing. Exactly. So, as, as we move more into, you know, your experience with data visualization, what do you think that maybe some more technical people, maybe data, more traditional data scientists, what do they get wrong with data visualization? I would imagine it's probably something related to the technologist mindset, but I'm interested if there's anything beyond. Yeah, So, so here's a specific thing. It's thinking in terms of dataset. and less in terms of decisions. So let me, let me unpack that a little bit. So, so the data scientist has to deal with the data sets. They have to do the very real and difficult job of rendering all of this data. What I see very often, if it was just, you know, kind of data science folks or engineers who just kind of went in and they just created a bunch of dashboards, what they did, what they do is they say, Okay, I know that these data sets are relevant to this job role, and now I'm gonna render these data sets. Don't think in terms of data sets, think in terms of decisions. The decision that that user is, is making or needs to make the data is there to support decision making, right? So what you wanna know is, is, is what does that person know and what does that person need to know? If you can answer those questions, that gets you a large way there. I worked on a project one time with a company who had about a dozen dashboards and they needed them to be redesigned. They needed these dashboards, this information to resonate more with the target users. And what my team found in the process is that there were about four relevant personas to that. And so we made four dashboards that revolved around those four specific personas. We did a deep dive of interviewing people who are members of that those persona groups those job roles. And we found out here are the decisions that they make and here are the pieces of information that they need in order to make those decisions. Okay. You know, so you might say that , maybe there's a job role where someone is responsible for managing the cost of, you know, you know, cloud objects or something like that. And what they need to see is the things that are causing the problem and then how much it costs or something like that. So just knowing that. So, okay, so we're gonna have one data set, render, you know, one graph rendering, one thing over here, another one rendering ano a piece, cost another one, you know, a list of the objects or something like that. So I would say that's a big thing. Don't think in terms of data sets first, think in terms of the decisions that people need to make first. And you'll end up with a good dashboard, has a mix of data sets that you didn't think it necessarily would have, right? Because there's different areas that need to be integrated in to make decisions. So if I'm judging here are my sales channels, here are my marketing dollars. And I look at those two information pieces of information together in order to make a decision. That is, that is one big piece of advice that I would give. Here's another one. Just because the user needs to look at both pieces, you know, two or three pieces of information, you don't need to literally put it in the same graph. I see that a lot where folks, they, they find these really brilliant ways, frankly, of engineering a bunch of data into the exact same graph itself. It's okay to split things out and show things in context. Maybe even do rows of information where it's like, it, it's not really a table, but it could be graphs in a slightly tabular format where you're able to see multiple dimensions of one object at a time. And so, so tho those are some things that I think I've seen a lot. You know, maybe done wrong in the industry, that there's sort of, by tweaking your mindset, you can kind of fix some of those habits. So I think that that's something a lot of data analysts, data scientists struggle with is that they, I know I do this, is I take direction very literally. Literally, a lot of the time it's like, Oh, we need this visualized, these three things visualize. And we're like, Oh, well. Well, Cause you have to as an engineer, you have to Yeah. But, but so, but the answer would be that you would have to have a whole step, A lot of folks will need to adjust their whole process. It'll be kind of a business process question, or your manager will have to understand like, okay, we need like this design step before we do it. Because you're right. Like once that's in order for an engineering task to be do doable, it kind of needs to be focused, right? It's, it's like, take this and render it in this. And then now you're kind of, now you're an engineer and you're focusing and deep diving on onto that one issue versus skipping out on that previous step. So a lot of times it's still, you have to do that, and I don't want folks to think that they're a bad version of doing for doing it that way, but it's just you need a earlier step to where you, you're wearing that design at. Yeah. And obviously you're, you're speaking not about all data scientists or all data analysts group, That's the most common common area you're seeing. And so I don't want anyone attacking you saying that all data scientists are doing this. But something that, that I personally struggle with is differentiating the visualization or the dashboard for self-service versus something prescriptive or a recommendation. I mean, often we're creating visuals or dashboards that are for those two purposes. Like one is to say, Hey, you should do this. And another is to say, you have access to this data, it's usable in your hands, and you're making the decisions based on your adaptation of the tool that we've created. How, how do you approach those two things differently? Because for me, honestly, that's something I struggle with pretty greatly. I haven't seen a breakdown to just those specific things. I find that interesting what you're talking about recommendations versus, versus, what was the other one? Versus self-service. So like for an exam, for as an example, maybe I, we have a Tableau dashboard that has specific data inputs and someone on the business side is evaluating their, their market performance by campaign with that, right? So they're using that every month to understand these things. They're switching off filters and they're creating their own insights from the dashboard that we've created. Another approach would be, oh, we give them a report or a dashboard that has all, all these findings of what they, they should have. They're not really doing self-service, they're just looking at it and they're getting this diagnostic from it. So an example, a very simple example of that would be you just have a sales chart on the wall that everyone's looking at. They're not analyzing it, they're just seeing it and consuming that information. And that might help them make better actions in the moment. So there's more like consumption based and there's more interaction. Oh, okay. So that's okay. So that's super interesting. Yeah. Consumption versus interaction. So, so that's related to a distinction that I'll often talk about, which is presentation versus something that you're using in a tool. Where presentation you kind of have the luxury of saying like, Okay, I know what exact message I'm communicating with in this presentation. And so now I have the ability to say, you know, I'm only presenting the relevant data, the relevant range of data. In pointing out certain interesting anomalies that may happen, and it's a little bit different of approach. You apply a lot of the same principles, but it's a little bit different versus the challenge of creating an actual tool where you're going to have, say, a situation awareness display, where there's a set of data that comes in a lot and then, but you don't know what the user is gonna exactly see, so you have to anticipate it. You've got to be familiar with the nature of the data. Sometimes sometimes you could d design a chart that works wonderfully for a certain type of a range of data, but works terribly for another thing. Like so for example if you have a bunch of data points that are all similar to each other, but they're large values, if you use a bar graph that requires a zero baseline to make sense. Versus if you use a dot plot where you can plot those values and shrink down the scale into where the differences are. You know, like that kind of thing, like being aware of the normal nature of the data will help you make way better decisions on that. So so yeah, kind of knowing all of that context, I think the ones that you throw out there are interesting with the recommendations versus the self-service that, that kind of distinction. And but I think the take home, I would say is being familiar with that context of how people are gonna be using it, maybe even watching them use similar interfaces and, you know, doing that kind of investigational really increase the quality of the output. Yeah. I think, at least for me, that's one of the biggest takeaways from this conversation is if I'm building any dashboard tools, like watch people use them, And ask them questions about it as they go through it. That, that's some of the best advice I've heard related to any interactive visualization period. Yeah. You know, we're, we're kind of coming to our time here. I was wondering if you have any, you know, aside from that one that I stole, do you have any maybe one unifying piece of advice for data analysts, data scientists, anyone in the more technical space looking to improve their visualization from a UX perspective? Yeah, I would say that there's there's some great schools of thought that have been fleshed out there. At the beginning. I threw out the names Edward Tufty. You know, big data visualization list in the eighties who wrote a bunch of books and got people kind of thinking along you know, certain lines like you know, you popularize the term data ink ratio. Chart junk is another term you popularized. He invented the spark line, right? There's, so for folks who do you know, day trading and things like that and, and follow stocks, you've interacted with spark lines before and things like that. Onward to the the nineties. Steven Few his probably most useful, broadly useful accessible book information dashboard design. Terrific book. He's written a whole bunch of books that really get into this perception of data and how do we maximize for that. And it, what, what I would, what I would leave. People with this concept is it boils down to signal versus noise. And every time you render anything, every time you're delivering pieces of information or you're, or you're stimulating the eyes or the ears, there's the person has to parse this into what's important versus what's not important. That's the signal and the noise every time you do data visualization. This is a balance between this is a art of maximizing, boosting the signal while reducing the noise. So you wanna make sure that things that you show on a screen are actually meaningful in any variation that you have, is mapping onto actual meaning and making sure that the signals as obvious as possible. And, and that's kind of a, maybe a mindset to go into it. I love that. Thank you so much, Thomas. Are there any, any things you're working on, any things you'd like to share about in your own life that are coming up? This is your, your platform. You can plug anything? Yeah, no, just 3leaf.consulting. If you, if you wanna see get in touch with me, what I work on. Find me on LinkedIn as well. And three Leaf Method on my social media. Although I'm not a big social media person, I rarely update those things, but but yeah. Yeah, get in touch. Well, we'll link your LinkedIn in the description of this. This is such an awesome and enlightening conversation to me. I am very grateful that you came on the show, and thank you so much. My pleasure. Absolutely. Thank you.