Embedding A Human Centred Design Culture

Tom Alterman, Baylie Brenner-Bruzgis, Lindsay Norman, Jim Longo at UXDX USA. Video: https://www.youtube.com/watch?v=SboysBm5VJ8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What is human-centered design anyway?

[00:00:01] Jim: How's everybody doing? Woo! Oh, come on, make some noise. I hate being that guy and saying, "come on, you can do better than that." I'm not going to say that. But this is about humans, all right? So I want to see the humans. Let's turn up these lights. It's the last panel of the day. How's everybody doing? There we go, there we go. Make some noise. All right.

[00:00:27] Jim: All right, we want to make this fun, all right? Because we've been here for two days and my social battery's draining, so I've got to recharge, and you're going to help me. And these people here on stage are going to do the same. So I want to make this as interactive as possible. My background is being a focus group moderator. This is the biggest focus group right here, that's what we're going to do. So I am going to encourage you guys, we're not going to wait till the end to ask questions, okay? If you have a burning question, raise your hand, we'll get a mic to you, and you ask the panel.

[00:01:03] Jim: So again, let's have fun, interact a little bit, and let's talk about human-centered design. What the hell is that? So let's talk about that. What does that mean? Baylie, Lindsay, Tom?

[00:01:18] Baylie: Oh, you said my name first, I'll go. So it has had several definitions depending on where I work. I don't have the answer to what human-centered is, but I think what we've tried to create where I am now is, how do we have a cycle to look at what matters for the users of our service, both streamers and viewers at Twitch. And how do we delight them?

[00:01:46] Jim: How do you delight? It's all about delighting them, right? Delight.

[00:01:49] Lindsay: Yeah, I'll admit that I looked it up a couple weeks ago, because I actually have not really heard of this phrase around the company, and even in my design career. I don't know, there's probably just a lot of terms trying to say the same thing, I think, in the design community. A lot of buzzwords thrown around.

[00:02:12] Lindsay: But I know from my experience at Hinge, when I joined, the problem I had initially was that I joined a team of designers who were sort of hybrid marketing designers as well as product designers. So I spent that first year actually helping the product team understand that they should no longer be doing the marketing work, and we needed to hire proper marketing designers and really get the product designers thinking about the research and the data. We also didn't have a research team, so pretty much spent a whole year training the team on what product design is.

[00:02:46] Lindsay: So there was a lot of learning there, and I think a big unlock was just when I taught the product design team that whenever they showed the designs, to really start with the framework of what problems they're solving, what do we know from the user insights, what have we learned about the data and the previous test. And I think that really set us up to earn the respect of the rest of the company and the leaders on the team.

[00:03:12] Jim: Great. Tom, anything to add to that?

[00:03:14] Tom: Well, the Oxford English Dictionary describes it as... I have two answers to that. One is the true answer, which is not as useful, is that for me it's about leading with empathy to the user, that all of your decisions are driven by that. That's a bit wishy-washy, so for me what I think about practically is, how do you know that you're doing it effectively? And that's really, for me the signal is, are the engineers, or even better the engineering manager, the sales leader in the company, asking questions about the user needs, or celebrating the users' needs, or calling out when we as a team are messing up, not through sales numbers or other metrics but by how well is this going to actually solve those customers' problems and how much they're going to love it.

Embedding empathy in the culture

[00:04:07] Jim: Okay, all right. So there's been a lot of sessions here and really the theme of this is around culture, right? And how do you embed empathy within your culture? You alluded to that, Tom, a little bit. So can you go a little bit deeper into that? Are people on your team actually talking to their customers? How is that information related back to your team?

[00:04:33] Tom: Yeah, well, I feel very lucky working where I do right now, because I've worked in a range of companies, from absolute messes to large organizations that really want to do this and never really did, to Asana where it's really just been drilled down from the founders down that this is how we work, this is in our values, this is just how we operate. Which is very weird for me, because I went in just ready to change the culture, do these things, and I was like, oh, you do it already.

[00:05:03] Tom: But what that is, is really making sure that we have enough time and space to truly understand the needs, that there is a touch point in the process of anything that we build where we call out, what are we trying to solve for? What evidence do we have to show that this hypothesis is going to be driven by solving those problems, and making sure that we can defend that to others and that we have the evidence to back that up. And it doesn't mean that a researcher has to do this or a designer has to do this, but the idea is that as a team they're accountable for doing that work and bringing that insight to the rest of the org.

[00:05:43] Lindsay: Yeah, something to add. So we have a separate research team that's really responsible for talking to people, getting the insights, really deeply understanding the problems that our users have. And I think that oftentimes, after that initial debrief where they share the insights, it can get lost along the design process. And so one thing I've really tried to train my team to do is, as the weeks go on and designers continue exploring in a space, with every crit, every meeting where they're showing their design work, to bring it back to, "by the way, imagine you're Sarah and this is your problem, this is your struggle and you have these behaviors," or maybe it's even, "you're this kind of person looking for this kind of partner."

[00:06:26] Lindsay: So just having designers really root everyone in what we've learned. And it can feel a bit repetitive, but I feel like that makes such a big difference in creating that culture of, oh yeah, this design is actually for a person and this is what they're struggling with. So just repeating that throughout the entire design process I think really gets people focused on why we're actually here and what we're trying to solve.

[00:06:51] Baylie: Yeah, we've used process, so I mean design ops, so a lot of it is process, but establishing what the process is for everybody too, so they know what's in it for me and why we should keep reflecting on those frameworks or whatever comes out of research. Whatever it might be, whether it's insights or the value prop for something in the end, tying all the work back to it, but also making sure that everybody on the team is aware of why you're doing it this way, comes from that foundation of process. So, revisiting everything from the ground up every time: okay, this is why we work this way, and these are the people who consume our product, and this is why it's important, every time there.

Process versus people and culture

[00:07:31] Jim: Okay, I'm going to just put this out here, because what we're talking about is a perfect world. Let's talk to the real world for a second, all right? Let's be honest with each other. How often has this happened, where you've gained the insights or the framework, it was passed to the product team, then to the designers, and then on to the engineers, but it doesn't link back to what the actual customer wants? Has that ever happened?

[00:08:00] Panel: Never. Probably. Never. Every time. Every time. Most of the time.

[00:08:07] Baylie: Well, yes. In poorer examples, it's usually because we didn't go back to that process that's laid out the foundation, and it's instead interpreted. So maybe someone in product is pushing the research in a certain way, or taking whatever insights they think helps with their incentives and might push that. So yes, in a perfect world that wouldn't happen at all, but process helps kind of save from that, which is, well, we don't really go just by what product wants us to research, or just by what the designer or business, quite frankly. It's everybody, and the research team, which is also separate from the team that I work with, gets to go kind of full force with that and not have to worry about hitting all the marks that product is looking for.

[00:09:00] Tom: No, just for dramatic effect, but I'm going to disagree with you there. Usually I've found that process — I've never managed to fix anything with process. I've managed to fix it with people and culture. My general theory with this is that people trumps culture trumps process. And usually when these problems, like this is a problem, or most problems I've seen with making teams successful, have been around, you try and solve it with process when actually it might be a cultural problem, or actually, fundamentally, you don't have the right people with the right attitude or skills, and that's what you need to change in order to make these other things happen.

[00:09:45] Tom: So when it comes to these insights, again, often if you have the right people and you have the right culture and they're looking for the same things, this will work out. If you don't, and a product person or a design person or a sales person has a particular pony, they'll just take whatever insights and chop off all the bits that don't fit their narrative and double down on the bits that do. And there's no process that can fix that, as much as I've tried in so many different ways.

[00:10:18] Lindsay: Yeah, I noticed something at Hinge, which was designers were venting about, every time I go into an engineering handoff they tell me half of it's impossible to build, or going to take three months, or we have to cut scope by 50%. And designers were just really defeated every time that happened, because they had worked so hard to create these beautiful flows. We had obviously shown engineering early, tried to get their buy-in. And I was like, how do you fix this problem? Because it feels so helpless as a designer when engineers tell you that they can't do something, that you can't really argue. And I'm sure we've all been there.

[00:10:53] Lindsay: And what I ultimately started with is that I noticed that the designers were DM Slack messaging their PM all the time, their researcher, other designers, and they just had these really intimate one-on-one relationships with everyone they worked with, apart from engineering. And so, to plus one Tom's point about people, I said, why don't we start with, why don't you ping random engineers while you're designing things? Ping random engineers, shoot them your designs, say, what do you think, do you love it, do you hate it? Start very casual, because ultimately if those relationships get tighter and there's more of that intimacy and collaboration, I think ultimately you create a situation where engineers don't want to do that, because they've been talking with the designer the entire time. So it seems a little bit of an odd place to start, but I really think there's no shortcut, there's no process for that problem. You need a better relationship with your engineers and then they won't do that ultimately.

[00:11:53] Baylie: Yeah, communication is part of that foundation, to be clear. If you have communication, if people know what's in it for them across the whole team, that can help solve it where maybe process falls short.

Sitting in on the research

[00:12:05] Jim: So I think it was Maya Angelou said, in order to really empathize with somebody you have to actually speak to them, to get the feeling, to feel them, right? And I know it's very difficult to sit in on the research side of it, and many times it's presented in a PowerPoint deck of some sort or something like that. So have any of you ever participated in the research, either as an observer, or looking at videos, rather than just taking a report and looking at a deck and then presenting that to your team?

[00:12:39] Baylie: Yes, so live watching it from the feed, and then having multiple note takers too, from different teams as well, so that the combined effort is, there's maybe not no bias, but a little less bias depending on where it comes from.

[00:12:55] Jim: Yeah, what I found is everyone's listening for something that's based on their role, right? And it's that debriefing that takes place after that research process, to understand where everybody's coming from. So let's talk a little bit about what happens when I'm just listening for what my role is and I'm just trying to validate my hypothesis. Ever happen? Often?

[00:13:16] Lindsay: I mean, I guess when you talk about research, one thing that comes to mind for me is, if we're trying to create a platform where anyone, regardless of gender, race, age, can find love, you better be [bleep] paying attention to research, or else you're going to exclude a lot of people. And we would be on the chopping block if we weren't paying really close attention to so many smaller groups that are often ignored.

[00:13:41] Lindsay: And the way we do that today is we have ERGs, these groups within the company. So the Black ERG, the LGBTQ plus, the handicap, all these different groups that meet, and they keep our company diverse, but they also look at the product in a pretty discerning way and ask the question, how could we potentially be excluding people? And just as a small example is people in wheelchairs. People in wheelchairs will ask for height, and so they'll be excluded from all these people who are setting these height filters, but it's actually handicap that they might want to explicitly call out. It wouldn't be fair to just lump them in with everyone else.

[00:14:20] Lindsay: So it's just so important that we have these groups raise these concerns to us. And sometimes it's really embarrassing when you hear the research, or you talk to these groups who are like, you've missed a lot in this product. But it's kept us really honest, and I think the last round of work we did was all about LGBTQ plus users and how we can make the app more inclusive for them. So we rely really heavily on them, at least to keep us honest.

[00:14:48] Jim: I'm going to Slack my marketing guy and say the new Discuss byline is, listen to the [bleep] research. Anyway.

Strong opinions, and when not to listen to research

[00:14:58] Tom: Not to play devil's advocate on this, but I also feel like you shouldn't always listen to the [bleep] research. But actually, it is important for great products to have a strong opinion, and that opinion may not be, if you just look at the research, or the insights, or subjectives, or data to drive your decision-making, you're not necessarily going to end up with the best product.

[00:15:22] Jim: Absolutely.

[00:15:23] Tom: But I think it's important to state those opinions, to have them strongly, but call them out on what is opinion, or what is a bet we're making, and at what point are you going to change course? Or what do you need to see that would make that bet change? And I think that's it, just kind of calling it out and saying, here's a bias, here's an opinion, and I'm okay with this until we see these other things. And I think that's a big problem that a lot of organizations have, is that they're not actually honest enough about, hey, we want to build this, we want to build this for this particular reason, and we're just going to make this bet. Otherwise people might waste a lot of time doing a lot of work that won't get attention, because the belief is so strong in that idea.

[00:16:18] Lindsay: I'll add one more thing to that, which is that I realized early on there's this tension with everything we want to design at Hinge, is pushing people to be more vulnerable and expose more of who they are, and that's naturally what so many of us do not want to do. And so how do you, I guess, nudge people that way, when most people in research will tell you, I don't want to have video, I don't want to have voice, I don't even want this many photos of me, I don't want to say what I'm looking for, I just want things to work. And it's a lot of pressure to put on a product, right? So I kind of agree in that, if we just listen to research, we'd be like, we can't do anything, we've done it all, it's done, you know? So you have to nudge, I think, more slowly.

[00:17:03] Tom: I had a really fantastic head of research at a previous startup I worked at. He was fantastic, because people would just come up and say, oh, we need to do some research on this topic, and he'd be like, why? He's like, well, why are you asking this? "You're the head of research, I'm sure you'd want to do this." And his pet peeve was, people want research, but really they should be asking, what's the question that you have? Is talking to users actually going to answer this question? Do you actually care about the results of this question? If not, then let's not waste time doing this stuff. And I think kind of calling that out is really important.

[00:17:44] Jim: It reminds me of the Henry Ford quote, right? If you go ask them, they would have built a faster horse. So don't always listen to research, but it's also what they don't say in the research, and I think that's important. But the cautionary tale that I always advise clients on is that it's about understanding the consumer and their lifestyle. It's not asking them direct questions, but you get more of just understanding, what's it like in the day of their life, and how does your product or service fit into that lifestyle? So that's more important, instead of saying, do you like this, should the button be here?

[00:18:22] Tom: Right, versus validating a hypothesis.

[00:18:25] Jim: Absolutely.

[00:18:25] Lindsay: Yeah, and a good research team should push back and be able to say — we love to ask our researchers, ask them if he'll try it, ask them if he'll buy it. And they're like, shut up, that's not how you do it. They know how to read between the lines, and so oftentimes the insights are just way more rich than that, and it's about designers taking the world of what someone's going through and the problems, and then being able to say, well, they want to know more about someone, and so here are maybe the ways we could imagine doing that.

Prioritizing and negotiating with engineering

[00:18:57] Jim: All right, so let's go back and pick on the engineers a little bit more, okay? Let's talk a little bit about that, and I say that in jest for any engineers in the audience, but I'm trying to be nice. So how do you deal with prioritizing the product development? How do you negotiate with the engineering team, especially in a mature model?

[00:19:20] Baylie: So we have two pipelines. We have road map related, that goes through your standard prioritization and based on feedback from users, but then we also have customer delight, which is anything that's been put on hold. We know it's really important, but it's not on the road map, so we can pull that in as we have time. So some of it's been prioritizing, yes, what resources are available in eng. If we have a lot of mobile resources available, immediately we'll prioritize that work, we'll do a hack week where we just get right into it, super week, whatever they're calling it now.

[00:19:56] Baylie: But we also bring engineers in earlier.

[00:20:00] Jim: Beautiful.

[00:20:00] Baylie: And everywhere I've worked, that's something that I've pushed really hard for, at the right time, because we don't want to waste anybody's time, but so that, one, they know what's in it for me, and they can share the feasibility really early on. We'll help with any prioritization in the beginning and then down the line too. But everywhere I've worked has been like a wagile, nothing is rapid kind of release, so just a caveat.

[00:20:28] Lindsay: Yeah, I'll just add that I noticed that big features always get on the road map, things that the PMs are really excited about, the big bets. But I started noticing when we were growing a lot and doing a lot of these bigger bet features that the quality of the app was slipping a bit, the polish was slipping. Noticed bad empty states, and you could tell that as a design team we just weren't being as thorough in all the places of the app that we used to, because now we're focused on the big ideas.

[00:20:56] Lindsay: And so one thing that worked for us is, rather than sort of nitpick at every visual bug or interactive bug, we decided to try and clump them together and do these experience sprints once a quarter. So rather than, it's tough to fight those little battles of just like this one pixel or two, but when you group them together and you say, hey, there's these 20 small things that we need engineers to focus on, I think you can get them a lot more bought into the process.

[00:21:26] Baylie: That was another kind of — so there's the one side that's the delight side of it to prioritize, but then to your point, Lindsay, we would do something similar for accessibility. Like, okay, how are we going to get them to redo this entire page so that the blue line work, any of the annotations, go in? It's like a whole, all right, so we have to basically look at what are the engineers working on right now and how quickly we can get those specs to them right away. So it's also like being human and working with the humans that are there, and people, right?

[00:21:58] Jim: People. Right. All right, we're going to take a pause here and let you ask some questions. So what would you like to ask the panel? Please, someone. Come on, don't make me pick somebody. No? You're getting all the answers right here? Hard to believe.

[00:22:20] Tom: You didn't put a plant in the audience?

[00:22:21] Jim: Yeah, no, did not. In the back there.

Audience question: is late feedback a process or a culture problem?

[00:22:35] Audience: Hi. This is a little funny because I'm an engineer at Hinge. Calling us out earlier, talking about how we say, oh yeah, we can't do that because it'll take X amount of time. Just kidding, just kidding. No, no, no, I completely agree with you, we don't like doing that. But kind of going back to an older point, where you said you never fix any problems with process: I always think, at least engineers, I always think, what's happening in the process that this is getting so late in the game, that this thing is completely designed and now we have to break some hearts and say, hey, that's actually really tough to do? So I guess how would you guys go about — is that fixing a process or is that something culture-related?

[00:23:29] Baylie: I know this one, I know this one.

[00:23:30] Jim: Go Baylie.

[00:23:31] Baylie: So that process cannot exist in a vacuum. You have to create it with the human beings that are going to use it. So engineers, they are human beings. They are. I know this because they have feelings too, right? They care. So how does that work for them? I just hate that idea of lobbing something over the fence to engineering. But I also hate the idea of saying, hey, engineer, full stack developer who's working on 15 projects right now, can you just come to this meeting to go through a kickoff of the project? Is that the best use of time? Probably not.

[00:24:05] Baylie: So process is working through that. Like, when is the best point? I've found a couple of different places I've been that an early preview meeting, to bring not only engineers but legal, risk, compliance or supervision, or whatever teams that you work with that are control partners, even marketing for go-to-market or pre-release. Come in, see this, we're at 20-ish, 25% fidelity at this point. Oh, there's value in that. We can say, oh, this is kind of feasible, I don't really need to see any more of it. Or, hey, this is a big blocker and it's going to cost this much money for us to do and we're not going to have time for it. So there's a sweet spot in creating a process for us, by us, by humans. But you're not lobbing things over the fence personally. I try to break that cycle.

[00:24:57] Tom: I mean, on the counterpoint of culture around the process, I tend to find that the best products I've ever built and worked on have happened outside of the process that were defined. And usually, again, I go back to this cultural thing, where if there's a culture of engineering being involved in the decision-making process, that everyone is accountable, engineering, research, tech leads, product, in what are we doing, why are we doing it, how that should work, then people will step up, will propose things, will give feedback at whatever stage of the process, rather than at the points where we said that this would happen. And a lot of the biggest needle-moving features I've ever had have actually often been engineers or sales people who are going completely rogue in the really nice process I designed for them, and just getting these things through. And that's the thing that really made the difference here.

[00:26:05] Lindsay: And I just want to throw in that I think remote work has made some of these parts of the process so much harder. You guys can probably all experience this, but whereas back in the day with a handoff of design, they will have been sitting near engineers, asking people to just take a look at something throughout the process. And I think that remote really highlighted just the lack of that relationship, and how it wasn't as strong as maybe our design team wanted, because now that design handoff was this really formal thing of, we got on Zoom, now I'm going to take you through the design. It just became less collaborative and casual because of the nature of working on Slack and working just mostly remote.

[00:26:49] Lindsay: So I think hopefully when we get back in the office, at least for our team — every time the design process gets formal, I get really nervous, because it puts a lot of pressure on design to have all the answers, and it's not the right way to work. So just the more you can facilitate those combos throughout the whole thing, the better I think the result.

Audience question: how do you make space for this work?

[00:27:11] Jim: Question? Okay, all right.

[00:27:20] Audience: Thank you for these insights, really cool stuff. My question is more towards, obviously that's very inspiring to all of us, this like experience sprints, this is a really cool idea. And then the versus, right, the road map versus customer delight, those are really cool ideas. My question is more organizational. So we all know those are great, how do you clear space for that? The ROIs of design and new weeks are very, very hard to prove, we all know that. How do you make space for that at an organizational level, right, prioritization level? What do you speak to? What helped you so far clear a way for those in case you're very monitored, let's say? And do you have any ideas there?

[00:27:59] Lindsay: Like how to celebrate sort of these things that are harder to measure on the design side. Yeah. For us it's a big challenge, I don't know if I've solved that at all. But I think one thing that's helpful is, I call it emotional wins. So I don't talk about it in terms of delight, but truly if we do something that makes people feel really good — I think I can get away with that at Hinge because dating's so shitty and it feels bad in so many places. So, trying to talk about how that is so much a part of creating a better experience. It's not just getting people to use it more or whatever, but people need to feel good while they're using it too.

[00:28:39] Lindsay: And what we try to do is, whenever we have one of those moments, that's when you want to double down on sharing out the videos of people going through it and saying, oh my god, this made me feel so comforted, or, I was feeling so rejected before and with this new animation or action, whatever it is, I felt better. So just really broadcasting and celebrating when you do that, because those are just feel-good moments, even if it's in front of the whole company. And then you're sort of establishing a culture that values that side of UX.

[00:29:15] Tom: If I understand your question correctly, please correct me if I'm wrong, it's around, if the company isn't valuing that and giving the time and space to design and research, how do you change that? My somewhat spicy take is, don't. Just go find somewhere else that does. I've spent a lot of time fighting this battle in various different formats, and my experience is you can go from [bleep] to less [bleep], but that requires a lot of emotional energy, because you're swimming against the stream that is just really hard to swim against.

[00:29:59] Tom: And I go back to John. John had a great talk earlier about this and how you change culture. And the thing is, it's not intentional. If you talk about human-centered design, there's no CEO that's going to go up and say, we don't care about human-centered design. Everyone's going to be like, we really want this, we really want great design. But when push comes to shove, there is some thing that is higher in the value stack. And you can look at that thing and see, how can you turn insights and research and design and measure it by that thing that people measure and show success? And we can talk later about all the tactics I've used to go through that. But ultimately that's not a fight. There are so many other places where you don't have to fight that fight, that I would just suggest you go and work there.

[00:30:45] Jim: Just quit. The answer. Career counseling, you know, you get that here. There was a question over here?

Audience question: companies that say one thing and do another

[00:30:58] Audience: When we talk about embedding a human centered design culture, there are companies that may proclaim that this is their goal, but when you further examine the culture and how things are prioritized, it may reflect just the opposite. How do you approach helping a company like this self-reflect and transform into really becoming a human centered design culture? This can feel like a moving mountain.

[00:31:23] Jim: I feel like I can't, because they're talking into a box. It was really hard. Can you take the mask off and just say that? Yeah, no worries. Okay, so Christian asked, when we talk about embedding a human centered design culture, there are companies that may proclaim that this is their goal, but when you further examine how things are prioritized, it may reflect just the opposite. How do you approach helping a company like this self-reflect and transform into really becoming a human centered design culture? This can feel like a moving mountain.

[00:31:54] Tom: Burn it down. Burn the company down, is basically what — I could give a slightly, okay, if you're deciding, okay, I'm going to commit to this very noble cause. Again, figure out what are the things — there's like a strategic thing and a metric thing. One is, look at what actually matters. What gets the recognition and celebration? Is it ARR? Is it certain customers? And just talk in that language. Make sure that whatever you're celebrating is in that way and it shows that ROI.

[00:32:25] Tom: The second thing is just show, don't tell. So don't try and pitch this, don't try and get people to academically agree with you on this. Go find a problem that is a problem that's big enough that if you solved it people would celebrate and take notice, but not such a big problem that it's in the eye of Sauron, that all the executives are looking at it and will panic if you try and do things a different way, or call you out if it messes up. And just deliver it with that and then get the ball rolling in that thing, and try and virally create excitement, because other people want to get on this train of success that you created.

[00:33:06] Lindsay: I think one small thing I did when I first joined Hinge, because I realized that it sort of didn't feel like the human-centered design part was big enough, is I paid attention to our all hands, which was every Friday, to talk about what's happening in the company, what we're celebrating. And I noticed mostly what was shown was graphs. Pretty much every Friday was a lot of graphs, a lot of things happening. And I realized that I previously worked at Pinterest and they were sort of just the exact opposite. Everything that happened at Pinterest in all hands was all around a person. There were user videos, they were just really amazing at that.

[00:33:47] Lindsay: And so I worked with the people who produce all hands and I said, we should just show faces. Even if it's, let's show off some faces of actual users. When we talk about features, let's show a quote from someone who's talking about it. Let's just bring in the picture of people using the product. And it's kind of amazing how it's subtle, but it sort of reminds people, and I guess I've said this earlier, but reminds people that we're designing for humans. These graphs are about humans using these things. And so paying attention to the way things are talked about and changing that storytelling or packaging of what you're doing can actually, I think personally, have an impact. It's hard to measure but it's just like that subtle nudge every week.

[00:34:36] Jim: Humans are not data points, right? All right, we're up on time. Thank you everybody. They'll be around this afternoon, so if you have any questions, please intercept us at some point, or buy us a drink, even that's even better.

[00:34:51] Tom: Aren't they free?

[00:34:52] Jim: Yeah, they're free, I know, I know. All right, thank you very much everybody, have a good afternoon.