Transcript

Natalie Kurz: Cooking is very analogous to software development in many ways. 

Gina Trapani: It really is. It is.

[POSTLIGHT INTRO MUSIC]

Chris LoSacco: Welcome to the Postlight podcast. Postlight is a digital strategy, design and engineering firm where we talk about the world of software design and development. And I am Chris LoSacco, the president of Postlight. Joined as always by my partner in this business, CEO of Postlight, Gina Trapani. How are you, Gina?

Gina: Hey, Chris. Good. How are you doing? 

Chris: I’m doing very well. We have a very special guest from Postlight on the show today. 

Gina: Yes. 

Chris: Natalie Kurz, our head of design. Natalie, hello. 

Natalie: Good to be here. Hello! 

Gina: Love having you on the show. Good to see you too. 

Chris: So, Natalie, you recently wrote a piece for our website called “Reduce the Risk of Getting It Wrong,” and the genesis for this piece was not about software design, which is what we’re here to talk about. 

Natalie: Right.

Chris: The genesis for the piece was a refrigerator.

Natalie: It was, it was actually.

Chris: Tell us what happened. 

Natalie: So we—we started getting the smell in our kitchen, right? And it was just, it was the smell of death. There was, there was no doubt..

Gina: Not a good smell.

Natalie: Yeah. You walk in. Hit in the face, smell of death. 

Gina: Oh. Oh. That’s not the smell you want in your kitchen. 

Chris: Right. It wasn’t like lasagna or.. [crosstalk]

Gina: …chocolate chip cookies…. 

Natalie: And it wasn’t even like, “oh, there’s a rotten tomato.” Right. “There’s a rotten tomato in the fridge.” Yeah, it was, so we cleaned the fridge out. You know, our, our kitchen shares a wall with the garage, so trying to look in the garage. You know, my partner went up in the rafters looking in the attic, trying to figure out like, where did this thing die? We could not figure this out. Finally, we pulled the refrigerator, you know, out and we’re checking under the refrigerator and that’s where the smell’s coming from. So somehow some kind of critter got up into the mechanism of the fridge and you can’t take that thing apart. So I was like, new fridge time. So I literally..

Chris: New fridge time. 

Gina: New fridge time. 

Natalie: Yeah . Just done and..

Gina: I’m so, I’m just so sorry. How long did this go on? Because it really kills cooking at home. 

Natalie: It was like 3 days. 

Gina: Oh, it did? Yeah, yeah, yeah. 

Natalie: We couldn’t eat. We couldn’t eat at home. We ate out. We ate at my mom. 

Gina: Seamless, GrubHub. 

Natalie: Yeah.

Gina: Yeah.

Natalie: Exactly. And—because we couldn’t even be in the kitchen, right? It was just that bad. There’s literal preamble to this whole thing, which was I’d ordered all new kitchen appliances back over the summer, and when they tried to deliver them, they could not get the refrigerator through the door frame. 

Gina: Oh, you have one of those houses. 

Natalie: Too big. They could not get it in. We would’ve had to take all of the molding off the door. And it was like a package deal. We, we returned all of the appliances. So now I’m faced with, “okay, now I need a new fridge and I need one tomorrow.” So I went in and I jumped on Google and I started Googling like stainless steel fridge delivered tomorrow, right, and my zip code. [laughs] Like, that was the criteria.

Gina: As one does, right? 

Natalie: I didn’t care what brand it was, I didn’t care if it had good reviews. I just needed—I need this thing outta my house. Actually, ’cause they—they were doing haul aways. So they did haul away the stinky fridge. 

Gina: Wonderful.

Natalie: So the lesson I learned for the first time was measure, you know, make sure that it’s a counter depth fridge, make sure that the outside’s gonna fit through the door, right. So I was very specific in looking at that. and I wanted it to be delivered tomorrow. Right? Like those were my criteria. So I found a Frigidaire refrigerator, it was delivered the next day. They got it through the door. There was much celebration in the house, right? Like, yay, there’s…

Chris: Like, “Yay, happy ending!”

Gina: Yay! 

Natalie: And then we—we pushed it in and I got one where the left door was a little bit less wide than the right door because we’ve always had a problem with the door not quite opening, ’cause it’s butt up against the wall. 

Gina: Mm-hmm. 

Natalie: And this one was even worse ’cause the door itself was so much thicker that you get about four inches of opening on that left side door. Like you cannot open the left side door. 

Gina: It’s a two door fridge, right? 

Natalie: It’s a two door. Yeah. It’s a—it’s a French door, right?

Gina: Uhhuh. Uh Huh.

Natalie: And so you open the left door and it hits the wall after about four inches. 

Chris: Ugh.

Natalie: And so, We realize this and it’s like, okay, do we return this one and wait to find some other fridge? Like they don’t have the thickness of the doors as a..

Gina: Speck?

Natalie: You know, typical speck. Exactly. And so it’s like, are we gonna go around to every store and see what’s in stock and measure this? 

Chris: I’m exhausted.

Gina: So how..

Natalie: Yeah. 

Gina: Can you get into it? Can you open the door enough to get into it? You just can’t open it all the way. That’s what I’m saying. 

Natalie: Yeah. You can open the right side and then like, you can’t open the left vegetable drawer like that. There’s no way you’re getting in there . Like the vegetable drawer, you know, on the bottom, like it’s just..

Gina: Gotcha.

Natalie: It’s there for looks now. 

Gina: Got it. And is the, is the freezer kind of the drawer on the bottom? Is that..?

Natalie: It’s the big drawer on the bottom, that’s all cool. Like freezer door’s great. 

Gina: Cool. All good. That works. 

Natalie: So it’s funny now. It was not funny then. 

Chris: Yeah. 

Gina: Humbling. I mean, I’m feeling humbled. 

Natalie: Yeah. It became one of those things of like, is this something we can live with, you know, for the duration of, of being in this house or not? And it also became the thing of, I really pray that when we go to sell this house, they don’t try to open the refrigerator. [laughs] you know? Cause it’s those little annoyances that—that factors into decision. So anyway. 

Gina: I’m so sorry. And let’s just take a moment. I’m so sorry. That had to have been so frustrating in the moment. I’m sure that is like an just a, a minor fact of your life now that like doesn’t, doesn’t bother you at all, like, which you shouldn’t but it, but I can imagine the moment just feeling like I just dead inside. 

Natalie: It was. I felt like such a failure because I had focused so much on the exterior measurements of the fridge because of the other experience, couldn’t get it through the door that I didn’t even think about those types of things. 

Gina: Right. 

Natalie: And so this started leading me down that path of, we do that all the time in software development. 

Gina: Yes.

Natalie: We focus on one thing. We think this one thing’s gonna be the problem, or this is where we need to put all our effort and we leave out this other detail. And that detail could be the make or break of like literally a usable product or not. 

Gina: The entire experience. Right.

Natalie: The entire experience. 

Chris: But we should unpack this because it’s hard for people, right? Because we often read things and listen to things where it’s like you should pick the one or two key things that really matter and focus on them above all else, right? Which is what you did in this fridge scenario. You were like..

Natalie: Right.

Chris: “I need it to fit through the door. And I needed to come tomorrow.” Like..

Natalie: Exactly. 

Chris: It was very clear that those are the two things you were prioritizing, but..

Gina: It didn’t fit in the space.

Chris: Didn’t fit in this space.

Gina: Yeah. 

Chris: Yeah. But there was a fatal flaw. And, and I think it’s interesting. Again, it’s an interesting parallel when you think about software design to think about, you know, yes, there’s value in having a clear focus area to your product, but if you are too neglectful of the other things, you could end up making a major mistake. And I’m, and I’m curious like how do you strike the balance? And where, where do you think the right equilibrium is, Natalie, as you think about like how to spend your, your team’s effort?

Natalie: Yeah, absolutely. So you’re right, I think having primary focus is really important because you can’t solve every problem for every person, right? Especially when you’re on a budget, you’re on a deadline. You do have to prioritize. That’s really important. But I think what, what it really taught me is like, don’t forget to look at some of those little details, especially when you have some time, right, upfront to get an understanding. It’s really getting an understanding of the holistic problem. So if I’d gone into this fridge buying process understanding or, or with the in mind, the problem that already existed of my current fridge, you couldn’t open all the way. Right? So already taking that into account and factoring that in and then adding that as some kind of research metric or, you know, I’m gonna dig up and try and find a spec, or try and find a picture and judge, you know, how thick the door is. I could have addressed that and I could have maybe made the problem better instead of worse. Cause I literally did make that specific problem much, much worse than it was aside from the smell the day before. Right? 

Chris: Right. 

Natalie: And, and so I think about research as kind of trying to do three different things, right? The first one is, what problem are you solving? So for me that was a really easy one, right? I need a new fridge. But I need that new fridge in such a way that I can open the left door, and that was the detail that I was missing. Right. And so if I had done, let’s say, like a whole system audit of how is my current fridge functioning? And you know, I, I probably could have taken that into account.

Gina: I mean, you were also under duress. You got kids, you gotta cook dinner. You were like, I need to solve this quickly. Like you were optimizing. 

Natalie: Absolutely. Yeah. Timing was everything here. 

Gina: Like, get, let’s get this tomorrow, which totally understandable.

Chris: And most projects are optimizing for speed for the record. 

Natalie: Sure. That’s right. 

Chris: Yeah. 

Natalie: Absolutely. But it was understanding the problem. And you know, thinking back, I was trying to think of a good example from a project in my career. And early in my career, I did a project for Canon, and it was part of their B2B business, right? Selling giant printers to businesses. And as we were looking at the, the product detail page and trying to figure out like what information is important here, in our minds, we had like one set of criteria. And after we started really talking to the users and understanding like it’s not necessarily the IT, the head of it that are making these decisions, right? It’s maybe a researcher or an executive assistant or something else. It reprioritized all the information and kind of the function that that page needed. You know, it was more about benefits, right? Layman’s terms. It was not very, very specific technical specs, so having an understanding of like, what’s the problem? The problem was they couldn’t understand the current page, right, enough in order to be able to make that decision. 

Gina: I wanna pause here for a minute. Like, the point that you’re making is understanding what the problem is is such an important one. And I wanna own up to the fact that I have been the person who, when embarking on a project, a designer or someone smart and who’s wants to think about this, you know, take this beat to think about it, has said to me “what problem we’re solving for?” and my immediate reaction was to feel impatience. Like, it’s so obvious what problem. Like, “you see what’s going on? There’s a dead thing under—that we’ve eaten out every—we have to get a new fridge..”. Like I would, I would be like, “Ugh, this is a waste of time. Why are we wasting our time sitting around talking about the problem, the problem’s so obvious.” right? And I think that’s really, I think that’s common, and I think that’s something that you really have to—you know, as a leader, I’ve really tried to be like, okay, let’s just take a breath.. 

Chris: Mm-hmm. 

Gina: ..And do this. Right? Because articulating the problem is really so important because if you don’t, and there isn’t a complete understanding that shared amongst everyone, you’ll go down a path and not be able to open your refrigerator door. 

Chris: Exactly.

Natalie: Right. 

Gina: Like that’s—that’s a real thing. 

Natalie: Yeah, exactly it. And I’ll say, you know, this goes beyond just the initial like, discovery of, of big picture problem. Right. I think this, this is really important to think about on a user story by user story basis. There’s a reason user stories are written from a user perspective, right? And, and those user stories should be focused on solving a problem. And, and that’s a big phrase that, you know, I know the designers here will shake their heads yes. You know, design for solving a problem, not for building a feature right?

Gina: Mm-hmm. Yes. 

Natalie: And those are two very different things. And so if you’re writing a user story from the perspective of, okay, the user needs to accomplish this, this is a problem we’re solving that we’re trying to solve for the user, that leaves you lots of areas for exploration and innovation. That’s where the big ideas and those key points of differentiating can come, is in the execution of that solution. Right? So coming into a situation where you understand the problem space and then working through building and developing that product, that’s how you come to those solutions. That’s how you solve the problems. That’s where that innovation comes from.

Chris: It’s such a good point. It is very easy to conflate. “I want the platform to do this thing” with “this is the task I am trying to finish or the problem I’m trying to solve or the thing I’m trying to accomplish.” And one of the tricks that I have seen really effective designers use is when they get a feature request, they reframe it around, oh, you know what I’m hearing is that you want to try to do X, and it’s very helpful to sort of coach key stakeholders or someone doing a user test or something like that around exactly what you’re saying solving a problem. And then taking a very wide, a wider look at how could we go after that problem versus I just need to address this specific thing in the interface. 

Gina: Right. Design the button and the dropdown. 

Natalie: Exactly. 

Chris: Right.

Natalie: And sometimes it is that simple, but wherever possible you wanna take a step back and, and understand like, okay, well, is that the right button? Is that in the right placement? Is it labeled correctly? Right? Is it clear? Is a button even necessary? Right? Like, you wanna look at all this? What, what are we trying to solve? And then does this adequately solve that problem? And that does it a adequately solve this problem? That’s another part of the research, right, is validating those solutions. And that is absolutely a continual thing throughout a project. Just like, you know, what problem are we solving is not a one-time upfront discovery. And, and that’s why like, you know, giant spec document where we’ve got, you know, a thousand requirements up front and this is what we’re building. Like that closes you off from, from innovation and, and discovery. 

Chris: Exactly. 

Natalie: And learning as you go. Like, that’s actually not what the users need. What they need is this. And that’s, as a designer, those are my favorite moments of a project is that aha moment with, with users of like, oh my gosh, I understand now what you actually need is this.

Chris: Yes. The thousand page requirements document is a false security blanket. 

Gina: Yes. 

Chris: Because you can, you can trick yourself into thinking, oh, these are the things that are in front of. And lose the, the truth of the matter, which is that there’s a person that’s gonna use this interface and that’s what you have to be thinking about. I, I like the way you’re describing it, Natalie, again, because it’s like, this is not research for research’s sake. Right? This is a very practical, we are thinking about the people using this interface and what they are trying to do and how we get at that core. Not, you know, we’re going to write up a bunch of documents because we want to fully understand the problem we’re solving or something like that. There is a, a practical application of what you’re talking about, which I think like resonates more for me than, you know, I want to do a research effort just because I wanna produce a document or something.

Natalie: Exactly. Yeah. Documentation for documentation’s sake doesn’t benefit anybody. And when you think about research, I think most people think about, okay, this is gonna be a three week process and we’re gonna create a moderator’s guide and we’re gonna have to recruit people based on these demographics. And it’s like, that is one way to do research. But you can also like phone a friend, right? Like, again, depending on what your system is, but if your system’s, you know, something that the whole public’s gonna use, like talk to a couple people, you know, talk to a couple people at your company, right, that aren’t involved in the project..

Chris: Hallway research.

Natalie: You can do that type of gorilla testing, hallway research, exactly. And you can do that remotely, right? It doesn’t have to be a literal hallway anymore, which is nice. But you know, get it in front of someone. And a lot of the systems, I think that, design, there are internal users as well. 

Chris: Yeah. 

Natalie: And sometimes those can be easier ’cause that’s, that’s like your stakeholders or or other folks on their team.

Chris: Yeah. Go talk to ’em. Right. 

Natalie: Move into a room and let’s, exactly, go talk to ’em. One of the best experiences of my entire career, we had so much access to our internal users. We literally had daily design standups with them half an hour. Where? Where every day, every single day we went over design with them and got ..

Gina: Wow.

Natalie: ..Feedback in real time. Yeah. Such an incredible credible privilege to have that kind of access and we were able to work so much faster.

Chris: I’m curious though, what, do you have a sense for how they received that? Like did they like that daily meeting? 

Natalie: They did it. It’s really interesting because it also helped with adoption and with ownership because all of these different internal groups that we were working with had seen the system. They were part of the decision making process and we got to help educate them. You know, they would give us these ideas and say, oh, okay, what? What if we solved it this way? Or a lot? A lot of times they were just telling us how they currently did something because all they wanted in their heads was, I wanna be able to do the thing that I’m doing, but just better and have it look nicer. And for me, that would’ve been failure. That bar would’ve been failure to give them the same thing they had just look nicer. I wanted innovative ways to solve problems and they would tell us, okay, this is what we could do. And then we’d show them the next day at design and they’d be like, no, no, no. That’s not what we asked for. Right? And so we’d take them a step back and, and talk through, well, this is why we got to this decision. We talked them through our process and after a couple months, they really got it. They understood UX, they understood how we were making decisions and they understood how it was improving their product. That led to, that’s a whole other podcast, right? As separating user wants from user needs.

Gina: I’m gonna have to do that one. 

Natalie: I’ve done a couple, couple conference talks on that on that topic. 

Gina: Oh booked! Consider it booked. 

Natalie: That’s got a whole other analogy involving frozen chicken. 

Gina: Oh, yes. 

Chris: Sensing a theme.

Gina: Frozen chicken. You very [crosstalk] centered themes here, Natalie? 

Natalie: I like food. I like food. 

Gina: I know I, me too. I respect it. 

Natalie: But so to your question of, of how do they receive it? It was very well received and it gave us opportunity to help improve kind of their understanding of what their problems were. And it was really wonderful. We got to see the aha moments with them when they were looking at it and they’re like, oh. Oh my gosh, that is a better way to do that. I never, I never would’ve thought of that. We heard that so much during that project. I never would’ve thought of that. And we were able to increase efficiency so much. They literally got rid of one of their departments because what was taking them several weeks to do? We automated with a single button. It really was an easy button. It was like the best example of an easy button I will ever have. Those people weren’t let go. Those people weren’t were they were.. 

Gina: Reallocated to higher value work.

Natalie: Exactly. Exactly. And it was so satisfying it, it was absolutely satisfying and it did deliver what they needed. So involving those users is a great way to get that buy-in change management, all of that’s so important, especially with internal systems where they’d been using this for 30 years and so many of the people there had been, had been there for decades and this is what they knew and they had their little workarounds and you had to understand, okay, the workaround is trying to solve what actual problem that your system couldn’t and why did you have the workaround? Was it ’cause it was a technical constraint or was it Some of it was a physical constraint. Right. We, we had example there where I saw one clerk printing out labels to mail documents to, to the folks that they were trying to communicate with. And then I saw someone else printing a cover, right? From a different department. And I’m like, huh. And so I wrote down, you know, requirement, we must integrate with label makers. Okay, let’s talk to devs, right? This is very important. And then I sat with it for the rest of the day and I’m like, that’s not the right question. That’s not the right thing here. So I went back to her and I said, why do you print labels? And she doesn’t? Well in her part of the system, they can print cover sheets. We can’t do that in our part of the system. And we were given regular envelopes and they have windowed envelopes and so we can’t. , you know, we need to print these labels or we’d have to hand write them. 

Gina: Wow. 

Natalie: So I’m like, I’m solving the wrong problem. 

Chris: Mm-hmm. 

Natalie: I’m not—so, you know, the problem I need to solve is not how do I integrate with the label maker? It’s how can I very easily get an address on this envelope? 

Gina: Different question. 

Natalie: Yeah. But, but that involved research that involved asking the right questions and, and coming in with an open mind and not taking things that face value of, “oh, I’m just gonna integrate with a label maker.” 

Gina: Those windowed.. 

Chris: Yeah, that’s a great example.

Gina: Great example. Those windows envelopes, they’ll really get ya. They’re make or break those envelopes. Geez. 

Natalie: But think about it, think about how much money that was costing them. They, they’d, they were renting, you know, dozens of these label makers and having two different types of envelopes to keep track. Like, it just, it, it gave them so much efficiency and it was, it wasn’t a problem that anyone thought to solve. 

Gina: Yeah. 

Natalie: They’re just like, this is how we do it. 

Gina: Right. This is just how we do it. 

Chris: Yeah. 

Gina: You know? Yeah. It’s, I mean, it’s just so easy to get carried along and the inertia of the, that this is just how we do it.

Chris: Of course. 

Gina: It helps so much and I think a lot of times our clients bring us in cause they’re like, we just need a fresh set of eyes here to just dig in a little bit. 

Chris: Right. We’re, we’ve been drinking our own Kool-Aid for a long time. 

Gina: We just, right. We’re just so steeped in the day-to-day, you know, this is just what my job. is how it works to say why.

Natalie: Right. Exactly. 

Gina: Mm-hmm. 

Chris: I wanna go back to something you said before Natalie. Like you made such a good point, which is that in asking questions to get to the root of the problem, it’s not just about taking what people are saying at face value, it’s about understanding what they are trying to do and then applying..

Natalie: Exactly.

Chris: ..Great design thinking around what they’re trying to do. But here’s, so here’s my question. Do you think that you can over research something and lose sight of that and get too caught in what people are saying? Because you know, I worry that sometimes design teams are like, I’m going to try to exhaustively ask questions so that everything is obvious versus having to do that like problem solving type thinking, which is not, which is not gonna happen in a user interview, right? It’s gonna happen after the fact when you figure it out what that person is trying to do. So, yeah. So the, so the question I’m, I’m wondering is how much is too much? And when do you. , stop the discussion and get to a whiteboard or open up Figma or whatever the, you know, next step is?

Natalie: It’s a great question. I think it’s gonna vary from project to project. You know, the short answer is yes, you can research something to death, right? Because doing research is not actually building a product, right? You’re not actually building anything. At that point, you’re just trying to gain knowledge. And so there has to be a point when you shift gears to, okay, now let’s actually start ideating. And so I think it’s gonna vary from team to team, from project to project. But for me it’s like when you start getting a sense—like when, if we’re talking about upfront discovery, let’s say, let’s frame it that way, where it’s, it’s we need to understand big picture stuff. It’s when you start to piece that stuff together and you may still have questions. You don’t have to have everything figured out. I guess that’s the key. You don’t have to have everything figured out. If you have enough figured out that you can start ideating. That’s the time to start ideating. And, and I think this is a mistake teams make too, is I wanna understand that the entire system, I wanna have the entire system kind of framed in my head before I start putting pen to paper. You’re never gonna get it right? 

Chris: Yes. 

Natalie: So that’s kind of a waste of time, right? So let’s, let’s take a piece of it. and let’s focus on that. Let’s do some research around that. So I, that’s why iterative research throughout your project is so critical, because you can’t know everything upfront. You’re going to learn things, things are going to change. There’s going to have to be some rework. You have to build your system in a way where it’s rework becomes easy and smart as opposed to, you know, just a giant time suck. But yeah, I guess it’s, it’s research until you get to that point where you feel like you have enough to start putting pen to paper and working through. And then the key is get that in front of a user. Does it actually solve that problem? And oftentimes during that you’ll go, okay, it does solve that problem, but maybe it creates a new one. Or maybe it leads you down a path of, oh, here’s another problem to solve that I didn’t know existed, right. So it feeds off each other.

Chris: Right. You’re not, you’re not done after round one. There’s gonna be multiple rounds of this. 

Natalie: Yeah, exactly. . But it’s important and it’s important to do kind of on an ongoing basis. Another aspect of this is, is, you know, we talked about what problem are you solving? We talked about doing like usability testing, put it in front of users to, to understand is this solving the problem the right way? Right? Am I adequately solving the problem? And I have a great example of that too, where it’s like we did exactly what the users asked for, right? They wanted to be able to send documents to each other and attach messages. Right? ’cause it was a workflow based system. And so we built that and we tested it individually and each person using it individually. It worked. It worked for them. It was great. Then we did kind of an innovative round table usability test where we watched a case go through the entire system. It was a case management system. 

Gina: Mm-hmm.

Natalie: It go through the entire system. So we saw all the different people touching it and we found out that the system that we built this part of it was not what they needed at all. There were so many issues once you had human beings involved, in passing the hat, right? Essentially. 

Chris: Yeah.

Natalie: Right. Like they were trying to pass the hat to each other. I, I’m holding the hat and it’s great and I can hold the hat, but wanna try and pass it to the next person. There’s a giant wall on my way and I can’t do it anymore. And so in discovering that, we realized they don’t need to send documents with messages. They need to send messages that sometimes have a document, right? 

Gina: Mm-hmm.

Natalie: But we built it in such a modular way. We, we fixed that in about two weeks. It was not like, let’s tear the whole thing down..

Gina: Oh, that’s great. 

Natalie: …and rebuild. But we did it early enough where other things that would’ve been dependent on that, you know, we didn’t have to go back and rebuild those because we did it kind of in real time. If we hadn’t have caught that for six months, there would’ve been a massive amount of rework. 

Chris: Yeah. The, the pull quote from the episode though is you know, there were so many issues once humans got involved because, Every, every project ever I feel like you make that statement about it. 

Gina: That’s true. 

Natalie: Yeah. 

Chris: I remember a similar project that I worked on many years ago. We were doing a search interface and there was basic search and advanced search, and we got basic search. More or less figured out very early on. And then we spent a lot of time on an advanced search interface that let you do some really, like, impressive, you know, you could, it was a database of structured elements, structured things, and you could dive down really deep and really specifically and do some like incredibly impressive stuff. And this is probably 15 years ago. So it was, you know..

Gina: For that time. 

Chris: And for that time it was..

Gina: Amazing. 

Chris: …it was, you know, really differentiating and nobody used it. Nobody.

Gina: No one clicked advanced. Nobody. Everyone.. 

Chris: Exactly. 

Gina: …Type into the search box and pressed basic or what? 

Chris: Yeah, exactly. And if they did click advanced, they bounced off the interface. They were like, this is too, and we, we tried to make it..

Natalie: Too hard. 

Chris: I mean, you can probably picture it in your heads, right? It was a set of fields and you could add multiple, you know.. 

Gina: Criteria. 

Chris: Rows of criteria. Exactly. 

Natalie: You know, is it and or ORs 

Chris: Yeah, exactly.

Gina: Yes. 

Chris: And it was, again, it was very powerful and for probably a dozen users it was like, this is amazing for my use case, but almost nobody used it. And what we, in, in retrospect, what we should have done. And I think if we were following a process where research was more ingrained in the design, we would’ve invested more in making basic search smarter, as opposed to building advanced search.. 

Gina: Right. 

Chris: …With, with a lot of power. Yeah. So it’s, it is interesting and I, and the idea that, that research is not, it’s not this like three week phase that you do upfront and then you’re done. I mean, I think hopefully what people take away from this is that it’s ongoing. It’s something you have to build into your process. And the way that it reduces risk is because you’re doing it sort of throughout the development effort. Right? And you’ve got your design consistently reevaluating, what are we doing? What is the problem we’re solving, and how do we let this build in, you know, iteratively over our development. I, I think that’s, it’s such a smarter, more effective way. To pull research into your, into your team and into your effort then, then this like, you know, targeted phase upfront. 

Natalie: Yeah, absolutely. Absolutely. And, and another aspect that I don’t think people maybe think about as much when you, when you’re thinking about research is, you know, you mentioned the entire team and while designers typically, or strategy, you know, folks are the ones leading this research, it’s important to have the whole team involved. And so we actually had some of our backend engineers facilitating workshops with us there to help, right? But facilitating a one-on-one usability test with one of the internal users and their reaction, getting to see a user use the thing that they built, actual people, it was eye-opening for them and it gave them way more empathy. Right? Throughout, throughout the build. And, and when we discussed, you know, the trade-offs that you, you always are gonna make between like level of effort and how much is it helping the user and like we have to find that happy middle ground. They were much more willing to kind of negotiate that and, and understand that. Or understand the concessions that we’re making with the user because we really did have to do it the simpler way from a technical standpoint, but they understood what we were giving up. 

Gina: Mm-hmm. 

Chris: because they saw it firsthand? 

Natalie: Right, right. In in, in doing that, in those cases, ’cause they saw it firsthand. And you know, same thing with product owners, internal stakeholders, anyone that you can get observing even after the fact. Right? Recording a usability test and then being able to show your stakeholders later, or show them clips or pull out quotes to show them exactly what it. That that your user said is really, really important. 

Gina: My programmer brain. The other metaphor, I think about a lot with software development is taking a trip. So, like for me, and, and you two tell me if this is right, I’m thinking about, you know, you’re like, okay, let’s go, let’s go to Europe. We’re gonna do a trip to Europe. Right? And, and the research phase is.. 

Chris: I’m in. 

Gina: Yeah, let’s do it. 

Natalie: Yeah. 

Gina: But the research phase, like.. 

Natalie: When did we leave ? 

Gina: Let’s do it. It’s like where? What city? The research phase is actually setting your destination. And then once you get into flip into, okay, now we’re gonna figure out how we’re going to get there. Right. But it’s so important to know where. Wanna end up right, because if the—the trip goes off, off course and you know you paddle in the wrong direction, there’s some —you can say, no, no, no, we’re headed to Venice. 

Natalie: I think that’s a great analogy, Gina. And, and it gets me thinking. So recently I was fortunate enough to go to Spain . And the impetus for that was I wanted to take my partner for his birthday to see his favorite band, the Cure and they were only playing in Europe. And so it was like, okay, well where are they playing on weeks we can travel?

Gina: Mm-hmm.

Natalie: Right? And then where’s a city we haven’t been to? 

Gina: Mm-hmm. 

Natalie: Or, or a country we haven’t been to before? Right. And that was how we picked it was the only time I’ve ever. Kind of taken that type of approach to travel of like, I, I wasn’t going to Spain to go to Spain. I was going there to see a concert. 

Gina: You had criteria, right? You had an end goal. 

Natalie: I had criteria, yes, exactly. And, but then we had to go, okay, once I’m there, what am I gonna do? Right? So then there’s that ongoing research. Even, even from a daily perspective, like we didn’t know anything about the city. We, we weren’t going there to visit family or something. It, you know, so it really was a daily of, okay. What museum are we gonna see tomorrow? Or what restaurant do we have to hit? Right. We here.

Gina: Let’s make the most… 

Natalie: [crosstalk] …Ongoing research. 

Chris: Yeah, exactly. 

Natalie: That ongoing research. So it is critical. It’s not just, we’re going to Spain and then you show up. I mean, you can do it that way and sometimes you get lucky and have a great trip and then you know, sometimes you end up in the worst restaurant in the city. Right? Because you do..

Gina: How is the concert? 

Natalie: Oh, it was amazing. 

Gina: Was it? Awesome. 

Natalie: The whole trip was just wonderful from start to finish. So..

Gina: That’s great. 

Natalie: So research, right? It helped. 

Gina: Right.

Natalie: We, we went in kind of knowing what we wanted to do and yeah. So..

Gina: Set the destination. 

Natalie: Good analogy with the, with the travel. I like that. 

Chris: Great. 

Natalie: The other key thing I think here is, we talked about this in a little bit, is understanding who are you solving these problems for? Right? And this is understanding your users. This is kind of the—the third. The third leg of the stool, if you will. This is where things like personas and journey maps and ethnographic studies and all of those types of things can come into play is who are we solving this for and are we solving it for the right—have we accounted for everyone? Right? And, and this is a—a huge piece of things as well, because you have to know. What problems am I solving for this person? ’cause solving a problem for one group of people may look very different than solving the same problem for a different group of people. 

Chris: It’s a great point. I think that’s a great place to close it to. And Natalie, thank you for coming on and talking through this. I feel like this is..

Natalie: Absolutely.

Chris: …A very down to earth, practical but important approach to research that hopefully resonates with people and, and I would encourage you. If you’re listening and you’re like, I, you know, this makes sense to me, but I just don’t know where to start. I don’t know how to run an effort like this. I don’t know how to talk to the people who are using my platform. Let us help you. We would love to do it. We’d love to talk to you about it. We’d love to hear what you’re up against and how we could get around it. 

Natalie: Absolutely. 

Chris: hello@postlight.com to reach out to us.

Chris: We have a whole team of designers who would love to do this work 

Gina: with you. We wanna make sure your refrigerator. For sure. 

Natalie: Exactly. 

Gina: All the way. 

Natalie: Exactly. 

Gina: Thank you so much, Natalie. This was so much fun. I really appreciate you sharing that story too. 

Natalie: Absolutely. Thank you so much for having me. 

Chris: Bye everyone.

Gina: Bye everyone.

[POSTLIGHT OUTRO MUSIC]