 In the last several videos, I've talked about the role in data science of technical things. On the other hand, communicating is also central to the practice. And the first thing I want to talk about there is interpretability. The idea here is that you want to be able to lead people through a path on your data. You want to tell a data driven story. And that's the entire goal of what we're doing with data science. Now, another way to think about this is when you're doing your analysis, what you're trying to do is solve for value. You're making an equation, you take the data, you're trying to solve for value. The trouble is this, a lot of people get hung up on analysis, but they need to remember that analysis is not the same thing as value. Instead, I like to think of it this way, that analysis times story is equal to value. Now, please note, that's multiplicative, not additive. And so one consequence of that is when you go back to analysis times story equals value. Well, if you have zero story, you're gonna have zero value because as you recall, anything times zero is zero. So instead of that, let's go back this and say what we really want to do is we want to maximize the story so that we can maximize the value that results from our analysis. Again, maximum value is the overall goal here. The analysis, the tools that tech are simply methods for getting to that goal. So let's talk about goals, for instance, analysis is goal driven. You're trying to accomplish something as specific. And so the story or the narrative or the explanation you give about your project should match those goals. If you're working for a client and they had a specific question that they wanted you to answer, then you have a professional responsibility to answer those questions clearly and unambiguously. So they know whether you said yes or no, and they know why you said yes or no. Now, part of the problem here is the fact that the client isn't you and they don't see what you do. And as I show here, simply covering your face doesn't make things disappear. You have to worry about a few psychological abstractions, you have to worry about egocentrism. And I'm not talking about being vain. I'm talking about the idea that you think other people see and know and understand what you know. That's not true. Otherwise, they wouldn't have hired you in the first place. And so you have to put it in terms that the client works with and that they understand. And you're going to have to get out of your own center in order to do that. Also, there's the idea of false consensus, the idea that well, everybody knows that. And again, that's not true. Otherwise, they wouldn't have hired you. You need to understand that they're going to come from a different background with a different range of experience and interpretation. You're going to have to compensate for that. A funny little thing is the idea about anchoring. When you give somebody an initial impression, they use that as an anchor and then they adjust away from it. So if you're going to try to flip things over on their heads, watch out for giving a false impression at the beginning, unless you absolutely need to. But most importantly, in order to bridge the gap between the client and you, you need to have clarity and explain yourself at each step. You can also think about the answers. When you're explaining the project to the client, you might want to start in a very simple procedure, state the question that you're answering. Give your answer to that question. And if you need to qualify as needed, and then go in order top to bottom. So you're trying to make it as clear as possible, what you're saying, what the answer is, and make it really easy to follow. Now, in terms of discussing your process, how you did this all, most of the time it's probably the case that they don't care. They just want to know what the answer is, and that you used a good method to do that. So in terms of discussing process or the technical details, only when absolutely necessary, that's something to keep in mind. The process here is to remember that analysis, which means breaking something apart, this, by the way, is a mechanical typewriter broken into its individual components. Analysis means to take something apart. An analysis of data is an exercise in simplification. You're taking the overall complexity, sort of the overwhelmingness of the data, and you're boiling it down and finding the patterns that make sense and serve the needs of your client. Now, let's go to a wonderful quote from our friend, Albert Einstein here, who said, everything should be made as simple as possible, but not simpler. That's true in presenting your analysis. Or if you want to go see the architect and designer Ludwig Mies van der Rohe, who said, less is more. It's actually Robert Browning who originally said that, but Mies van der Rohe popularized it. Or if you want another way of putting a principle that comes from my field, I'm actually a psychological researcher. They talk about being minimally sufficient, just enough to adequately answer the question. If you're in commerce, you know about a minimal viable product is sort of the same idea with an analysis here, the minimum viable analysis. So here's a few tips. When you're giving a presentation, more charts, less text, great. And then simplify the charts, remove everything that doesn't need to be in there. Generally, you want to avoid tables of data, because those are hard to read. And then one more time, because I want to emphasize it, less text again, charts, tables can usually carry the message. And so let me give you an example here. I'm going to give a very famous data set, Berkeley admissions. Now, these are not stairs to Berkeley, but it gives the idea of trying to get into something that's far off and distant. Here's the data. This is graduate school admissions in 1973. So it's, you know, it's over 40 years ago. But the idea is that men and women were both applying for graduate school at the University of California at Berkeley. And what we found is that 44% of the men who applied were admitted that they're part in green and that of the women, only 35% were admitted when they applied. So really, at first glance, this is bias and it actually led to a lawsuit. It was it was a major issue. So what Berkeley then tried to do is find out, well, which programs are responsible for this bias? And then you got a very curious set of results. If you break the applications down by program, and here we're just calling them A through F, six different programs. What you find actually, is that in each of these male applicants are on the left, female applicants are on the right. If you look at program A, women actually got accepted at a higher rate. And the same is true for B. And the same is true for D. And the same is true for F. And so this is a very curious set of responses. And it's something that requires explanation. Now in statistics, this is known as Simpson's paradox. But here's the paradox. Bias may be negligible at the department level. And in fact, as we saw in for the departments, there was a possible bias in favor of women. And the problem is that women applied to more selective programs, programs with lower acceptance rates. Now, some people stop right here and say, therefore, nothing's going on. Nothing to complain about. But you know, that's still ending the story a little bit early. There are other questions that you can ask. And as producing a data driven story, this is stuff that you would want to do. So for instance, you may want to ask, why did the programs vary in overall class size? Why do the acceptance rates differ from one program to the other? Why do men and women apply to different programs? And you might want to look at things like the admissions criteria for each of the programs, the promotional strategies, how they advertise themselves to students. You might want to look at the kinds of prior education students have in each of the programs. And you really want to look at funding levels for each of the programs. And so really, you get one answer. It leads to more questions, maybe some more answers and more questions. And you need to address enough of this to provide a comprehensive overview and solution to it for your client. In some, let's say this, stories give value to data analyses. And when you tell the story, you need to make sure that you are addressing your clients goals in a clear, unambiguous way. And the overall principle here is be minimally sufficient. Get to the point, make it clear, say what you need to, but otherwise be concise and make your message clear.