054-Jared Spool on Designing Innovative ML/AI and Analytics User Experiences

Experiencing Data with Brian O'Neill (Designing for Analytics)
Experiencing Data with Brian T. O'Neill
054-Jared Spool on Designing Innovative ML/AI and Analytics User Experiences

Jared Spool is arguably the most well-known name in the field of design and user experience. For more than a decade, he has beena witty, powerful voice for why UX is critical to value creation within businesses. Formerly an engineer, Jared started working in UX in 1978, founded UIE (User Interface Engineering) in 1988, and has helped establish the field over the last 30 years. In addition, he advised the US Digital Service / Executive Office of President Obama and in 2016, Jared co-founded the Center Centre, the user experience design school that’s creating a new generation of industry-ready UX designers.

Today however, we turned to the topic of UX in the context of  analytics, ML and AI—and what teams–especially those without trained designers on staff–need to know about creating successful data products.

In our chat, we covered: 

  • Jared’s definition of “design”
  • The definition of UX outcomes, and who should be responsible for defining and delivering them
  • Understanding the “value chain” of user experience and the idea that “everyone” creating the solution is a designer and responsible for UX
  • Brian’s take on the current state of data and AI-awareness within the field of UX —and whether Jared agrees with Brian’s perceptions
  • Why teams should use visual aids to drive change and innovation, and two tools they can use to execute this 
  • The relationship between data literacy and design
  • The type of math training Jared thinks is missing in education and why he thinks it should replace calculus in high school -- Examples of how UX design directly addresses privacy and ethical issues with intelligent devices
  • Some example actions that leaders who are new to the UX profession can do immediately to start driving more value with data products

Quotes from Today’s Episode

“Center Centre is a school in Chattanooga for creating UX designers, and it's also the name of the professional development business that we've created around it that helps organizations create and exude excellence in terms of making UX design and product services…” - Jared

“The reality is this: on the other side of all that data, there are people. There's the direct people who are interacting with the data directly, interacting with the intelligence interacting with the various elements of what's going on, but at the same time, there's indirect folks. If someone is making decisions based on that intelligence, those decisions affect somebody else's life.” - Jared

“I think something that's missing frequently here is the inability to think beyond the immediate customer who requests a solution.” Brian

“The fact that there are user experience teams anywhere is sort of a new and novel thing. A decade ago, that was very unlikely that you'd go into a business and there’d be a user experience team of any note that had any sort of influence across the business.” - Jared

[At Netflix], we'd probably put the people who work in the basement on [server and network] performance at the opposite side of the chart from the people who work on the user interface or what we consider the user experience of Netflix […] Except at that one moment where someone's watching their favorite film, and that little spinny thing comes up, and the film pauses, and the experience is completely interrupted. And it's interrupted because the latency, and the throughput, and the resilience of the network are coming through to the user interface. And suddenly, that group of people in the basement are the most important UX designers at Netflix.  - Jared

My feeling is, with the exception of perhaps the FANG companies, the idea of designers being required, or part of the equation when we're developing probabilistic solutions that use machine learning etc., well, it's not even part of the conversation with most user experience leaders that I talk to. - Brian



Brian: Welcome back to Experiencing Data. This is Brian T. O'Neill. Today I have the maker of awesomeness from the Center Centre. What the heck is that Jared? Tell us who you are and what a maker of awesomeness is.

Jared: Well, I think ‘maker of awesomeness’ is a little self-explanatory. We just go around making awesomeness as best we can. But Center Centre is a school in Chattanooga for creating UX designers, and it's also the name of the professional development business that we've created around it that helps organizations create and exude excellence in terms of making UX design and product services that companies are producing to make the best possible experiences that people have. 

Brian: Mm-hm. I’m going to explain to our audience who may not be familiar with your work in just a second, but why should someone producing internal business intelligence, machine learning models, analytic solutions, technical products, why should they care about user experience at all? What would they get for that? What's the pain that they would have that they would send someone to your school, or just care?

Jared: [laugh]. You don't have to care.

Brian: [laugh].

Jared: The reality is this: on the other side of all that data, there are people. There's the direct people who are interacting with the data directly, interacting with the intelligence interacting with the various elements of what's going on, but at the same time, there's indirect folks. If someone is making decisions based on that intelligence, those decisions affect somebody else's life. If you're deciding based on intelligence whether to raise rates or pricing, or you're using some sort of dynamic pricing algorithm, there's someone who wants to buy that thing whose life is affected. And if it's a mission-critical thing, it might just be that there's someone who is on the receiving end of that decision, where they no longer have the insurance that they need, or they no longer have the protection that they should because a decision was made. And those types of things are all user experience. 

We see it and we're seeing it now, four years into this current presidential administration, where there are a lot of people who are losing their benefits and a lot of that's being done algorithmically. And so this is a thing. And so, understanding what we mean by the experience of the user, understanding how we adjust for that is a big part of what we talk about to the organizations that we work with and the students that we work on behalf of.

Brian: So, challenge this premise for a second that if we do the work, the way we do it now, something is going to come out the other end, an output will come out the other end that we can put in front of somebody. So, is the process of design and user experience really about going from the decent thing we put out to a better thing? Or is it the difference between pass-fail, like, just even getting to the point of success? Is it just more better that it adds, or does it add something more significant? 

Jared: Well, the medium of design is behavior. So, it's really about what behaviors do we want to see. What behaviors are out there. And one way that we talk about it, we have this notion of what we call a UX outcome. And a UX outcome is an answer to a question: if we do a good job on this thing, how does it make someone's life better? 

There's another way we could frame it, which is if we do a good job on this thing, how does it actually make someone's life worse? Let's take something that's been in the news lately, the telematics that come out of automobiles. So, we now have all this data that the automobile is collecting because the automobile is now more computer than it is mechanical device. So, because it's a computer we know every moment the spark plugs fire, and we know every amount of gas that's burned in the engine, and we know the exact components of the exhaust system, but we also know things like where the car has been and what the tire pressure is, and we can even make adjustments to these things in real-time. So, we have controls, and we have these applications that allow us to monitor our vehicle and to even change our vehicle. 

So, the question is, how do we make the driver's life better? How do we make the passenger’s life better, the car owner’s life better because we've given them this capability, this control. So, that's an outcome. And we can say, “Well, if we do our job really well using all this data that's in the vehicle, we can start to do that.” But there's also a whole bunch of stuff that can happen where, what happens when a ex-boyfriend, or ex-husband, or someone of that ilk, has set up their own app—unbeknownst to the car owner—for controlling their ex's car, and now can do things lock them out of the vehicle, like shut it off while it's running, like change its abilities, like monitor its location. How do we protect the car owner from this abusive behavior, while still giving them the control and benefit of all the data? This is a big piece of the user experience that we have to think about in these situations.

Brian: So, let's imagine that you're a leader working in this space around telematics and you don't have user experience resources on your team. This is something where we wait for a public relations nightmare to realize that this matters, or is this something where the work of the people that are in charge of the technical side—the analytics, the data science, the intelligence that perhaps comes out of these vehicles, et cetera—is it everyone's job to do this? Is it only the job of a designer and we only need to bring them in if we have kind of a problem? How do you see that? Is it something everyone needs to be doing as part of their work?

Jared: So, I see—we have these terms designer and engineer and all these things, but really what those are, they are just collective nouns for a set of skills. A designer is someone who has a lot of good design skill. A better designer has more design skill than someone who's not a great designer, but it's really just what reflects a designer is design skill. But at some level, a designer is someone who designs. Just like a cook is someone who cooks. 

I might have virtually no cooking experience, but if I open up the box of mac and cheese, and I follow the instructions, and I make myself a dinner of mac and cheese which by the way, according to the package of mac and cheese, I am four people since that package makes four servings—

Brian: [laugh].

Jared: [laugh]—I am now a cook.

Brian: Aren't you a cooker then, actually? If we're talking about designers?

Jared: Yeah, I mean—

Brian: You'd be a cooker. 

Jared: We—typically a cooker is a device, but yes. [laugh]. I'm not particularly fast so I guess that would make me a slow cooker.

Brian: [laugh]. Oh, I could feel the headphones turning off as we conti—

Jared: Yes that’s right, that's right. I'll be here through Thursday; try the veal. But the fact is that anyone who makes a design decision at some level is a designer. So, now the question becomes, how do we equip everybody on the team to be the best designer they can be? So, it's not so much that we need a designer on the team and the designer does the designer-y things, it's that we need design skills on the team, and maybe we have someone who has so many skills, and that's all they do, so today, they're the designer. 

But that could be someone who yesterday was the programmer. I mean, it doesn't really matter. What matters is that we're making all the right decisions. And the more people on the team who have design skills, the better the overall design is going to be because design happens so often in the development process. I mean, we're making decisions. 

Here's what I tell folks. There's a group of people in the basement of the headquarters of Netflix whose job it is to make sure bits get on and off servers. That's their job, and since they opened up the streaming business, it's been a core job and there's a lot of people involved at Netflix to do this. And they all live in the basement, and they all focus on those servers. And they have terminology around throughput, and reliability, and latency, and resilience, and all these words that they use to describe this process of getting bits on and off servers. 

And we don't use those words in design very often, so they feel like they're not designed tasks. And if we were to draw some sort of org chart of all the people in Netflix, and we were to put some sort of relative distance in our visualization of how related the jobs are, we'd probably put the people who work in the basement on performance at the opposite side of the chart from the people who work on the user interface or what we consider the user experience of Netflix and we would not think of them as the same. Except at that one moment where someone's watching their favorite film, and that little spinny thing comes up, and the film pauses, and the experience is completely interrupted. And it's interrupted because the latency, and the throughput, and the resilience of the network are coming through to the user interface. And suddenly, that group of people in the basement are the most important UX designers at Netflix. 

That's what we're talking about is that we like to think of UX as being this self-contained group of activities that have to do with screens, or voice, or whatever it is, but in fact, every decision we make, the data model that we use underneath,s and the algorithms that we use to churn through the data, even the budgets that we use to figure out how much we know about our customers, and what more research we have to do, and the headcount that we get, and the hiring process that asks us when we bring someone new on the team—even if they don't have the title of UX—how much UX should they understand, all those things affect the user experience of the customers, the users, the employees, the people who are using this thing to deliver product and service to our customers and beyond. Everybody's a designer at some level.

Brian: Yeah, this is something we talk about on the show all the time. It's a team sport, and it really has to do with, you're either doing intentional design, or you're doing design and you don't know you are because you're making choices about things. So, it's really about the intent, and then if you're going to hire designers, that has a lot to do with what's the chance you're successful more often than not, and you're doing it quickly versus slowly.

Jared: I would go so far 00because the standard definition we use for design is, “The rendering of intent.” So, we have an intention in the world, we want people to be able to enjoy the movies, or we want people to safely drive the cars. And how do we render that intention? 

Brian: Yeah, and I think for this audience, at least half the camp probably is working in applied business intelligence, analytics, data science, where your customers may be more employees, colleagues, vendors, maybe not the external paying customers. But I think we can all relate to the concepts Jared is talking about.

Jared: Let's give you another example, then. One of my biggest clients is one of the largest supermarket chains in the United States. And we all experienced the user experience of their business intelligence operation when suddenly there was no toilet paper to be found anywhere. 

Brian: [laugh].

Jared: And this is what they use their business intelligence for. And their algorithms were completely unprepared for this sudden demand that was caused by people shifting from work to home and thus using more toilet paper just because they were in their homes for more hours. Not because people were hoarding it, but then suddenly there was a hoarding thing happening, and then they had to put limits on things, and they had to be able to do projections, and they had to be able to source contracts and understand where their product was coming from and understand where they had inventory repositories and things like that. All of those things affected the user experience of the grocery store customer. Even though the grocery store customer never interacted with the business intelligence tool, it was at the core of that problem.

Brian: Yeah. So, I think having this idea of being able to look outside of maybe the immediate person, that's the user of your service, who may not be the ultimate stakeholder, the user may be a little bit farther removed in that context, but ultimately, that's why we're doing all this. [laugh]. That's the only reason any of this matters.

Jared: We refer to it as the value chain. An insurance company sells to a policyholder, but the insurance—let's say it's car insurance—covers the family members who know nothing about the choices that were made by the insurance company. Of course, the insurance was possibly sold to them by a broker or an agent who may or may not be an employee of the insurance company. Let's say they're not; there's an administrator who handles all the data entry and handles all that. And those two members of the broker, they're making decisions. 

They have multiple companies they can sell insurance for, and they've chosen your insurance because it's actually possibly easier to administer. They don't really care about what the policies cover: that's what the policyholder cares about. But it's the administration of that. And then there's probably someone inside the company who supports that broker, who has to make sure that that broker has everything they need to sell that policy. So, the interfaces that that internal person deals with to make sure that that goes smoothly, and problem resolution happens, and all sorts of other things. All of these things are part of the value chain of the user experience. They're all downstream from someone making a decision of what fields do we put in a database and what algorithms do we create to adjust those?

Brian: Total agreement there. Thinking about that, I think that's something that's missing frequently here is the inability to think beyond the immediate customer who requests a solution. “I need a churn model, I need a dashboard with XYZ, I need a spreadsheet with what other data,” is not understanding the decision making that's going to happen, the results of the decision making that's going to happen, and really seeing beyond that. In my opinion, getting the people out to really get to know, through the process of especially one-on-one research with these people, and then understanding what their job is like, and pulling all this information in is the best way to start leveling up your staff, your team, to think beyond just the immediate technology asset that's being created. Is that what you recommend as well? And if not, how do you think we develop that empathy? Especially if it's not a user experience team that's done this before, how do we get them to do that?

Jared: Well, the way that everybody's gotten to do it. The fact that there are user experience teams anywhere is sort of a new and novel thing. A decade ago, that was very unlikely that you'd go into a business and there’d be a user experience team of any note that had any sort of influence across the business. So, this is new; this is a new world that we're in. And the way all of those teams got started is the same way that any new team would get started right now, which is to just spend time with your users to actually find out what happens with that data, to follow it downstream. 

I had the opportunity, years and years ago, to work with a Food and Drug Administration paperwork trail. We were working on an online system to track what was previously paper forms, and they were all around adverse reaction reports. So, you have a clinical trial and during the clinical trial, somebody contacts the drug company and says, “Your drug turned my hair blue.” And there's regulation that requires that that message be communicated to the Food and Drug Administration immediately. Recently, in the vaccines for COVID, we heard instances in the news of drug companies shutting down their trials temporarily because there was an adverse reaction. 

And this is common practice—and in fact legal mandate—in the US FDA process. So, we were tracking the paperwork, and we found that as we literally watched a piece of paper go through the business—adverse reaction came in, we were there when it came in, we saw the person fill out the form, we then watched them walk it to the next person in the chain to get it, we saw what they did with it, they added some information, they then walked it to the next person. We followed it through two buildings; we literally followed this document through two different buildings and watched everybody who needed to touch it, touch it. And we noticed things like everybody filled out their little piece—there were 17 people who touch this document inside the drug company—everybody filled out their piece of information, made a photocopy of it, stuck it in their own filing cabinet, and then took the original and passed it on to the next person. So, by the time that thing had left the building, there were 17 partially filled out copies of this document, and only one person had the fully filled out version copied before it went off to the Food and Drug Administration. 

And there was no reason for this, but understanding all the people who touched that piece of data gave us some really good insight as to the complexity of the problem and the nature of evolutionary design because it turned out that half of those people did not have to see or touch that document, but they'd always had, and so it was part of their job to do that thing.

Brian: “That's how we've always done it, Jared.”

Jared: Yes, exactly right. Yeah. Yeah. That is the number one curse that you can give on any business process is, “But that's how he’s always done it.”

Brian: Yeah. And I think it's important to note, too, for our listeners here, visualizing this 17-step process that Jared just talked about, if you want to drive change and innovation, one of the best things I've found is literally show what that looks like: either video, or a journey map, or some kind of artifact that shows the craziness which, again, may have just evolved out of the nature of the business, and mergers, and new departments, and regulations, and all these things that happen. It wasn't that someone said it was a good idea; it just happened to evolve into that. Does it have to be that way? Well, I don't know. But getting someone to change it probably won't happen until they see a problem with it. Would you agree that visualizing the problem or the pain this way is the best way to drive a change to it?

Jared: Absolutely. I think that visualizing is a fantastic tool. There's a beautiful book by a guy named Jim Kalbach. It's called Mapping Experiences, and what it's about is all the different ways you can get to shared understanding by drawing things out. And so following the flow of something, or showing what happens behind the scenes at the same time of what the customer sees in front of the scenes, right. 

So, I go into the store and I go to the shelves, and there's no toilet paper, and then I go talk to the manager, I say, “When you're going to have toilet paper?” And they say, “Well, come back Tuesday; we have a shipment coming in.” What happens between that moment and the next Tuesday when I show up, and there may or may not be toilet paper? Being able to represent all of these things—that it's often referred to as a service blueprint when you show both the back of the house and the front of the house—all of these things helps people see the crazy that's going on. And one thing that you and I haven't talked about, which is, there's this assumption that the data that we are doing our BI intelligence on—I realize that's redundant ‘BI Intelligence,’—

Brian: It's twice as good because that's two ‘I’s.

Jared: There you go. Yeah, the ‘Business BI Intelligence.’ That's the best kind.

Brian: [laugh].

Jared: That data, how dirty is it? How flawed is it? What's missing from it? Where is it misrepresented? Where is there duplication? How clean is it? If it's got attitudinal stuff, is it calibrated, right? 

Because we often ask people on a scale of 0 to 10, if they'll recommend us to a friend, but what does that number actually even mean? because different people fill that out differently. And so now, how do we make all that work? And this is a big piece of the problem is that we don't have a good way to really represent what it is that makes our users successful. What is it that we need to have to work? We need to be able to get to the source of that data and understand if we can even extract the things we are claiming that data tells us.

Brian: And by the way just, again, for our audience here, I know probably a fair number of you aren't familiar with Jared’s work—

Jared: I'm barely familiar with it.

Brian: I heard you probably were. 

Jared: I have to, like—every time I write a new article I have to Google and make sure I haven't written it before. And then about—I have found that I have and then—

Brian: Oh, here it is. [laugh]. Update date.

Jared: Yeah, it’s like, “Oh.” And that's exactly what I was about to say. Okay, now, what do I do? 

Brian: [laugh]. Well, this has been a great conversation so far, and I just want to give context to our listeners. Jared’s kind of like a Tom Davenport of the user experience world. He's kind of one of the leading voices in the analytics world. And so I wanted to have you come in here to relate user experience in the context of these decision support applications and the way we're using data now for machine learning and intelligent products, et cetera. 

So, something that's coming up regularly, especially in non-digital-native groups, especially with internal application creators, is data literacy, versus how easy or useful does the solution need to be. And so on the business side of the house, they're saying, “I don't know what to do with this information. This is not what I asked for. It's too hard to use.” 

And on the creator side, you have, “Well, our organization is not ready to make decisions with the data. They don't want to see it.” Or, “If you don't understand how to use Python or R, that's not my problem, but the model works just fine, so next ticket, please.” They're saying that there's a literacy problem. How does design come into play here about how easy does it need to be, how much investment do we make in utility, usability, and value versus upskilling, training the people? Talk to me about how a leader might think about that investment?

Jared: Well, training is always a trade-off, and training is the opposite of usability. We can train somebody, or we can invest in making something more accessible, more usable. The thing to keep in mind is that, at the end of the day, our goal is that we are able to make the decisions in the timeframe that the business needs that to happen. And more and more, the business needs that to be faster and more effective. Now, I could have someone who's been doing this job now for two decades, they know the data in and out, they know the tool in and out, they've mastered this thing. 

And they just lay their hands on the keyboard—you don't even see their fingers moving—and the next thing all this great data has shown up, and they're just a Zen master. And it's great. However, they find themselves quickly in this situation where they want to retire, or they have a health issue and now someone has to take their place. Does the business grind to a halt, or is the business able to do something? Or maybe there's more to do than this one person can do. 

So, now I need someone else to come on. And we could invest in training that person and getting them to where they need to be. And maybe that can be done in a week or a month, or maybe it takes five years. Is the business accepting the fact that that time is necessary to do that kind of training? If we just have a small number of users for this thing, training is an acceptable option because training, once it's done, it's done, and development is often more expensive than a single training episode. 

If I have this very complex thing to use, I can sit down and train you, and take careful notes, and make sure you get it faster than I could probably design something that was easier to use that, with the knowledge or experience that you had coming in, you would automatically know how to do that. But if we're talking about 1000 people or 10,000 people, then suddenly those training costs become astronomical. The cost of development can be much lower. So, the way to think about it is training is an ongoing cost. Every time you get someone new, you have to train them. 

So, if you want to double your staff, you have to double your training. If you want to have 10x staff, you have to have 10x training. If I make the software usable from the beginning, I only do that once. It may be more expensive, so it's probably more than 1x training. But is it more than 1000x training? 

Is it more than 500x training? Is it more than 10X training? We have to figure out where that point is. It's somewhere in there, so let's figure that out. And once we figure that out, it becomes a business decision not a sort of philosophical, theoretical, is it good if we do this? 

What we're talking about here is accessibility. We're talking about making this part of the business accessible to the people who need it. You know, we usually think of accessibility as tools to help blind people use our computers, or tools to help deaf people watch videos, but this is—when we talk about literacy, literacy is an accessibility element. People who can't read, who don't have what we would consider reading literacy—the ability to read a document that's aimed at a 10th grader, or college freshmen or something like that—someone who does not have that capability will not do as well in a job where reading is a fundamental part of the job. They could work a machine no problem, but when it comes to reading instructions, they can't do that. 

Okay, we can accommodate them in different ways. So, really what we're talking about when we're talking about data literacy, is accommodation. How much do we want to accommodate people who aren't coming with the knowledge and experience from some previous place, whether it be another job where they did the same thing or school that taught them how to do something? That's key. Now, between you and me, I think we should nuke calculus in high school and replace it with stats and prob. 

I think everybody should come out of high school with statistics and probability. That would teach them how to deal with large sets of data; that would teach them how to understand basic things like what are the odds you're going to win the lottery? They would probably make better decisions in their life. What are the odds you're going to catch COVID if you don't wear a mask? This is just basic probability and people are not paying attention to it because we have such bad data literacy in our world. 

That's why this damn pandemic is going on for much larger than it needs to be. So, we could blame that on data literacy, and we can blame that on not having a good background. So, personally, I would like to invest in training every high school student how to work with basic data. And maybe R or D3 or something should be part of the high school curriculum, at which point it’s completely different story about what does it mean to be data literate.

Brian: Your points are well taken, and it's even more important when we think about what a lot of analytics teams and data science teams are doing is they're not even providing a finished application. They're providing something equivalent to Photoshop or Microsoft Word where you then need to still go build your own thing. It's Tableau with maybe there's some stock dashboards or something, but it's more about, “Well, here's your access to infinite amounts of data that we have in the lake.” Feel free to assemble whatever you like. And a lot of is this is just not—

Jared: Yeah, we call this the Home Depot problem. 

Brian: Exactly.

Jared: If you were to say to me, “Hey, I'm thinking about building my own house.” I say, “I know exactly what you need to do.” And I put you in my car, and we drive to Home Depot, and I kick you out of the car, and I say, “Okay, everything you need is here, go for it.” And then I leave.

Brian: [laugh]. And then I'm like, “What do I use this thing for?”

Jared: Yeah.

Brian: Times a million.

Jared: How do you even start the process of building a house at the front door of Home Depot?

Brian: Absolutely. This is great. I'm going to switch gears here for a second, a different framing here. And this is to talk about user experience in the context of specifically of AI and more specifically, machine learning. I'm curious, your take here. 

My feeling is, with the exception of perhaps the FANG companies, the idea of designers being required, or part of the equation when we're developing probabilistic solutions that use machine learning and these technologies, it's not even part of the conversation with most user experience leaders that I even talk to. I'm curious if you think there's significant changes coming, either in the way we design with data or the design of tools using these technologies that will be used by customers? In my opinion, there's a lot to get right, especially when we talk about not just the users, but the third parties, the affected parties. Like, talk about your surveillance camera. There's the guy watching the screens, and it's doing facial rec and all that, but there's the non-users, us walking around the store being captured. There's so many different human things going on here. What is your feeling here? Does this matter? Is something we need to—user experience professionals need to be paying attention to more, is it just like a fad?

Jared: No, this absolutely needs to be taken into account because there are definitely ways that large amounts of data can be misused. We know this. We've seen this in action. So, now, we have to ask ourselves, “Who owns that responsibility?” If someone can get access to data and use that to harm someone else, are we culpable in that process? 

And I think the answer is, we are. If we create something where it could be misused, that is no better than a doctor not washing their hands and infecting a patient when it could have been prevented. There's some level of culpability to that. A colleague of mine, Dana Chisnell wrote a great presentation about what happens when we get things right, the sort of downstream effects of decisions. And we're seeing it now with Internet of Things, where we have this ability to control the Internet of Things remotely, so people are misusing that to create havoc in other people's lives, by gaslighting them. 

If I can control your thermostat, and we are no longer friends, and I am somehow angry at you, I can freeze you out of your house; I can lock you out of having access to your boiler. What happens to this? So, at what level do we give people control over who has access to their data, who has access to the control of that data? We're seeing all sorts of hacking and social engineering and all sorts of things. And much of it could be prevented if people just did a little bit of scenario planning and saying, “What are all the ways that this could be hacked?” 

So, there are techniques—the military has been using this for a year, there's something known as red team/blue team techniques where the red team is a group of people whose job it is to figure out all the different ways to breach the access to the data and manipulate it for evil intent, and the blue team is trying to patch that up, put in security, and then the red team tries again, and you keep repeating that process. These types of exercises, these type of tabletop games can be done to dramatically reduce the number of vulnerabilities that can happen and to think through scenarios of how could somebody misuse this?

Brian: Yeah, absolutely. So, this kind of segues into my last question which was, to give leaders that are not coming from the UX space, or the traditional product management space in the data space, more. What would be two or three behaviors that they could start doing in their teams today, without going out and necessarily hiring a designer or something like that? Are there just a few things that you would advocate to start seeing some value come back?

Jared: Yeah. Start spending time with your users. That's the number one thing. The more time you spend with your users, the more we see improvement in the user experience. It's not hard to do, particularly if they work for your company, so go spend time with them. 

Go sit them—you know, next time, you have an opportunity to meet somebody who uses the data that you're working on or the tools that you're building, go sit with them and see what they do with it. Just spend time; see where it matches what you thought they did with it. See if there are things that you could do to make their life easier. Is there a different way to format the data so that they can have access to it? Is there a starter kit of tools, or templates, or pre-done models that would serve most of their need? 

I mean, we've all seen these things. We get a new word processor, and it comes with templates for different types of documents. You fire up a new SaaS product like Airtable, and it doesn't just have this random database; it's got a library of stuff. And in fact, they built an entire store—as it were—of user-supplied applications that serve certain purposes. So, could you do that? 

Could you get your user community to start sharing what they do with it? Here's a great thing you can do: hold little lunchtime meetings where the purpose of those meetings is for some user of your work to come show you what they do for a living and how your work plays into the decisions they have to make. Just doing that would change your world tremendously, which would probably, in turn, change their world, which also would probably, in turn, change the world have a whole bunch of other people who also would like to do this but don't know how. At Pixar, they tell the story of this thing they do every day, called dailies. And it comes out of the movie industry where you used to watch yesterday's filming; you'd get the film developed and you'd watch what was filmed and you'd make decisions: do we have to reshoot this scene or that scene? 

But at Pixar, that doesn't quite make sense because you can preview everything on the computer. But instead, people bring some partially finished work and they show it off. And they explain the thinking that they have and where it is. And there's this story that went around about this guy who kept showing up for the dailies—originally, the dailies were just people on the filming crew showing how they modeled hair, or how they modeled this, or whatever. And there was this guy who kept showing up who wasn't part of the film team, who would just sit in the back and just watch. 

Finally, someone went up to him and asked him who he was and it turns out, he came from accounting. And they had said this was open to anybody, and he was just fascinated by what the filming teams did, so he would just show up. And then after he was there for a while—there was always a Q&A during these sessions—at one point, he raised his hand and he asked a question. And the question he asked was actually really smart. I mean, it was clear that he wasn't doing this every day of his life, but he had obviously paid enough attention that he knew what question to ask. And then one day, they were saying, “We don't have anybody scheduled to present next week,” and he raised his hand for that. He said, “I'll present.”

Brian: Nice.

Jared: They’re like, “What are you going to present?” He says, “I’m going to present a budget.” Turns out that he'd been paying attention, and he came in with this beautifully designed budget. Because he'd been listening to how folks deal with things, and he's like, “Oh, I can apply these things to the budget spreadsheets I produce.” And he was thinking about who his users were and all this stuff. And it’s like, he presented a partially built budget, how he thought through—you know, rendering intent—how he thought through what the budget needs to do, and who's going to use it, and he'd spent time with his users, and he'd done all these things. Like, wow, you were paying attention. 

Brian: Yeah, love it. That's a great story. Jared, it’s been great having you. Anything else you'd like to add before we close out here on Experiencing Data?

Jared: No. Just spend time with your users, spend time understanding what they need. And then, the medium of design is behavior, so focus on making sure that you understand what behaviors come from the things you're building.

Brian: Yeah. Thank you so much for coming on here and sharing your ideas. It's been great to talk to you.

Jared: It's been great to talk to you. Thank you so much. 

Brian: Excellent.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.