Podcast: Play in new window | Download

Sean [00:00:00] Hello everyone, welcome back to the product momentum podcast. Super excited today to have Kim Goodwin, master of design and design principles, author of an amazing book, Designing for the Digital Age, published way back in 2009. But even though ten years in our space feels like a millennium this book is just as relevant today as it was 10 years ago in my opinion. So Kim I would like to let you introduce yourself and then we’ll jump right into getting after this interview.

Kim [00:00:26] Hi everybody. This is Kim Goodwin. It’s a pleasure to be here with Sean and Paul.

Sean [00:00:30] Cool. So can you tell us a little bit about your background and where you came from what you do…?

Kim [00:00:35] My background, uh, well let’s see… I’ve been doing design and product strategy, product management for 25 plus years and I’ve worked in-house and I’ve done a lot of consulting in my career and I would say these days I am pretty specialized in helping companies build their design capabilities and their product management/product strategy capabilities with coaching teams and building processes and that kind of thing.

Sean [00:01:01] All right. I see you went to UC Berkeley. Can I ask what you went school for? I seached around and I couldn’t figure out what you what your undergrad was. That made me even more curious.

Kim [00:01:09] No, like most people who have been in this field for a long time, my undergrad had absolutely nothing to do with what I do now. I majored in chemistry and in women’s studies which I have really not used at all. And then grad school was in education which I actually have used since I’ve been an educator for a lot of my career as well as a designer and product leader.

Sean [00:01:29] Interesting. So my undergrad was in Molecular Genetics. Again, very similar to you, having been in this field for over 20 years myself. It’s a relatively young field right, so it’s neat.

Kim [00:01:40] Yeah it really is. You know when I started out I was doing illustration and animation in 16 colors which tells you about when it was and the engineers said, “hey, you’re a visual person, why don’t you take care of the UI?” And I sort of cockily said, “sure I can do that,” and realized I had no idea what I was doing because behavior and interaction and cognition were all stuff I didn’t know much about. So I started digging into the literature and looking for tools and there were not a lot at the time.

Paul [00:02:08] That’s awesome. I think the foundation of what you’ve built on and the topic matter and the ideas that you’re putting out, especially lately, have been around obviously human-centered versus user-centered. And I was just wondering what other language have you found can change the way people think in the ways that we describe the decisions that we’re making for the people that we’re building for?

Kim [00:02:30] Hmmm… what language can change how people think? That’s an interesting question. Language definitely guides the way that we think. You know, it’s funny. I think that word design is problematic sometimes because it carries so much baggage with it, right. Who’s a designer, who gets to use the word, design decoration, all that stuff. So I don’t know about you guys but when somebody at a party says, “what do you do for a living?” these days I don’t use the D word. I just say I make companies better at humans.

Sean [00:02:56] I like that.

Kim [00:02:57] Because that’s really what it’s all about, right, is just helping people think about what does a normal human expect in this situation? What would feel great to them? What would help them be effective and feel known and cared for in whatever the situation is? And it really gets boiled down to that. So I guess when you ask what language I use, I try to minimize all the jargon, you know. I see lots of teams talking about, “oh we’re gonna do ethnography this and journey map that,” and yes those are useful words for us, but how about, “we’re going to go talk to some humans in their actual context and we’re going to see how they act and we’re gonna go from there.” And I just find that that demystifies the design process for people and just gets it a lot better accepted.

Paul [00:03:41] Yeah. You know it’s funny you say that. When I started applying some of your thoughts just to the way that I think it started changing just the basic template of a user story from, “as a user I want to X,” to, “as a human…” And it just made me think about the ways that I’m building things for the people that I’m impacting. That’s really great. Thanks.

Kim [00:03:59] Yeah. Well I’m glad that’s helpful. You know certainly we all bring a lot of who we are to the software we use and also to the way that we work together as teams, you know, I think that we have to apply that same sense of our colleagues as humans to get things done.

Sean [00:04:14] For sure. I’ve always hated that word user. It makes me think of drug user.

Kim [00:04:21] Well you know we talk in the language of drug dealers a lot these days, you know. When I started in design we were a lot less about, “let’s optimize this metric and let’s get people to do this or that.” And these days on the web in particular it’s, you know, “how do we get people to give us more information or give us more money or spend more time on our website and how do we get people hooked?” And that’s not language I’m very comfortable with, to be honest.

Sean [00:04:46] Agreed. Alright, something a little fun here. So you mentioned in our pre roll discussion that you just got back from Malaysia.

Kim [00:04:53] Yes.

[00:04:54] And I did notice, I got a really big kick out of going through your last couple of years of Twitter posts. Hopefully that doesn’t frighten you, the question I’m about to ask. But it’s clear that you travel a lot in your new role roaming around the world teaching people how to design better products and things. I noticed that you post a lot of pictures of hotel showers and their feeble and failed attempts at interface design.

Kim [00:05:17] Yeah.

Sean [00:05:18] I think my favorite quote that I’ve read anywhere that you wrote was maybe a year ago or so of how we’re sorted by profession: all hotel architects would wake up to a different style a shower every morning for all eternity.

Kim [00:05:30] Yes.

Sean [00:05:32] And I actually travel a lot as well and it is the bane of my existence; looking at that puzzle that they call a shower. Right.

Kim [00:05:42] Well it’s totally cruel, right, because you’re jet lagged and you wake up to this new thing and somebody designed a shower that looks really cool but there’s no way to turn it on without getting scalded or frozen. And sometimes, you know, there was one recently that you had to use three different knobs to get it to spit out water. And sometimes they’re just mysterious, right. It’s very much form over function on a lot of those things.

Sean [00:06:05] That’s awesome.

Kim [00:06:06] Yeah. I think that, you know, the curse of being a designer is you can’t look at anything in the world without thinking, “why is it like that?” and everybody I know who’s married to a designer ends up learning to think that way and cursing us for it.

Sean [00:06:22] Yeah. Some great advice I’ve read, I think it was in the opening of your book, was about the Socratic method and how you need to build the culture, yes clever answers are valued, but discriminating and thoughtful questions are valued more.

Kim [00:06:34] Yeah.

Sean [00:06:35] So along those lines, what are the right questions to ask versus, you know, coming up with solutions.

Kim [00:06:40] Well…the right questions to ask, I guess that depends on the stage in the project that you’re working on, right. I do think a lot of people, especially early in their careers, feel like their job is to have the answers and actually a lot of even senior executives feel like their job is to have the answers. But I find that if you ask the right questions people think, “oh my gosh she’s brilliant” when you actually haven’t provided any answers at all yet you’ve just helped people see the problem from a different angle. So, you know, early in a project I think it’s important that we ask, “what are we trying to accomplish for the business, what’s the goal?” You know, if people are talking about, “oh, well we should build X Y and Z,” why? What is that going to accomplish for us and for what kind of users or customers are we talking about? Which part of our audience and what problem do we think we’re solving for them? You know I think if we don’t ask those fundamental questions initially then we have usually a misaligned team.

Paul [00:07:32] Yeah. That’s actually a great segway into something that I’ve been curious to ask you about. You know, oftentimes there’s I think a false dichotomy that you point out between human-centered versus metric-centered and it’s not that they fight against each other but it’s a values system that needs addressing. But qualitative, thoughtful, ethical measurements can be really hard. And trying to put the time and the value set together to bring those out in the work that we do can be really challenging. So what is a way that people can begin thinking correctly about those, um, I’m going to say soft skills, and I know it’s not the best word but…

Kim [00:08:12] The most critical skills.

Paul [00:08:14] You know what I mean, yeah.

Kim [00:08:15] Yeah. Well, you know, I do talk about practicing metric-centered design as a problem because I think when we over-optimize to one metric, we get distorted behavior, right. We get unethical behavior and we get YouTube driving people to ever more radical videos and all of these kinds of things that we read about in the news it seems like every single week. What happens though is we get measured on those things and we get incented for those things and those things tend to be what’s easy to measure because we can look at click rates and those sorts of automated metrics.

Kim [00:08:50] And so those easy to measure things are attractive. What we don’t measure, though, is the impact that our products and our services have on people and on their lives. And the closest I see most organizations doing to this is Net Promoter Scores which are pretty much useless as far as I’m concerned because they say, “hey how much do you like us?” and they don’t tell you, “what should you do as a result?” and “what about our behavior as a company is making you not like us?” They’re not very informative so I think the only way that we get at those human metrics is to ask people. We can’t rely on click through rates as a proxy for our impact on people. But we have to ask more tailored questions than that, right. So take Facebook for example. They claim that their mission is to make the world a more connected place. So what Facebook asks me every, I don’t know, every three months or so is, “hey Kim, do you feel like Facebook cares about its users?” And I think, “wow that is the neediest question I’ve ever seen” because it’s about you. It’s not about my experience as a user. It’s about my brand perception of you. If instead you wanted to measure your impact on people you could ask, “hey after using Facebook today did you feel closer to the people you care about or did you feel more alienated from them?” You know, “did you feel better about the world in general?” You can measure those kinds of things instead and I think those start to get a little closer to what we can act on as designers and product managers.

Paul [00:10:16] I think that’s a challenging task that it’s hard to decide what to do but I think it’s also important to think about what we’re not doing.

Kim [00:10:23] Yeah.

Paul [00:10:24] There’s a great, um, I think art to what you described as sort of the Do No Harm. We can be aspirational but we also have to be pragmatic and deciding what to do and when to do it is driven by those values that you talked about.

Kim [00:10:39] It is driven by values. It’s also, you know, when you think about how we make decisions in our day-to-day lives, we’re never optimizing for just one thing. When I think about, let’s say, optimizing for fitness, right. If that was all I cared about I would spend my entire life at the gym and would I have no friends and I would never eat chocolate and neither of those things is acceptable, right. So we’re always looking at what are we not willing to trade off and there’s always some boundary that we hit. Every decision is a tradeoff. And yet we treat metrics as one dimensional things and we don’t look at pairs of metrics together and see how what we’re doing in one place is affecting the impact of our product. So anytime I see a team measuring just for one thing I think that’s a team that’s going to be damaging their user experience in ways that they’re not even seeing.

Sean [00:11:27] Agreed. Let’s switch gears a little bit. You talk a lot in your book about personas and I’m a huge fan of personas. We’ve been using them since we first discovered them. I learned in your book that personas were invented at Cooper, which is awesome. So we’re basically talking to one of the people that was deeply involved in figuring out how to make them work. And I would like to know what you think about how they’ve evolved over the years, or if they have evolved, and what you think you’ve learned in the last 20-some-odd years of using personas.

Kim [00:11:57] I think personas are a widely misunderstood tool. I think they were widely adopted, initially, because they appeared to solve some problems, and they do. But a lot of people have latched on to the personality aspects of personas a little too much and use them like creative writing tools and people criticize personas as not solving the whole problem when they don’t actually realize that personas as standalone tools are not that worthwhile. Personas with scenarios are hugely useful. If all you do is you say, “here’s our persona, here’s her goals,” and, you know, people slap some demographics on there and some fictitious details… Maybe that helps clarify your thinking a bit but without a scenario, your persona is not going to do much for you. It’s not going to help you really make a decision. So I guess that’s probably my biggest takeaway from personas is people are looking at them as complete tools. It’s kind of like a hammer with no nail. It doesn’t do much good.

Sean [00:12:56] Yeah I would argue the whole point of the persona, I think in your book you said it’s to create a shared purpose amongst the team, in my world I like to say it slightly differently. I say the purpose of the persona is to really improve the level of empathy as for the consumer, for the customer that we’re building for. And if it doesn’t do that it’s useless.

Kim [00:13:19] Yeah I would agree with that. I would also take it one step further which is that particularly in a lot of enterprise products, people talk a lot about roles, you know, basically job descriptions. And even in consumer space there’s a lot of differentiation among people who use a tool. They have different goals or they have different mental models. They have different skill levels, right. They have different needs that make them a bit more nuanced. So if you take air travel, for example, a passenger is a role, but there’s all kinds of people who need different things out of their air travel and have different expectations. So a persona lends that additional nuance and helps you think in much more detail than a role; it makes it a lot less generic, and that way know when you and I are talking about our users, we can talk about a particular flavor of user who has a particular kind of need, but generally those needs are not demographic-based. They’re based on things like a skill level or a different environment that that person’s operating in or a different goal that they have.

Sean [00:14:20] Yeah I liked how you in the book you talk about different competency levels. We use something similar to that, like especially…all we do is build software products, right, so it’s really important for us to understand what the person’s competency level is and technology in general because that’s going to inform how much experimentation and design we need to do around onboarding a new customer especially if it’s a complicated domain, right.

Kim [00:14:43] Yeah. And actually even technology skill in general I find has less impact than skill in the domain, right. So “does this person know how to do their job?” in which case our tool just needs to get out of the way, or “does this person actually need to be taught how to do the job by the tool?” you know, “are we educating them in a whole new field of knowledge?” Because that’s a very different approach to designing that product.

Sean [00:15:09] Awesome. So you gave a couple tips in the book. I want to go through some of the things that I read.

Kim [00:15:13] Okay.

Sean [00:15:13] One, using as realistic as possible descriptions of the people with real names. But clearly, and I’ve actually done this before and it is a trap, when you pick a specific person and use that as the persona. Right. Don’t do that.

Kim [00:15:29] Yeah it’s funny. I would say do what works. And often that doesn’t work. Once in a while that is what works. So you know I would say that since I wrote the book, you know, I was coming very much from our perspective at Cooper when I wrote the book. I think I have used personal as a slightly more varied ways since then. One is, look, if people just hate the concept of a persona, fine, don’t fight that fight. Focus on the behavior pattern that’s behind the persona. But if people are bothered by the fact that it has a real name, OK fine, I’m not going to fight that point. I do think that it’s helpful to be realistic but people can sometimes get hung up on the details. You know, for example, I had a client once who, it was a health care setting, and because of the way insurance works in America, which we all know is complicated, we needed somebody to be a single parent. And so we had a divorced single mom and our client got really hung up on the fact that she was divorced, like he had a moral issue with the fact that she was divorced and so that was just a distraction we didn’t need. So we just took that detail out because it wasn’t helpful.

Paul [00:16:31] Yeah. One of the things that I think is important to remember is we’re trying to blow up the Maslow’s hierarchy, right. We’re going from physiological to safety and ultimately trying to actualize the people around us and if we’re taking that measurement that I think you used, and I’d love to hear you expand on it just a little bit, of that the primary goal being we’re moving someone towards actualization but simultaneously moving no one away from it, and you had a couple recent examples; I was wondering if you found any others in the wild that would be helpful just as a litmus test of what that might look like or not look like.

Kim [00:17:07] Well yeah, I mean one of the things that I talk about is, what does human-centered even mean? Because I’m not sure we have a shared definition of that. And I think that is a good starting point, at least, which is we’re helping people self-actualize meaning. We’re helping people achieve their full potential as humans without getting in anybody else’s way while doing that and I think there’s a ton of tools where that’s a helpful example. So if you look at job listings, for example, if you help the people listing jobs be very specific in their search criteria then you’re helping them to get better candidates for, you know, less ad spend and all that kind of stuff. But if you give them certain kinds of tools that let them narrow the search too much, you might be hiding that job opportunity from people who fit certain demographics that they expect are not going to be helpful to them, right. So you could be building discrimination into a job search tool which is harming somebody else. Even if it’s not your user, it’s still harming somebody else in the world. And so, you know, we can think about that in terms of environmental impact with lots of our tools… even just ride share. I saw an article recently, I forget where it was maybe the New York Times, about how Uber and Lyft are losing money, they’re making traffic worse; so what problem are they solving exactly other than generating money for a certain group of people? But the companies even themselves are losing money so what are we designing for? Who are we self-actualizing there? So it’s an interesting framework that I think applies in a lot of places.

Paul [00:18:38] Yeah and I think one of the coolest examples, well one of the most insightful examples that you had, was a walking metric of something trying to encourage someone to take a certain number of steps and equating it to a mini cupcake or a number of mini cupcakes and then…

Kim [00:18:53] Oh yeah, yeah. This was something that the Google Maps team did a while ago, right, with the assumption that, “hey encouraging people to walk is good for the public health.” And it’s really well intended. And so they had this feature implemented, briefly, where it said, “hey if you walk here you’ll burn this many calories and that’s however many mini cupcakes,” and a lot of people probably found that useful, but then there’s a segment of people who say, “um, hi, eating disorders are a problem; this is not a healthy attitude toward food,” and they’re right. So it’s one of those cases where if you’d had the right people in the room either as part of that design team and product team or as part of your user research that would have been caught before it got launched. And so I think that those diverse voices in the research and in the teams themselves are really important.

Paul [00:19:40] I have one more on that topic but a little bit of a curveball. The health topic and your Twitter profile intersect where you say you’re a fitness nerd and I’m just curious if you could share what’s one thing that you’ve found lately to be a helpful or even a challenging routine or tactic that has changed the way that you think about your approach to fitness nerd-dom?

Kim [00:20:02] Haha, my personal fitness nerd-dom. I guess by fitness nerd I mean that I like to learn a lot about topics that I’m into. You know, anything that I adopt as a hobby or a passion I just nerd out on and so I read a lot about these things and, you know, I track things and quantify stuff and all of that sort of thing. So yeah, I guess that’s what I mean by fitness nerd. A thing that I have learned. You know, for me, the biggest challenge actually is that I do travel so much and a lot of fitness is so much about having a routine that, you know, I’ve landed in a strange city and I’m at a hotel and I think, “ugh, do I really want to go to the gym?” And I find if I take one step in that direction I’m more likely to get there. It’s like, “OK I don’t know if I’m going to go to the gym, but I’m going to put on my gym clothes. OK I’m in my gym clothes, I might as well go check out the gym and see if it’s decent. Well I’m here, I might as well exercise for a bit.” I find I take that one step and it makes all the difference. So to me it’s a design problem, right. How do I design my environment to change my own behavior?

Paul [00:21:05] That’s super interesting. Yeah I think that’s super helpful and in other areas of life too.

Kim [00:21:09] Yeah I apply nerdy design things to life in general. It’s funny, I was having lunch with some friends. One friend is a design researcher and her husband and, I forget what we were talking about, but I asked him something very much the way I would have asked in a user interview and he said, “oh gosh, you’re design researching me aren’t you?” So I just started busting because she does that to him all the time.

Sean [00:21:33] That’s awesome. All right, so changing gears a little bit again. In ITX we like to talk about project versus product mindsets because we built software products, and, you know, I’ve kind of made this word project, you know, not a bad word but a word we try to avoid because when you have a project it has a defined start and end. Especially in the software space you shouldn’t be thinking about it as having an end, right. It goes back to a quote that I found on Twitter from you about road maps: “The term road map, unfortunately, implies we are charting known territory; stakeholders need to know it’s more like an exploration plan to create the map.” We know that we can change it, like tomorrow. It’s not like we’re building a piece of hardware that you have this manufacturing ripple effect with a piece of hardware; once you design it, it’s hard to change, right. With software we can literally change it in the next sprint. So it’s a very dangerous thing to say we’re going to have this fixed roadmap or this fixed thing that we’re going to accomplish. And you talk a lot about that in your book too and I just want to hear your thoughts on this concept of a fixed versus a product, you know, living mindset.

Kim [00:22:40] Yeah. You know, I think it’s one of those things that isn’t black and white. You know, you’re right that a lot of the expectation about road maps I think does come from that manufacturing mindset, right, which is: we have a thing that has been solved and specified and we’re just executing it. And that’s not how software development works. So definitely the idea that we can plan out for the next two or three years exactly what we’re building is flawed. On the other hand, I think that I don’t necessarily agree with the point of view that, “well we don’t know what we’re doing from one sprint to the next,” because I think that’s often a terrible way to plan and roll out a product, you know, there’s a happy medium in there somewhere where we have small chunks of delivery and we’re learning but we do have an overall direction that we’re heading, right. So the idea that we don’t have any plan at all I also take exception to. So I think the happy medium is: we have a vision, we have a north star, we have some idea of roughly what we’re going to build and what problems we’re solving for people. So I’m a fan of problem-based road maps, right. Things that say that this team is working on solving this problem for this kind of person, and, you know, in the next three months we know roughly what we’re building, after that we’re not sure because we’re going to learn from what we’ve built and see where to go from there to solve that problem better. So I think it’s a happy medium, right. I’m not a fan of extreme dogma on either end of that spectrum.

Sean [00:23:59] But you can’t get investment money if you don’t have some sort of resolution that we’re going to make our ally in this thing.

Kim [00:24:05] Yeah.

Sean [00:24:05] You’ve got to balance that all out.

Kim [00:24:07] For sure.

Paul [00:24:08] Tagging up just a couple seconds ago, when you talk about the decisions that we make, there’s a phrase that often comes up that we roll our eyes at when you have conversations like this where business stakeholders will say, “well everybody’s a designer.” And to some degree that’s true because we’re all making decisions that impact the product that we’re working on and we do as product people and designers want to keep our skills precious to some degree. But I think there is some truth in the sense that we do want to push those decisions down and democratize that thinking of, “who are we building for?” and that’s important. How can we start to talk to our teams in ways that, you know, not in personas that we can hang on a wall behind our desk that helps us remember the people are building for, but bring that language, the user research language, to the developers, the pixels and code that we’re putting up on a screen and try to remember that what we’re doing has an impact on the world. What are some ways that we can try to shape that dynamic?

Kim [00:25:07] You know, I think one of the biggest mistakes people make with personas is assuming that if you hand somebody your persona that that’s a substitute for them spending time with real humans. And I think personas are best used as a shorthand, as a reminder of what we’ve all seen together in some user research. So I really think the only way to get a team truly aligned around what humans need is to get them all to spend time with humans. And by everybody, I mean the developers, the product managers, the marketing team, the executives; get everybody to spend some time and I think that makes a tremendous difference. So that’s honestly where I’d start and you can’t necessarily get everyone on a really large team out to see users in person, but can you at least share videos? Can you get them to connect on a bit more human level rather than just, “here’s the abstracted version.” Any time I hear a user a researcher say, “well, the team isn’t using my research,” and I say that’s the problem, because it’s your research. It’s not our research, it’s not their research; it needs to be a connection that everybody makes with the users.

Sean [00:26:11] Yeah. The communication of the research is just as important as the research itself, right?

Kim [00:26:19] Absolutely.

Sean [00:26:19] Along the lines of your question too Paul, another Twitter quote from you, Kim: engineering decisions are UX decisions. For example, if there’s not enough hot water, nobody cares if the shower controls are well-designed. Going back to our shower discussion earlier. It seems to be the theme of our podcast here.

Kim [00:26:35] Yeah, clearly I have opinions about hotel showers. So look, I think designers get very bent out of shape about this phrase “everyone’s a designer.” I think that there’s a reason for that, which is, when you have some hard-won skills that don’t get sometimes the respect they deserve, you want to say, “no actually, we have some knowledge and qualifications that other people don’t.” And that’s fair, but I also think it’s true that everyone does make design decisions regardless of whether they bring design skills to the table or not. So decisions about back end architecture, well those end up limiting what we can do with the data later on. Decisions about performance, well OK, that determines whether your user is going to get up and get a cup of coffee or whether they’re going to have their transaction processed right then and there. So engineering decisions, legal decisions, pricing decisions, all of those things end up creating the user’s experience.

Kim [00:27:26] So yeah, that is all design. It’s a funny world where we want to own that title designer but the fact is that we’re never going to design the entire user experience. So actually I have to laugh a little bit at that term user experience because there’s no one team that owns that and there never will be. It’s just too dispersed. And so when we think about, “what’s the best place for us as designers to invest our time?” Is it in perfecting the pixels or is it in helping the legal team understand the impact of those goofy terms and conditions, right. Is it in helping the engineering team understand the impact of buggy software? I think that that is often a better use of our time.

Paul [00:28:04] Yeah. One of the things that I think is really powerful in that concept, that organizational concept, is how do we say to the organizations behind us, like the legal team and so forth, that they are having an impact on how our people are feeling, not our users but even just our teams, and we can put modules together for onboarding and we can put human language behind legalese that makes it a little bit more approachable and have less of an intimidating impact on people. There’s a really sort of counter-business cultural aspect to that that can be really just empathetic in the way that we think about those that we’re working next to and those that we’re building products for.

Kim [00:28:46] Absolutely. And I think that, you know, as designers we have the tools and the skills to understand how other people perceive the world and design experiences for that. And very often we don’t apply that same set of skills to our own work because we’re so focused on how much everybody is frustrating us that we’re not necessarily taking the time to realize, “oh, other people don’t know how to digest this or to think in this way, and, you know, we’re not giving them what they need in this interaction.” So if we design the way that we behave in our organizations I think that’s our best bet for getting back what we need and getting that better user experience out there.

Paul [00:29:23] Yeah. The cobbler’s kids have holes in their shoes.

Kim [00:29:26] Absolutely.

Sean [00:29:28] Alright, I want to flip that around a little bit. So we talk about, or you’ve talked about, being pretty adamant; get as many people involved in customer interviews and in front of customers as possible. I think that’s tremendously important but it’s also expensive.

Kim [00:29:40] Mhm. It can be.

Sean [00:29:41] So one of the things I’ve found useful, I just want to bounce it off of you and see what your thoughts are, is this concept of workshopping. So the thing about going out and watching, observing one customer or interviewing a customer or even a group of customers: each one only has like one set of linear experiences with you, right.

Kim [00:29:59] Mhm.

Sean [00:29:59] But if you think about the context of most real businesses today, at least the larger businesses that my firm tends to work with, customer service people, sales people, marketing people to some extent, and, you know, people in the value delivery chain that talk to hundreds or thousands of customers; they’re much more likely, in my opinion, to have an understanding of where your customers are exhibiting the most frustration or where we’re likely to get the most joy from them. And I think if you don’t have a conversation with those people in a structured sort of way to kind of try to extract that: “where are our customers being frustrated, where are they finding joy, how how might we design a better mousetrap for them?” I think there’s a missing opportunity there. So that’s one of things I try to do and I love it when we can get customers in the same room as those people to talk about these problems in a somewhat structured way.

Kim [00:30:48] Yeah. I think it’s a yes/and. I don’t think it’s an either/or. I absolutely agree that you need to get the customer service people, in particular, involved because, you know, they understand exactly where the frustrations are, they may have metrics to track, and they certainly have stories to tell you about how people perceive things. But they also only have a slice of the picture, right. They don’t necessarily understand, “how does this product fit into people’s lives and into other tools they use?” So I think there’s a role for that workshopping approach and I think there’s a very different role for sitting in someone’s context of use with them and understanding, here’s how this tool fits in their lives, and often coming to the humbling realization that your tool is a very small slice of their lives, is often a thing that that kind of contextual research will give a team that no other tool does.

Sean [00:31:40] For sure.

Kim [00:31:41] I think you need both.

Paul [00:31:42] Yeah there is, I think, something that comes out when you get those kind of conversations going because oftentimes, especially in the digital software world, you have stakeholders who will bring a number, a budget, to a team of people to build a product for people and that ripple effect of different concerns, different motivations, different hopes and fears, often gets mixed up when you’ve got all those people with each other. I think the more you can do to shorten the distance between them as opposed to artificially lengthening it, you’re going to get closer to that human-centered solution.

Kim [00:32:15] Yeah. I agree.

Sean [00:32:17] All right. To be respectful of your time, we’re just about at the end here. I always like to ask if there’s anything that you want to plug. Anything going on in your life that you want to promote?

Kim [00:32:26] Not really, no. I have been neglecting writing and so on lately so I don’t have anything new to promote.

Sean [00:32:34] Well you are going to be speaking at the ITX conference coming up pretty soon.

Kim [00:32:38] That is true and I’m looking forward to that. Yeah, so I’ll be doing a talk in a workshop there. That’ll be a great time time; I’m looking forward to spending some time with you all and your customers and getting to know your work.

Sean [00:32:49] Nothing wrong with a little shameless self promotion every now and then. All right and then lastly we always ask our guests your favorite book that you like to recommend to others in our field or something that you’ve recently read that you think has been impactful or powerful.

Kim [00:33:03] Oh, favorite book…. Um, well my book of course. Speaking of shameless self promotion. No, um, gosh. There’s so many books to recommend depending on what people are looking for. I think on the ethics topic Mike Monteiro’s latest book Ruined by Design is definitely worth a look for most people.

Sean [00:33:22] Ah, love it.

Kim [00:33:22] Well, just, if you don’t like the curse words just be warned. But Mike and I agree on a whole lot of things I just say them with less cursing than he does.

Sean [00:33:31] All right. Well if there’s one key takeaway that I got from learning more and more about you and reading your book, it’s this; it’s that great design and great products give people time and reduce their cognitive load so they can live better and more productive lives. So for that I want to thank you for joining us. And thank you for spending this time and thank you for coming to our conference and we’ll wrap it up.

Kim [00:33:53] My pleasure. Thank you both.