Getting everyone in the product development process on the same page requires radical transparency, empathy, and collaboration. In the Same Page event series, we’re getting practitioners and leaders together for open conversations on exploring what it takes to build those cross-functional team relationships and how to find alignment.

In this Same Page event, Netflix Lead Product Designer Global Conversion Fonz Morris joins Abstract Director of Product Design Sarah McIlwain to discuss user research. From lo-fi tactics like asking your colleagues to friends to test your designs to the more sophisticated research projects deployed by large teams like the one at Netflix — finding out what your user is thinking and experiencing helps you build better products.

Transcript

Sarah McIlwain: Everybody, thanks so much for joining us.

Fonz Morris: Hey, hey, hey. What's up?

Sarah McIlwain: Hey Fonz. How are you doing?

Fonz Morris: I'm good. I'm good. Glad to be here. Glad to be here.

Sarah McIlwain: Me too. I'm glad to be talking with you. Everybody, I'm Sarah McIlwain, I'm the director of design at Abstract. I'm super excited to be sitting here talking with Fonz Morris today. He's a lead product designer at Netflix, focused on global conversion. We're going to talk about research today. As we're getting rolling here, I would love to hear where people are dialing in from today. 

Fonz Morris: Yeah... in the chat.

Sarah McIlwain: Yeah.

Fonz Morris:I see Atlanta, Denver. Shout out to Atlanta, I went to college there. New York City. I'm from New York, South Korea, Allentown.

Sarah McIlwain: Very cool.

Fonz Morris: Brooklyn. Yes, yes.

Sarah McIlwain:international here. This is good stuff.

Fonz Morris: I love it. This is good. This is good. This is good.

Sarah McIlwain: Great. So folks, the goal here is to have these series of conversations, exploring a design first approach to product development. And obviously, Abstract super passionate about design. Hopefully you are too. So we're going to be talking about user research and how you build the foundations of good design. Research is that framework that we build on for the best design experience as possible. It's something I'm really, really passionate about having had the chance to work with some really amazing user researchers in my career. We want this to be a conversation. This is not just Fonz and I talking, we would love to hear from all of you.

Fonz Morris: Yes.

Sarah McIlwain: So drop your thoughts into the chat. You can use the Q&A feature if you have questions that you're hoping Fonz and I can answer. So yeah, be a part of this.

Fonz Morris:Yeah. This is definitely a multi-person conversation. Don't let us dominate the convo.

Sarah McIlwain: Absolutely. Fonz, do you want to talk a little bit about how you got to where you are and how you started working as a research ... How you got started with user research and how you come to realize that it's an important part of your process?

Fonz Morris: Sure. So I'm Fonz, I'm from Brooklyn. I am a product designer at Netflix. Before that, I was a growth product designer at Coursera. So I've always been in the growth space and that's because I started as a entrepreneur. And I think most people don't even know that as an entrepreneur you're automatically in the growth phase. So with that, I was at least smart enough to say, "If I'm building something for people, I should probably know what those people think." And I think that's where my user research came from. But when I was entrepreneur and doing a startup, I didn't have the same research budget or access to the same people.

Fonz Morris: So I would literally just ask everybody around me. I'm big on sharing my work, so I look at user research as being a huge gamut. It can either be super sophisticated the way we do it at Netflix, or it can be super low five where you ask your neighbors or you even just put some wireframes onto a platform like usertesting.com. But I think that it's hard for you to say you have empathy for your users if you don't talk to them. And I pride myself on being an empathetic designer. But it's funny as I've grown in my career, I valued research even more and more and more and more. And now I love going to quals, I love reading the reports from our research sessions that we have because I just really want to hear from the user.

Sarah McIlwain: Yeah, same. And that piece of building empathy for the user just, I think is so, so critical for a good product, ultimately. Even when you are innovating in your space and it's something that hasn't been done before, I still think understanding how folks interact with it, what their needs are, what the problems are that you're solving. And why do you feel like research is so important to product design?

Fonz Morris: Because you're not building a product for yourself. To all the designer that's on the call, I hope you realize that, that this is not for you. I don't design Netflix things for me. I design them for the millions of people that use them. So, I don't really see how you could be building an inclusive and global product if you're not including your users into it. So that's why I always try to figure out a way to do user research. Like I said, I'm lucky enough to understand that there's multiple layers to user research, so I use whatever I can at that moment. Sometimes I'm fortunate enough to have a multi-day global qual with Netflix users from all over the place. And sometimes I just had to try to put envision together and share with the only other people in my company to get feedback. But I'm always trying to hear from the people because I'm not really building the things that I build for me.

Sarah McIlwain: Yeah. I mean, we're so close to the things that we're building that even if you are a consumer of the thing, like at Abstract, we're designers designing for designers. And it's really easy to think, okay, I'm designing this for me, but with the product and we know it so well that we are absolutely not these. We are not the first time customer. We're not the person who's been using it for six months. So, that mission of you're solving someone else's problems and not your own problems, I think is the biggest piece there. Yeah.

Fonz Morris: Right. Plus I like to put myself in the user's shoes. So by doing that, when you think of a company like Netflix that has so many different users from so many cultures, so many places, and so many different scenarios of whether you're talking about internet or English is not their first language, so you really have to put yourself in their shoes because if not, you will build a one-sided project. And I think that's what has allowed Netflix to be so successful, is it feels so easy and usable by everybody on planet earth. And I want to keep it that way.

Sarah McIlwain: And that's not an accident, obviously.

Fonz Morris: No, no, no. The simplicity is something we strive for because when you start doing quals once again, since this call is about research, I'm not saying about research till the cows come home. When you start doing these quals, you start seeing people don't use Netflix the same way you may. They don't understand it the same way you do. They have their own styles. There's hundreds, there's thousands of different cell phones that people use Netflix on. Some people are on PS4, some people on the TV. So, it's just so many different ways to use the platform that simplicity has been key for us because the minute you add even a slight layer of complexity for a company like Netflix, that can result in millions and millions of dollars of people calling in and want to talk to customer service, or they're talking about us online, about this is too complicated. So simplicity is key for us.

Sarah McIlwain: Absolutely. Yeah. One of things I'm always curious to hear from other folks, other designers, is how you make time for research in a fast paced environment. So, most of us working in the tech space already used to having to hit those timelines, you don't want to block engineering, you got to get this thing out the door. I think for us, we're moving towards a sprint process in our own, internally. And so really starting to think about how can we set up research in a timely and quick way so that we're doing it consistently, but that we're not pausing projects to do that research. So how do you, Fonz, make sure that you're getting that research in when things are moving quickly?

Fonz Morris: I mean, I have to be honest, every project doesn't get to get the research that I would want from it, right? So at Netflix, we have something that's like a just do. Just dos don't get user research. Just dos maybe something that we've decided as a team, we need to fix this. So, let's go ahead and fix that. But when you start thinking of the bigger size projects, when you think of a project that we know is a massive problem, that the scope is huge and we have a lot of time, we're definitely going to do a blowout research situation. If we have a faster or shorter timeframe, now we got to decide, what does that research look like? Who do we really want to get feedback from? Do we need internal feedback? Is that enough research? Do we need external feedback? What is the problem really attached to, to where? Who do we need to talk to, to really hear from?

Fonz Morris: Can we get that information internally from the design team, internally from the company, or do we have to go outside of Netflix? And when we go outside of Netflix, then it gets a little bit tricky. So, I always try to ask the timeframe early, as soon as I find out about it and then ask, "Do we have time for research?" And if we don't have time for research, then I always say, "Well, how are we going to validate that this is the right solution if we're not going to talk to anybody?" Let's go ahead and talk about that now.

Sarah McIlwain: Yeah, exactly. What are we going to be looking for? I mean, one thing we talk about is, all right, if we're not going to user test this, what are we going to be looking for with this launches to know whether we made the right qual or the wrong qual? Talk about that one way doors, right? And you don't, if you are trying to think about a one way door, if you're going to build something that there's no coming back from or no changing, then you need that user research upfront before you share them. But if it's something you can iterate on and build on and change as you go on, and then maybe what you need to do is establish what those metrics are that you'd be looking for once it gets out there in the real world. Yeah. I hear you about, yeah, asking the timeline first and then figuring out.

Fonz Morris: But also I'll add that Netflix, we have long range projects. I just launched a project that was three years in the making. I'm just starting a new project that's probably going to be running for two, three, four years because we can't make quick changes with anything. I mean, you'd be surprised you move a button from the right side to the left side of the page and people don't convert. And then the PMs can actually, with data size, can do the numbers to tell you, "This test experiment, we lost $19 million on this because people dropped off of the experience because they couldn't find a button."

Fonz Morris: So because of that, we end up usually making gigantic strategy bets early. And then with those strategy bets, we'll do the research for that, and then that research will carry us through the rest of the project because we can always go back to it and say, "Well, if you're about to make this edit, Sarah, don't forget in quals, they said this." Or if you're about to do this font, do you have anything from qual to back that up? So, we'll do massive research early, and because it's so broad and massive, it allows us to use that information for smaller projects that's still under the same umbrella, if that makes sense.

Sarah McIlwain: That makes a ton of sense. That's actually very cool and that's a great way of thinking about it. Setting yourselves up for success in the long-term by having is deep enough and extensive enough that you can continue to draw from it. Do you get to work with a research team for that?

Fonz Morris: Oh, yeah. That's the thing about working at a company like Netflix. And I don't want to keep saying that word. I want to say shout out to all of the tech companies all across the world because I think they're all fantastic, whether it's startup to blue chip. But one of the benefits at working at some of these bigger companies is the resources. Let's just be honest. The resources are very, very plentiful at Netflix. So I get to work closely with two researchers actually. And I actually get to go to the quals and sit in the quals. I did a qual in, what's this? This is May, in March. I did a six day qual, where we had to talk to users from Argentina, we had to talk to users from the United States, from Ireland, from Thailand, from France, Italy. So by being able to have that access, it just changed my whole view and perspective on the project. So I get to work very closely with research. I'm really lucky.

Sarah McIlwain: Yeah, yeah. And I saw a question in here. It's a great one, about how many folks do get to work with researchers? How many folks are researchers? How many folks have to sit in that hybrid role? We'd love to hear in the chat, folks, from you, how many of you get to work with a research team? How many of you do the research yourself? You sit in that hybrid role.

Fonz Morris: Oh.

Sarah McIlwain: Yeah.

Fonz Morris: Excuse me, Sarah. I'm sorry. Good thing I'm reading the chat. I'm sorry everybody. So quals are short for qualitative research. I'm sorry. I'm already in my designer and WeChat. And so quals is just a shorter way of saying qualitative research, because if you say that every single time, you get tired. So anytime I say quals, that's what I'm talking about.

Sarah McIlwain: Get rid of some of those extra syllables.

Fonz Morris: Yeah. You know lazy.

Sarah McIlwain: So we've got a couple of polls I'd love to run. One, I'm going to go ahead and publish this one here and y'all are going to have to forgive me because this is a new platform. GoCast is super slick.

Fonz Morris: Yeah, it is.

Sarah McIlwain: So, I'm going to publish on this poll. What I would love to hear is what type of research does your team do most often? So do you do moderated usability testing, unmoderated usability testing, user interviews, ethnographic like field studies, surveys. I would say for my team, we do a split, I think between user interviews and moderated usability testing. And then we're starting to do surveys more often as well. What about you, Fonz?

Fonz Morris: You took the words right out of my mouth. That's exactly what I was going to say.

Sarah McIlwain: Yeah, yeah.

Fonz Morris: We do the moderated usability testing, which is a hybrid of the user interviews and the moderated usability testing. For instance, for one qual that we did, it was just straight user interviews. But then for another one that we just recently did, it was using prototypes of what they would actually be using if we launched this test. So they were able to interact with what the experience could possibly feel like. And then we also do send surveys periodically to people just to get random feedback. But the surveys are not as, we don't lean on the surveys as much as we do the user interviews and the moderated usability testing.

Sarah McIlwain: Exactly. Do you find, it depends on the stage of the project, the type of research that you're choosing for a given situation? I know for us, we do the user interviews. A lot of times this happened when we're thinking about building a feature, we're trying to understand the problem space ahead of time, versus usability testing, obviously that's midway through the project that we're on the right track. And then surveys would happen maybe once it's launched or it's in beta, things like that. You find that to be true for you as well?

Fonz Morris: Yes, yes. That's pretty close. I would say that the user interviews happen for us when we're even trying to decide, are we going to do this? Even before we have even ... So what we'll do is we'll come up with this idea as a team, right? It's like plan X. But before we really want to move on plan X, we prefer to talk about plan X to our customers. And then based off the results of that qual, either we'll keep going or we'll switch. We recently just had a qual where, I don't want to say it went bad, but the feedback from the users was so different than what we were trying to hear, that it completely spiraled and changed the whole project. I don't want to say it blew it up, but it just changed everything. So I'm glad we had that though, because if we would've went through the motions and got to the moderated usability testing, oh, they would've destroyed us.

Sarah McIlwain: That is so smart. I mean, that is such a ... I hope everyone in the room gets to experience that at some point in your career because that is the moment where you're like, "This is why we do user research." This right there, getting blind started, that's what-

Fonz Morris: That's exactly why the whole time I was sitting in the quals, listening like, "Man, they are not feeling this idea at all. I am so glad we did not roll this out. Oh, wow." So that's why research is so important because you can't make all the decisions for people all the time. You can try. It's just better when you include them.

Sarah McIlwain: That's exactly right. And none of us has a crystal ball as far as I'm aware. And you just don't know until you actually get the idea in front of us. And yeah, like you said, thank God that you had done that before you went all the way to usability testing, because at that point you've built prototype, that you've written script and it would have been wasted effort. And then God forbid, you had actually launched the thing. You know what I mean there?

Fonz Morris: Right, right.

Sarah McIlwain: All engineering hours that went into that.

Fonz Morris: Yeah. No, research is your friend. And that's why when you reached out to have me on the show to talk about research, I'm passionate about research and I'm not a researcher, I'm a product designer, but I know how to research and I really love research. But I really just, honestly, I understand the value of it. And when you really understand the value of research, it just helps you become just a better product designer.

Sarah McIlwain: That's so true. That's so true. I mean, and hopefully this call today, this conversation is helping a little bit with that. There is some really good questions in the chat. We've got one here from Min, I'm going to publish. I think this is a great one. So good. What would be a good approach or framework, or even a tool for research for a small team that doesn't have enough resources or time? I hear so many times in my career. What do you think, Fonz? I mean.

Fonz Morris: I mean, I've been there most of my career. I just got out of that phase. Really, I think it's about understanding what you want to learn. And that varies throughout where you are in a process as well, because do you want to talk to somebody to just find out if this is a good idea or not? Are you past that phase as a team where you believe in an idea, but you don't want to go too far into developing, so you want to do wireframes and then you want to have the wireframes tested? Really what I'm trying to say is it depends on what information you really want. And based off of that, you'll use different things to get that. You wouldn't use usertesting.com to validate your idea because you need designs of some sort to put on usertesting.com.

Fonz Morris: So in the earlier part of, if you're trying to validate an idea, you would probably do user interviews. And that can be very simple. That's just more of, we're just saying, don't only let the people that's in your team make the decisions. You don't have to have 1,000 people as your interview database. You can have five, you can have 10. And I'm sure each of you may know two people. So it's also about being resourceful, I would say, Sarah. How about you?

Sarah McIlwain: Yeah, being scrappy. One thing I used to do when I was at Amazon Videos, I used to actually bribe people outside of our department with a pizza lunch. And I would load up a bunch of tablets and phones with a prototype, and just publish a notice saying, "Hey, you come to this conference room at 12:00 PM, we'll have six pizzas." And you send it to folks who are outside of your department. So if you have, like the legal team or, that's the furthest removed from your own department, that's a really good option. The other thing that I found to be incredibly valuable is to talk to your customer service team if you have one, right?

Fonz Morris: Wow.

Sarah McIlwain: Yeah, because -

Fonz Morris: Touching.

Sarah McIlwain: They are a wealth of resources. Those customer problems are, I mean, they are like a goldmine. So though sit down with your customer service team, ask them, what are the things that come up the most? What are the biggest customer complaints? Do they have a repository? Do they have Zendesk or something where they're storing all of this stuff in there and look at that? Sit in on calls with them. When I worked for health insurance, we used to do, at least once a quarter, you go and you just do a ride along on a customer service call.

Sarah McIlwain: I have a good friend who, Scott, who worked at Comcast for a long time and they would actually get in the track, the install track, and ride along install appointments. And so any way that you can integrate with those teams that are customer facing. I think also your account team is a great one. So our account team here at Abstract, they just have so much knowledge about the customer space. So there's all kinds of ways you can get to understand the customer problem even if you don't have the resources for a proper user researcher.

Fonz Morris:Yeah, for sure. I would say use the slide that you showed before, I mean, where the poll of the different styles or things, you can use those. Just scale them to what needs for you because I know that they said they were looking for a framework. Take this and then scale it to however you need. If you're just trying to get some quick feedback, you may need to do a survey.

Sarah McIlwain: Yeah.

Fonz Morris: So, you just have the framework.

Sarah McIlwain:  That's exactly right. And there are great resources out there. Jared Spool, Nelson Hungria, all of these folks have articles on their websites about how to figure out the level of research to do at a particular stage in your process. So just, yeah, be scrappy.

Fonz Morris: Jared Spool is great. I want to put his name in the chat in case some of us don't know who we're talking about. And actually it's not two Es, it's one E.

Sarah McIlwain: Yeah.

Fonz Morris: There you go. Yeah. Please follow him on Twitter. He has fantastic user research insights and he's been in the industry for so long. He has a lot of good insights.

Sarah McIlwain: He's got some great stuff. I would love to do one more poll here about, specifically usability studies. This is one that I'm always curious about. What do you folks test with the most usability study? So do you do paper prototypes, do you like clickable wireframes like Axure? Do you go to the trouble of building out a hi-fidelity prototype with interactions? Do you actually go down the whole framework path, or do you just use early builds? So when I worked in mobile in healthcare, we would actually, a lot of times just use a full ... we would get the engineering team to do an early build and use that for a test. Testing on mobile, you really have to have those interactions. I would love to hear what most folks are doing their usability tests with. Looks like we've got a lot of folks who are doing those Figma prototypes, prototypes. And-

Fonz Morris: But I don't see any code-based prototype. If I was on there, I would have had to select code-based prototype. Well, what do you test with most? Yeah. See, that's tricky. I would have to say 50-50. Internally, it's Figma. Externally, Figma doesn't work for us, especially when you think of, if you build a really, really robust prototype, sometimes it lags and it's not the same as the actual build. So when we're doing external user research where we're talking to actual customers in Florida or in Japan, we're going to use a code build.

Sarah McIlwain: Yeah. Yeah. That's a really good point. And there's a really good question in the chat that I want to get to, related to this, which is the difference between hi-fidelity and robust prototypes. Question from Art. Yeah. So I think what I'm thinking of, hi-fidelity is the design itself is hi-fidelity. So you've got the full UI in there, but you're literally just, you have, it's just hotspots links together in Figma. And then robust prototypes, I think of those as having the actual animated interactions like the, you've got the transitions, you've got multiple hotspots on the screen. Maybe you've even got the ability to select UI elements and interact with UI elements. That's a great question.

Fonz Morris: Yeah. I would agree too. The robust, I would just say it's way more advanced. I think somebody in the chat also, Weston, made a great point that I think the prototype matters for what kind of question you're trying to solve. If you're trying to figure out information architecture, you don't need a hi-fidelity prototype to do that. If you're trying to get a sign off from the company on the visual design, then you're going to need hi-fidelity, because they're going to want to see how it all works. Not just boxes on a screen.

Fonz Morris: So I think it depends, but the robust is usually more for you're happy with the design, you're happy with the UX. You're trying to figure about the interaction and you need to try to touch it before you give the engineering, and they spend the time building it because once they build it, now it's build obviously. But then that money has been spent if there's changes. So you want to do the robust if you think this is going to be a heavy engineering and you still need to test it just to make sure before you push the button on engineering.

Sarah McIlwain: That's exactly right. And actually you got a great question in here from, I'm hoping I'm pronouncing your name right, Jaka from Slovenia, has a great question here. Finding a good balance as to how far to go with research. Yeah, I find myself and my team struggling with this one as well. Fonz, do you have any thoughts on this?

Fonz Morris: I don't really think you can go too far with research. I think you should always be learning, but you should have that first question or questions that you're trying to get answered. And then many if you get those questions answered, you can stop. Now, if you want to have multiple answers to those questions, that's up to you and your team, you can keep going. But I'm a very simple designer. I don't ever want to do too much work just for the sake of doing it. So I'm very focused on once I get started with something, okay, what questions do I have and how do I get those answers? And the minute I get those answers, I take a second and say, "Is this enough?" And if it is, then I'm moving on. If it's not, then let me do more. But I'm always very methodical about how much time I'm spending on something because I usually have a lot of things going on and I don't want to put unnecessary time into something, if I could have just got this information and been done with it.

Sarah McIlwain: That's exactly right. Yeah. And I think you hit on a great point there, which is knowing what the questions are that you want to answer upfront. And actually, I find that if you could just put together a doc that starts with what is the goal of this research project, what are the questions that we want to answer and who do we want to get answers from? And you just start there and you list out those questions. And then the research writes itself from there. So how do we ask questions to get at that research? Or how do we ask questions to get at the answers and putting those up front, and then also knowing the timeline of the project that you're working on.

Sarah McIlwain:I think the combination of knowing how quickly you need to get this over to your engineering team. What questions you specifically have that will help you figure out what the right level of research is. But again, one idea, one way door versus something you can iterate on. So if you're making a decision that's irreversible, you probably want to err on the side of putting a little bit more, or if you are working for Netflix and you've got millions of dollars, right?

Fonz Morris: But as a smaller company, as well though, I think you should have your expectations set up early where you say, "Okay, we're going to do research, let's interview four people." And once we do that four, we'll go over this and see, is this enough information? Do we do another four? But I think sometimes as a smaller company, you're very ambitious. So you may come up again and say, "Well, we're going to interview 20 people." And it's like, well, why'd you pick 20? That was a random number. It sounds good, but did you need 20? Because if you got 20, you could have probably did it with 10. And if you had 10, you might've been able to even do it with five. So you really need to spend that time at the beginning to really ask yourself how much feedback do I need to really be happy with whatever answer I'll come up with?

Sarah McIlwain: Yeah. And that's, again, we're putting together that just, you just do it a quick one pager, whatever your favorite editing tool is, just put together a quick one pager and outline those things. And actually that, it's a good segue to another question from Ermin, which is, for someone not familiar with a more structured research practice, what's the best way to start? You talk to the users but you feel like you're lacking in documenting the research. I mean, this is, just like we're talking about, having that one pager, what are the goals? And then as you get answers to those questions, you're putting those in that one page document. One thing we do is, you record the calls that you have and then you link to the transcripts from those calls. Right?

Fonz Morris: Yeah.

Sarah McIlwain: And look up an answer later on, you can just do a quick text search from what that was. And then at the end of the research, one thing I really like to do is just put together a quick deck. You just use Google slides or whatever, and share that deck with the company when it's done. And just say, "This is what we learned," because the more you can get that research out in front of ... Ours is a small company, so I can share that the whole company. For someone who's at a bigger company, maybe it's just sharing it with the teams that you work closely with. But sharing that research externally outside of just the design team, I think is a really important piece of it. What do you think, Fonz?

Fonz Morris: No, I agree with most of the things that you said, as well as, what I found that was really important is when you're in the research sessions, to have somebody taking notes, so that in case somebody missed something or somebody wants to read it afterwards, you can do the transcribe as well. But the notes is a little more organized and it's really focused and stuff like that. So as far as I would say, what's the best way to start, it's of course, do the research, do the one pager, like Sarah said. Take the notes, have the questions lined out, frame the way you want to ask these questions, frame the users into some type of bucket where it's like, well, this is user one, this is user two, this is user three. We're going to ask them these questions.

Fonz Morris: And then at the end of the research, you definitely need to put a synopsis together. And that synopsis should either explain why the user research now supports the hypothesis that you were trying to solve or why the user research does it. And now because it does or it doesn't, that should help you figure out, "Well, because of this, now these are the next steps that we're going to do." So it starts to become a path for you to get to where you want to go, as opposed to you just saying, "I love this idea, design, engineering, building."

Sarah McIlwain: Exactly. And I love that piece that you talked about the note takers and the marking the participants. One thing we used to do back in the olden days when we were all in the office together, my last team, shout out to Robert and Christie on this one, for coming up with just a really, really cool debrief methodology. Basically we would have, each note taker had a post-it pad and you would write observations. Not necessarily what the person said, but maybe what the person did. And each person is doing those little post-its and you're putting those post-its up on a whiteboard as you're debriefing together. And getting that shared perspective of multiple folks sitting in. And observing that call was also really, really huge, right?

Fonz Morris: A debrief is huge. The debrief is huge as well. That's something that I can do right afterwards and everybody give their opinion. And either you can take more notes from that, or you can just hear what other people got from it because everybody hears things differently, but you also want to hear what your teammates think about the qual, because maybe there were parts where you were confused or something of that nature. And then at the end result, just so we really make sure that we answered their question is, do that final synopsis at the end. So do the one pager at the beginning that explains why you're even doing this and then have the notes from the actual research, along with the questions that you're going to ask, and some user personas around who the people you're picking, and then at the end of it, have the synopsis so you can share that out with the team, whether they're design or anybody, because that information is probably useful to everybody in the company, not just the product team.

Sarah McIlwain: Yeah. No, that's really true. I mean, sharing that research around, at the end of the project is so, so critical. Is there a way that you like to share a user research across your organization, Fonz, I mean?

Fonz Morris: Our researchers are just phenomenal. So what they did was they made the notes available for anybody that want to read it because we use Google Docs for everything. So even if you weren't a part of the qual, you can still jump in and read the notes, but they just put together a phenomenal debrief document at the end where they broke down. They also even recorded the sessions. And then they took clips out of certain parts and they stitch them together and made this bigger presentation that had the clips associated to the different parts where we said, "Well, we don't think this is a good idea and here's why. People did like this idea, here's why." So, it felt like a way for everybody who wasn't necessarily involved in it, who couldn't attend, they still felt like they got the necessary information from it. So putting that document together with the mindset of, I'm trying to get this information for my teammates that wasn't able to attend, I think is a good process.

Sarah McIlwain: Yeah. And those video clips too. When you get some customers actually like our ticket saying the problem out loud, when you play, it's amazing the impact of just hearing it in a customer's own words, so powerful. I mean that's, there's a tip for you right there. It's like the more that you can either pull verbatim quotes from your research and you're just printing it in your report or actually pulling those video clips and sharing them with people, man, that's powerful. I mean-

Fonz Morris: One guy did an analogy in one of our quals and he'd rock the whole team. The analogy was so right on the money. We all just, even though we wasn't together, you could almost feel like we all looked at each other like, "Oh, that was good." And that's what we use. That's what the researcher use for the next four or five meetings to explain to people who couldn't really understand what the feedback was. Once we gave that analogy that we got from the customer, it just put it in a whole different perspective and they was like, "I get it." And he makes a lot of sense with it as well. So that really helped us.

Sarah McIlwain: That's amazing. That's so cool. Julia has got a great question in here about speaking to the customer and speaking of what you hear from them. How do you balance what the customer is asking you for versus the level of efforts from design and development? Customers are asking for the moon and asking for all these features, but obviously there's always budgets. There's always time constraints. How do you deal with this one?

Fonz Morris: I mean, you always want to design what the customer wants, right? And you should have the customer's best interests when you're designing, but there are a lot of other things that come into play, which is design, how much is it going to take to design that? Is that two way off of a design for what we need? Does it make sense to do that? I think ultimately, it's about priorities and what you really need to able to make the business successful at the same time. So there's different levels to this. I don't think there's one exact answer because for some situations you will literally be able to take what the user said and then design it and then development builds it. Sometimes it'll be the user will say this, design is like, "I don't even really like that idea," and development is like, "Even if we did that idea, it wouldn't be smart to build that."

Fonz Morris: So I think it varies most of the time, but it is definitely balanced. And I would say one word that I like to use, it's just compromised. I feel like compromise is a good word because it means everybody tried to get what they could, but they were willing to give up some, to meet somewhere in the middle. And I think that's what we end up doing a lot at Netflix. I'm working on a project right now where the design I sent the engineering, they stripped it down so bad. I was like, "This doesn't even look like my design anymore." But I understood why they said that, but I had to push back and say, "I added this to the design because I think the user needed that." So now we're in the middle of trying to find that perfect harmony of, well, where was I being maybe extra creative where I could find a smaller solution, but where is engineering not pushing the bar of what we could build and things like that.

Sarah McIlwain: Yeah. That trade off, that negotiation. And again, that's actually where user research is so valuable, right? You can go back to that research and say, "Look, this is the must have. This is the piece of this got to have in here." I think the other thing that can help, Julia, to help answer your question is trying to get at the pro ... one that the customer wants to solve. So a lot of times, I mean, everybody's heard this and they're sick to death of it, but I'm sure, but you ask the customer what they want, they're going to tell you a faster horse, when actually what they want is a car, right?

Sarah McIlwain: And so if you hear the customer asking you for something, really try in your research to get at what the heart of the problem is. So rather than asking them what they would like to see, ask them what are the challenges you're facing? What are the problems you're trying to solve? And then I think a lot of times you can find ways of solving that problem without necessarily delivering the moon. And maybe it's not a rock. Maybe it's a meteor or somewhere in between.

Fonz Morris:  Or maybe it is a rock. It's just a really pretty, shiny, smooth rock that has a lot of purposes. But I think it's about being simple as well though. And I think that was something that I was nervous about when I started at Netflix, was like, "Everybody's so smart. I need to come up with the most complex ideas I've ever had in my whole design career. I need to be performing at the ultimate level." And to be honest with you, a lot of my projects, even though I came at them that way, the end result ended up being a way more simpler and slim down solution that still work. And that's the thing, is being able to understand when can you sacrifice some things but still be successful?

Sarah McIlwain: I mean, sometimes the best designers are the ones that are absolutely dead simple, right?

Fonz Morris: Google Search. We all know that google.com is the best web design in the history of the web. And I will argue anybody.

Sarah McIlwain: 100%.

Fonz Morris: They never changed it. They never changed it.

Sarah McIlwain: Yeah, and there's a reason. Yeah. And there's a reason-

Fonz Morris:  And the company is like a trillion dollar company, that's never changed their website. You got smaller companies, Sarah, that have changed their website hundreds of times. Then you have a mega monolith like Google who's like, "Let me just keep that search bar right in the middle and we're good."

Sarah McIlwain: I want to take us to the very last segment in our conversation today. So we've been talking a lot about the foundations of a good project. We've been talking a lot about creating documents, to play on your research. And I think a lot of us have all the stuff in our heads at the start of a project, and getting them down on paper can often be the best way to explore ideas. So I think a lot of us, myself included, have scratch pads, notebooks, sketchbooks that we use to explore these ideas. I brought mine actually today. 

Fonz Morris: Oh, wow.

Sarah McIlwain: We got some examples up on the screen too. So I've got mine that has my notes and then notes-

Fonz Morris: That looks good.

Sarah McIlwain: That my kid did. And then yeah, up here on the screen, we've got these great examples from some folks that, so cool.

Fonz Morris: My scratch pad don't look that good.

Sarah McIlwain: And I'm curious, it sounds like a lot of you have journals that you keep as well. We think it's such an important part of the creative process that we're looking at this process pages project. So we've got this project we're starting at. We want to see your process and its reface. We want to see this early stage work. We want to see your ideas and your thoughts. So we would love to give away 75 process pages journals. Our producer's going to put a link-

Fonz Morris: Give aways?

Sarah McIlwain: Chat. Yeah.

Fonz Morris: We got give aways?

Sarah McIlwain: We got stuff. So Kelsey has put a link in the chat for some of these freely. These are wicked cool. These journals that our brand designers put together. We've got 75 of them. So claim one, record your process and then share the results with us. We're going to put together ezine when we get a bunch of these -

Fonz Morris: Oh, that's cool.

Sarah McIlwain: A zine.

Fonz Morris: That's cool.

Sarah McIlwain: So if you submit it to us, we'll send you more information via email about how to participate in process. We'll also put some of this stuff up on Abstract's Twitter, but we're going to run all summer and we're looking forward to seeing what y'all do.

Fonz Morris: No, I love that idea. So what I'll say is I'm not the biggest sketcher, but I'm a write in the notebook guy. I can go back to notebooks that I have from 2000. And the wildest thing is I use the exact same style notebook and I use the exact same style pen. I don't deviate from notebook, I don't deviate from pen. So I just have a bunch of mock ins from 20 years ago. But the beauty of it is when you look at them and you see what you were thinking about or what you were working on back then, and it's like, "Wow, I remember that."

Sarah McIlwain: I love it. Yeah.

Fonz Morris: I remember that.

Sarah McIlwain: I'm with you. I use the Leuchtturm notebooks and I have the same pen that I've been buying for how many years now, but we want to see this from all of you. We are just about out of time. Fonz, thank you so much. This has been an amazing call.

Fonz Morris: This was so fast. These things go so fast. Before you do it you're like, "How am I going to stay for an hour? I hope I don't mess up. I don't trip." And then when you get on there, you're like, "It's time to go already. I'm not finished though."

Sarah McIlwain: I can keep talking research.

Fonz Morris: I see your dog came in.

Sarah McIlwain: He hears me wrap it up and he's like, "Okay, yeah.

Fonz Morris: This is great. This was fantastic.

Sarah McIlwain: Thank you so much. Our next session y'all, is on May 20th. Abstract CEO, Kelly Watkins, is going to talk with Mia Blume. I am a huge, yes. They're going to talk about building on outcomes and I'm personally super excited to hear the two of them together in one conversations. So, I hope that you will all join us.

Fonz Morris: I will be there.

Sarah McIlwain: Thank you, Fonz.

Fonz Morris: Yeah, I'll be there.

Sarah McIlwain: Thank you Kelsey and Sarah for helping behind the scenes. And thank you folks for joining us.

Fonz Morris: Yes, it's great kickoff. Thank you, Sarah.

Sarah McIlwain: Bye.