Get in touch
Episode 158 March 12, 2019 | 33min

Letting Design Function: Product Designers Talk Relay

Postlight's Directors of Product Design dive into what Relay is and how it works.

Show Notes

Good design doesn’t have to be complex: Like many, Rich feels like an outsider when it comes to design. To non-designers, the field can seem confusing, even intimidating. But it doesn’t have to be. At Postlight, design drives the process, and in this episode we break down that process. Paul and Rich are joined by Postlight’s directors of product design, Skyler Balbus and Matt Quintanilla, who lead Relay, the Postlight design sprint. What is a design sprint? What makes good design? What role should it play in product development? And what makes a great product designer? The team answers these questions and more.

Rich Ziade Quick, Paul, who likes sun dried tomatoes? [Crosstalk

Matt Quintanilla Eh. 

Paul Ford They’re fine. They’re good. 

RZ [Crosstalks] They’re awful. It’s like—

MQ Tomatoes are the devil’s fruit. 

PF They’re nice and squeezy in—in your mouth. 

RZ They’re tart—they’re like sharp and you put ‘em in a sandwich, it’s like that—

PF I don’t understand the problem here. This is not what this is about [music plays for 18 seconds, ramps down]. 

RZ We have—and I just looked at—Skyler Balbus, the Director of Design at Postlight, and Matt Quintanilla who is the Head of Design and Partner at Postlight. Welcome, guys, to Track Changes.

Skyler Balbus Thanks! 

MQ Thank you for having us. 

RZ It’s great to have you and they [music fades out] came all the way from their desks, Paul [laughs]. 

PF About two and half feet away. 

RZ [Laughs] Um—

PF Do you ever hear us through the glass? 

SB Occasionally. 

PF All the time. 

SB Yeah. 

RZ We have a lot to talk about. 

PF Yeah, we do. 

RZ But I wanna just, you know, I—I like being the outsider here. Design, historically has been like something that’s beautiful and something that, you know, evokes emotion and, what I’ve learned, over the years, and that comes from sort of the classic product management end of it, mostly in technology, is that design actually serves a hugely defining function in what product is and what—and how it can be meaningful and useful and effective. Which, you know, the FedEx logo is, you know, iconic and recognizable and you know which truck it is, so there is some function there but design, for me, has just grown into this dominant part of product development, right into engineering, and that’s, you know, I wanna jump to what we call designers at Postlight, we call ‘em product designers. And I want you guys to talk a little bit about that distinction and what it represents. 

[1:52]

MQ The reason why we—we landed on product design is that it really needed to encompass more than what you think of when you think of just design when—particularly when we’re talking to clients who have—may have limited or experience in working with designers or have their own ideas as to what, you know, what good design is. We really needed to expand that definition out to include beyond just what it looks like and how it works to actually how it connects to the larger vision of the product, of how it works with the business strategy; how it touches users; but also needs to be able to connect to [yeah] a larger meaning and a larger, uh, you know, effort from—from a business. 

RZ Yeah, now design drives, to a large extent, it’s almost a key sort of propellent in the beginning of the process which is, to me, I mean, it’s new! That’s not—that’s not something that’s been the case for a very long time. 

SB I mean I think a lot of the work that we do now is essentially project or product management with pictures. It’s being able to define [mm] a product visually and experientially and put that out into the world, bypassing a lot of the conversational time that it takes to get there. It allows us to—to see things that are real and move things forward more quickly. 

MQ And, I think, you look at what’s on runways and fashion design, you say like, “Who would ever wear that?” Like, “What’s going on here?” Like, “It’s completely not practical,” but when you talk about textile designers and people who are actually constructing clothes that people wear, they’re taking those influences from fashion design and saying, “Ok, how do we make this usable for people? How do we put this to where they live?” And—and to me that’s—that’s kind of the distinction between product design and design for me. Like, design is a toolbox of color, type, emotion, you know, all the things that you would learn in school or—or pick up a design book and read but how do you apply that? How do you put that together with a vision? How do you make that for people? That’s really the—the sort of leap that you have to take when it comes to product design. 

[3:53]

RZ So, Paul? 

PF Yeah. 

RZ In the past we’ve talked about and we kinda like show it off cuz Postlight’s awesome—that a lot of people come to us and they don’t know exactly what to do just yet. They have—they have a broader idea and vision, they’re not—like they’re not coming to us with the blueprint. 

PF No, they—sometimes they come with a budget and a broad goal; sometimes the goals are like: “I need more revenue,”; sometimes it’s, “We have to just fix the big mess that we made over the last ten years,” [right]; and sometimes it’s, “I have a new product. It’s around, you know, insurance.” 

RZ Sometimes you have a great idea. We’re just—we just, you know, ended a phase with a client who just was so energetic about an idea and a vision. That’s about all she had. She had like 40 minutes of monologue. 

PF Well they have a sense! The client has a sense [yeah] that there’s this gap, right? And they gotta fill it somehow. What are the tools? Now, I think, traditionally people—a lot of times when they think about tech and platforms, they just think, “I need engineers; I need programmers.” 

RZ The builders. 


PF Yeah. “Let’s go get some builders and then we’ll figure it out from there,” and that’s not actually how we work here. We lead with the—we lead with design. Product managers run the engagements and designers drive them. 

RZ Here’s the thing about this: you could spin and do the whiteboards like for a really long time and—and a lot of times a lot of it is just gettin’ people to calm down, like, “I know you have a lot of great ideas here and they’re all awesome and some are in outer space but just chill for a second.” And hate—I don’t hate process but, you know, you don’t wanna throw process at that kind of energy and enthusiasm but you do wanna kinda ground it and give it like a path, like a track to go down. So, there’s this thing, Paul, and I learned about this like less than a year ago, called Google Design Sprints. Do you know what this is? 

PF I do, I’ve been part of some. 

RZ Ok. I’ve only been part of one. And they’re interesting because they try to kind of put that sort of—

PF I mean, first of all, there’s a book about them. 

[5:48]

RZ There’s a book. And it’s pretty good and it’s interesting. 

PF So, can one of you explain what a Google Design Sprint is? 

MQ A Google Design Sprint is a method that was sort of developed by Google ventures to really put time around a space; to get the people in the room to really work through a, sort of, feature set or idea or—or sort of things that need to be validated out in the world with the people who have the idea. So, getting everybody in the room sort of laptops closed, whiteboard, you know, markers out to really define what it is we’re doing; what are the jobs to be done; how do we put people in a sort of workflow that makes sense; and how do we then test that out? 

PF So I wanna make an app that lets grandfathers get ha—hats that they pick online, in the mail. 

RZ So is this, yeah, so like that idea comes into the picture is this—is this a meeting? Like, what—

MQ So the way that the Google Design Sprint is—is usually structured, and there’s a couple variations here and there, but it’s five days. And it’s very much let’s get everybody in the room; let’s clear our schedules; no cell phones; we’re gonna bring in lunch; and we’re gonna work through a pretty regimented path of how we’re thinking about solving this [mm] problem. It is not overly prescriptive but it very much has a method and a way of thinking about things. 

RZ Trying to put some boundaries and, really, guardrails around this. 

MQ Absolutely. And getting everybody in the room to be a designer; to put on a design hat [yeah] and really, you know, take all the pieces of design thinking and process and apply it to a business problem. 

RZ So, not just the designers are being asked to think that way, like you’ve got the business owners, and—and whatnot. Just throw this out there: are they in the room—that group, everyday, for the five days? 

MQ That’s the expectation. 

PF And they’re kind of a grind, to be honest. 

RZ Let’s talk about the panini on like Wednesday. With that same group. You’ve been in that—with that group for two and a half days now, they order that luncheon. You know those wraps? And they say, “Oh that’s a spinach tortilla thing.” [Matt chuckles] Is that what it is? 

[7:57]

SB The—the Google Ventures book actually has recommendations on the lunch that you should have. 


RZ You’re kidding! 

SB No, I’m not! 

PF Oh yeah, yeah. No. 

SB And it’s important. Like you need to have high—high energy, high protein snacks—

RZ No mashed potatoes [laughs]. 

SB No chicken parm sandwiches, no mashed potatoes. So like [that is amazing] whatever panini you’re envisioning in your mind, like let’s make sure that it’s Google Ventures panini. 

RZ Ok. 

PF Everybody still orders from Potbelly though. 

RZ Not, not—the wrap is what I’m thinking about. It’s purple and they’re like, “Oh [Paul sighs] this is a veggie wrap!” 

PF I know. 

RZ Cuz it’s spinach. It’s just cuz it’s—

SB Like a sundried tomato wrap. I think—I think that’s the one you’re thinking of. 

RZ It’s bullshit! 

PF Don’t—unfortunately you can’t say sun dried tomato around Rich.

RZ Ah [Skyler laughs] they’re a crime. No, but I wanna ask this question, though, five days, same people in a room. I’ve been a—I mean you do an all day meeting one day and it starts to become a grind. Like how do you off—like how do you keep that energy? I mean that’s rough. 

MQ It’s a challenge and I think, you know, there are a number of specialists out there that really help teams do this and to do it well because it very much is an embrace of, “This process works for this kind of a thing. Let’s do this thing.” 

RZ Yeah. 

[8:58]

MQ And in a lot of ways, I mean, in my experience and, you know, how I’ve—I’ve seen other people run them, they become very much an exercise of team building [mm] and getting everybody to understand what it is design is. And there’s an outcome from that that I think is valuable and is helpful [yeah] but in a lot of ways is—starts feeling like design theater. 

RZ Yeah. 

PF Define that a little bit. What’s design theater? 

MQ So design theater is very much the—the process of looking at things through a design lens when you haven’t done it that way [mm hmm] and really embracing it and learning along the way, but in a way wh—it’s not gonna be useful. It’s like taking an improv class. Like you’re not gonna join UCB, like you’re not gonna do that—like but you took the class and so you’re like, “Oh now I know something about—” 

PF Ok. 

SB I think in a lot of ways this is why some people are allergic to the phrase ‘design thinking’ these days. It’s seen as a business-y buzzword but doesn’t really mean anything cuz it’s difficult to follow through on. That’s the kind of design theater that we’re talking about. 

PF So you’ve got these things that feel really good. Like, “Oh we have a great plan for an app and we figured out what the first five screens are gonna be like,” but then actually turning that into action feels difficult. 

RZ But help me out here like is—is . . . are there design—there are designers in the room, there are bonafide designers in the room. Do they say, “Gimme two hours while you eat that wrap and I’m gonna design something—a wireframe, so I can show it to you, and we could talk off that,” like you’re all in the room together. Like you bring your laptops and you do some designing?! I—[stammers] I’m not—I’m not fully getting it. 

MQ There are a lot of wireframes, a lot of whiteboards, and a lot of, “Here’s how to draw a wireframe; here’s what these boxes mean [ah I see]; this is why this has an X in it [ok]; this is what fidelity means at this point.” [Yeah] Like, you know, high fidelity versus low fidelity. It’s a little bit of client education that happens [that’s what it sounds like] in the room. Yeah. 

PF There’s also a lot of like stakeholder interviews and things like that where you’re—

RZ Got it. 

PF—gathering real feedback and showing people things but it’s not—it doesn’t let you iterate and think. 

[10:55]

RZ Yeah. What the artifact? Like what are you like, “Oh! This is good. We got it good.” 

PF Yeah, what’s a successful Google Design Sprint get you? 

MQ A successful Google Design Sprint lets you have a—a prototype of some sort that you can then put in front of people and sort of gauge reaction. 

PF Mm hmm. 

RZ Ok. 

PF It’s good for a week. 

RZ You know what it is? You could really drift off and—and not get control of a direction here. It’s—it’s—you can do that and piss a lot of time away. So at least it’s forcing a little control. It’s sort of saying, “Hey! I’m gonna lock this door and you’re staying in there until you come out with something.”

PF It takes a lot of people a week to return a phone call. 

RZ It does. It does. 

MQ I think it’s worth noting here, though, that even people who run Google Design Sprints know that it doesn’t work for every problem [mm]. They’re very explicit about, “These are the types of things that you should be testing with it. Don’t make it too big. Don’t make it too broad.” It’s often focused on features and very specific pieces that you carved out from a larger piece of the puzzle [mm hmm] and in a lot of way the—the most successful Google Design Sprint will result in another Google Design Sprint. To say, “Ok, that didn’t work. Let’s take [Rich laughs] the lessons from that and do another one, and figure out a real closer, you know, more accurate picture as to what we should be building here.” 

RZ “So let’s stay together for another five days.” 

PF Are there other—like what are these other—so there’s ‘design thinking’ which is sort of very, very broad at this point. There’s the design sprints. Like what are the other kinds of things that people do to work out ideas? 

[12:25]

MQ thoughtbot has a product design sprint. thoughtbot is a—a [chuckles] global agency that works out of a lot of different cities but they—they have a playbook that they’ve developed and sort of posted online so that everybody can see. “This is what you’re getting when you sign up to do this with us.” 

PF Nice. 

MQ And—I think it’s very explicit, it borrows heavily from Google Design Sprints. It takes, you know, the pieces that work and applies their own method and their own ways of thinking about things and says, “You know, we’re gonna build a website in—in five days and it’ll be considered, from a product perspective, in a way that matches with how we build websites.” 

RZ I mean I have things I don’t—I’m not attracted to as part of this. What don’t you like about it? 

SB I find often these kinds of processes tend to just be looking for innovation for innovation’s sake. Or they tend to be—we—we don’t know what’s wrong, we know something’s not working but like, “Let’s all get together for a week and come together and talk it out and figure it out.” And that’s—I think there’s a place for that, for sure, of like if you have that kind of uncertainty about what the direction of your product is, you should do whatever it takes to figure out the clarity in that. But it’s not successful, necessarily, as a design or product exercise, to do that, to say, “Well, let’s just find a feature that will shape everything and change everything,” I think to Matt’s point about the result of that may be doing it over again. That failure or at least not—not a completely successful launch of that feature or even that entire product idea is—is a big risk with that. 

MQ And I don’t wanna make it sound like failure’s a bad outcome here. I think you learn a lot through iterative approaches to design. I mean this—the—the things that are in a Google Design Sprint are not inherently wrong in any ways and it’s really just a set of tools that have been laid out in a specific timeline to get to a certain result. 

RZ It sounds like it’s to get things going more than it is like, “Ok, we’ve got some—we’ve got a real picture here of where we wanna go,” cuz it strikes me as like design really—now the professionals need to get to work to some extent cuz 12 days later, you may find the design team comes back and is like, “Look, guys, there’s a fatal flaw here and we need to talk through this.” 

MQ I think one of the—the good outcomes out of a design sprint is that everybody’s at least talking the same language at that point. They know what—what [yeah] the designer means when they say ‘low fidelity wireframes’ and [yeah]—and when they point to the sort of guiding principles and say, “These are users and the actions that they need take and there are jobs to be done.” Like, when we have a framework for saying how—how might we do something. Like those are the right types of questions that everybody in the room should have [mm hmm]. So there—I don’t wanna make it sound like these things are bad or not part of a larger toolset that designers have in their arsenal. It just—a Google Design Sprint itself is not always the right answer. 

[15:18]

RZ Yeah. You ever see those, those like late night infomercials where the first part of is in black and white—

PF Mm hmm. 

RZ—and it’s just someone trying to use like a sandwich press but all the food keeps oozing out of the sides—

PF Right or they—they—

RZ And it’s like, “This’ll never work!!” 

PF They spill the entire basket of cheetos in their lap. 

RZ Yeah, and it’s just a bad scene and then the right product shows up and it’s just—it’s like you know the George Foreman panini maker or whatever? We’re reaching that point now. We’re going from black and white to color. 

PF Grill. It’s just a grill. The George Foreman Grill. 

RZ It’s a grill, that’s right. 

MQ There’s a really good reddit about this called “Where Does the Soda Go?” And it’s just [Skyler laughs] all of the videos of the black and white versions of—

RZ Oh is that true?! 

MQ Spilling things all over themselves [that’s great], very dramatically [that’s great]. Alright so we’re done with the black and white part, Paul. Do you know why? 

PF Why?? 

RZ Because we have introduced our own take on this sort of approach of like get in a room. And I think it’s really interesting and I want us to talk through it. It’s called Postlight Relay. 

PF Mm hmm. Well and it’s—Matt and Skyler’s are the leaders of design at Postlight. 

Pf Yeah. 

PF And they’ve been watching this world kind of for, you know, big chunks of their careers, and they wanted to react to it and create something new inside of the organization so that when people come in and they’re not quite sure what—what the next steps are, maybe more than just like you and me in a sales meeting going, “I don’t know! Let’s figure it out together!” Give them a set of steps that they can follow. Something Postlight can do to help an support them and at a certain point, you both took it, and you said, “You know, let’s—we’re gonna do something. We’re gonna—we’re gonna make a new kind of intellectual product inside the organization.” So what is it? 

MQ So people come to us with ideas [mm hmm] and they very much need a solution on how to move forward. What is the next step? How do I build from here? [Mm hmm] And they may not have that answer; they may not have had that experience of—of actually building product, and going through the process, and seeing what it looks like, and working with engineers, and piecing it all together. And so Relay is really designed to be design led. Engineering validated. But very much a conversation around what is that we should be building here? How do we get this into the hands of people to then validate that and say that we’re on the right track here and sell that vision? Make sure that people are equipped to carry forth their idea with true design thinking behind it; through strategic vision; and—and have an actual plan to build it. 

RZ How long is it? 

MQ Relay is ten days. 

RZ Ok. 

MQ That’s our starting point. 

RZ Alright. And you have a schedule you’re thinking about? Alright, I wanna play a little game. 

MQ Ok. 

RZ Ok? 

PF Lemme walk in the door. “My name is Dan. This is a—this is a do-gooder project. I have a—a couple pet adoption centers for pets that need some help and adoption and I wanna match people to pets. And I wanna do this on the web, and maybe on mobile, and have some video, and that’s kind of about as far as I’ve gotten. I know—I know that everybody’s online and I know everyone’s on their phone and I know that I have over, you know, I have 275 dogs, and I wanna match them to 275 homes. And that’s—that’s gonna keep going every year. So, I—design sprint sounds interesting. I have some funding. What—what are we gonna do here? Get me started. 

[18:35]

MQ So before you even walk in the door to start a Relay [mm hmm], there’s a sort of getting to know you stage. You know, it’s conversations; it’s a bit of a questionnaire; it’s trying to get a lay of the land as to what exactly you have today in terms of users; interested audiences that you’re looking at; what your inventory is, here it’s dogs [mm hmm]. Great. So, given that, what is then the next step? What are we looking to have at the end of this relay? And then we start by saying, “Ok. Day one. Let’s all get in a room and up—completely understand that, top to bottom. Everybody on your side. That’s everybody on our side.” It’s product managers, product designers, engineers. And all of the stakeholders and interested parties on—on your side to really—

PF I’m gonna bring 275 dogs into the office. 

MQ Please do [laughter]. 

SB How cute are they? 

PF Not cute. 

RZ I wanna—we—we glossed over this: there’s an engineer in the room. 

MQ Correct. 

RZ Ok, that’s interesting! 

MQ So, yeah, this is—this part of how Postlight works. We are driven by design but I think as an organization but everything that we do touches engineering. We live in a world of reality; of real constraints, that are actually helpful for designers to have and to understand and it’s part of our process. We’ve been doing this for three years and every point when we start making a product we are talking to engineers, we are understanding what are the data limitations; what is the structure today; what can we push on; what can’t we push on. These are real questions that keep us grounded in the real world of product that other design sprints don’t necessarily consider. I think that it’s—it’s easy to start getting into the blue sky, green field, purple mountain area of product thinking but it doesn’t then connect back to, “Let’s actually build the thing.”

PF Well, are you gonna share a dream or are you gonna make a promise? Like the way the firm—the dreams are important and there are like dream focused design firms, like think as big and broad, and this might cost a trillion dollars and not be possible but let’s go there! And then there is the promise like we deliver the promise. Like, “Yeah, you see this? It can be built. It can be built in the time that we said it will be built and it can work as well as anything else that’s out there or better.” So, ok, “We’re moving you towards a promise here. We’re gonna get you somewhere where it can be built. This is exciting for me cuz I have 275 dogs and I can’t have that many dogs.” Ok so what happens now? I come in the office, we’ve had this conversation. “I like you. I’m gonna write you a check.” 

[21:05]

MQ Well yeah, we start the Relay and in that first day we have sort of a download of everything, have everybody in the room understand what we’re doing here; who’s doing what; understand jobs to be done. And then we spend time synthesizing that, coming up with a true plan, and then getting to work on that. So, of the ten days of a Relay, we’re expecting this sort of full team to be exposed to what it is we do and really have a—a heavy duty feedback sessions [mm hmm] for four of those days. 

PF Ok. 

MQ We need time to work. We need time to actually put together some of these things and to actually validate—you know, do some of our own user research; our own user testing; of, you know, quick and dirty versions of prototypes, to really make sure we’re—we’re making the right assumptions here and moving forward with that. 

RZ Ok so you break up. You’re not living together. You tell the business stakeholders, “This is enough. We’ve got a lot here. Um, we wanna go make some stuff and come back.” 

MQ Yeah. I mean we think people are—are busy. There’s really [mm hmm], you know, more that they can be doing with their own business to make sure that things are set up, you know, I don’t know, bringing in the 25—[chuckles] bringing in the dogs. I think—

RZ It’s also—I mean, correct me if I’m wrong, it’s hard to do something really decent if you’re just hackin’ it together in a room with five other people. Like, going back to your station and going to work with a thought or an idea and taking a particular path in a focused way is meaningful, I—I think—I mean—

SB Yeah, as we were talking about defining the—the time allotted for the Relay, we talked about the idea of like headphone days. 

PF Mm hmm. 

SB Of sometimes you just have to go and put your headphones on and do the work. 

RZ Absolutely! Absolutely! 

[22:48]

SB So we wanted to make sure that that was reflected here, that’s part of how great work gets done. Collaboration is a key part of it but it’s not a hundred percent. 

RZ I completely agree. I mean I agree also because this is Postlight Relay but I actually agree. I mean, yeah, you’ll come back with a bunch of Post It notes and sketches out of the—force yourself to stay in a room but I think the professionals need to go and work a little bit, and come back. So, they—you guys, you duck out, you do some work. 

PF Yeah, what’s the first thing you show the client? 

RZ Well, what day are we at? 

MQ This is day four where we have a complete product spec of what it is we’re gonna be building [ok] in terms of the first version of these, the prototype, from the Relay and how—how we’re going to then represent that. 

RZ Ok. 

MQ Detailing what is the workflow going to look like. Um these are steps that we’re going to show; this is what the final product is gonna like like [mm hmm] when you step away from this on day ten. You’re gonna have a functioning prototype and a presentation deck to be able to walk around said idea to the people that need to see it. 

RZ Ok. Um. And then you come back and you present, and they react again? 

MQ So the first presentation is a little more collaborative than, “We’ve—we’ve solved it [chuckles] for you.” 

RZ Ok. 

MQ It’s more of a progress check to say, “This is where we’re at. This is our gut feeling. Here’s what we’re piecing together. Here’s—here’s our story. Let’s—”

RZ “There’s a direction we’re going in.” 

MQ Exactly. Just to make sure that everybody’s on the same page, that we’re on the right track [ok], and that we can feel good about what we have in ten days. 

RZ Ok. 

[24:30]

SB This also draws from our experience doing this work on larger engagements, or smaller ones, really all of the work that we’ve done here at Postlight, any moment that we have for feedback with the client is really more about that gut check of saying, “Is this headed in the right direction? How do we course correct? How do we make sure we’re taking the right next step forward?” But it’s even more crucial when we only have ten days. 

RZ Mm hmm. 

MQ I think that’s a core part of everything that we’ve done here at Postlight in three years is—is—it’s driving with conversations, it’s really getting in there and understanding what it is we’re doing. We’re not standing up in front of the room and saying, “Look at this genius design that we’ve created.” It’s—it’s a, “Here’s what we’ve heard from you. Here’s our vision, let’s figure out where to move forward from that.” 

PF And engineers have been checking in so this can happen. 

MQ Absolutely. 

PF Yeah, “We didn’t just go away and dream. Here it is.” 

RZ It’s one of—I mean—a lot of times people, bless their hearts, they think it’s gonna cost 80 dollars and the vision is really big or they think it can happen in two weeks [chuckles and snorts] like you have to kind of right size that early in the process and get to a more realistic place. 

MQ And that’s the thing about Relay is that we’re really not trying to solve every single problem in the room, day one, in ten days. That’s—that’s an impossible task. This is about making sure that we’re selling the right vision and idea and representing that as a real thing that you can click, that you can touch, that you can get a—get a sense of what’s it’s going to end up being [yeah]. It’s not gonna be pixel perfect. It’s not gonna be, you know, with beautiful branding from day one but—

RZ Right. 

SB Although it might be. 

MQ It could be [laughter]. We do that too. 

RZ You may kill it! 

[26:11]

MQ We try—I mean we try really hard to think in things that look and feel real because that is—design is communication and the best way to communicate an idea is to be able to believe it when you see it. 

RZ Yeah, this is, I think, a key point. Wireframes, they’re great to whip something together and whatnot but when it starts to feel like the real thing and you can actually click, that is a big, big deal. The conversations it spawns and the connection it’s looking to make is—is very, very different. 

PF Skyler, what’s week two like? 

SB The week two is more iteration. We take the feedback from week one, continue working, continue validating our work, and then come back to the full team to make sure, again, we’re on the same page, we’re on the right track. 

MQ We also take that—that learning and those initial steps and put them in front of actual people. In front of users and try to just get some gut checks from them as well. It’s not just about what does the—are we meeting the business goals? It’s can other people use? You know we’ve—we’ve done this with clients before where we’ve flown people out to really sit with people and put prototypes in front of them that were kind of whipped together but very much the expression of what it is that we’re trying to build and saying, “Do you believe in this?” Like, “Like do you think that this is a thing that you want?” And, you know, we’ll get feedback that says, “I—I—I want this yesterday. Give it to me now.” And that’s powerful to be able to come back to—yes! People—you’re right! This idea has legs. Also, put that in—in the presentation. Put that and say, “This is why we need to go get some funding for this because people are ready.” 

PF Right cuz ultimately we’re building a tool for people to get buying. Or maybe they need the buy in from themselves because they’re gonna spend some money on it, or maybe they’re gonna walk it around. 

SB I mean that’s part of how we view design here in general is figuring out what the right way to communicate for the goal is [mm hmm]. Sometimes it’s wireframes; sometimes it’s prototypes; sometimes it’s completely high fidelity pixel perfect. For this, because the goal is to communicate an idea of a product, of a real product out into the world, we try to get to the right fidelity for that, the right way to communicate that idea. 

PF Relay!! [Skyler laughs

RZ So, we’re at day ten. What am I walking away with? 

MQ At the end of day ten you would get your clickable prototype as well as your presentation deck and nothing should be a surprise at this point because we’re involving the clients at every step of the way with regular check ins, you know, that don’t require full meetings but do require some—some feedback and some critical decisions that are—that are made in those ten days. Really the end product should be a shared vision of, “This is what we built together. You know you went off and—and [chuckles] worked your magic on the design side to make them clickable screens but this is my idea and this is not only, you know, put together as a design but as very much feasible from an engineering perspective.” How do we put that together in a presentation that can share that vision further than just the people who were in the room that were involved in the process? That’s—that’s the last day. Really making sure that we’ve, you know, crossed those ‘t’s and dotted ‘i’s.

[29:10]

RZ I think—Look, I’m just reacting as just someone outside of the world of design, and as a business person, and as a product thinker. The idea of putting constraints around an effort but also letting the professionals go work I think is the key tweak here. And bounding it with timeframes and commitments is a very big deal. I mean, you know, they talk about how, you know, engineers will fill up whatever time you give them. For design, I mean, the subjectivity around it and the sort of open endedness could go, I mean, you could go on. 

PF I mean let’s be real about what we’re doing here, too, right? It’s very hard to get buy in. People—Skyler was talking about this earlier. Like, you can’t describe a product in words. It doesn’t work. 

RZ No. 

PF People who work in the field can understand it but everybody else is like, “That sounds great??” And then they’re—they’re wondering what the hell you’re actually talking about. And I know this because I’ve had to do it and it’s a disaster. Design is the only communication medium that actually works to let people know what a technology is supposed to do. 

RZ Yes. 

PF And so you’re never gonna get buy in in a big organization with your vision written down on a—

RZ Card. 

PF Yup. And sometimes you can just go take screenshots of competitors and be like, “We’re gonna do this,” but—

RZ Put the arrows in [chuckles]. 

PF Yeah, it’s just not like—

[30:29]

RZ It doesn’t work. 

PF You need a tool for walking around [yes] and that’s what this really is, right? Like it’s a blueprint, it’s gonna change when people go to build it, but you’re giving people a communication tool. 

SB We’re—we’re all nodding. Agreed. 

RZ I wanna end this with a service announcement and a question for both of you: we’re hiring designers. We’re always looking for great designers at Postlight. We are in New York City and if you love to do design work, and this kind of design work, where you’re—you’re inside, reach out to us. Which leads me to my closing question: how would you define a great product designer? 

SB A great product designer in general is somebody who can think in a lot of different ways, who can understand a product and a problem from different perspectives; who considers things in—in different dimensions. Somebody who can approach things from a business perspective; from an aesthetic perspective; from a user perspective. Having a combination of all of those leads to great work and great design. 

MQ For me I think it really is about leadership and leadership with a lowercase ‘L’. I think being able to recognize when you, as a product designer, what your role is; what you’re doing at any given moment, whether that’s with an internal team, trying to, you know, get everybody on the same page and understand what it is that we’re building, working with clients, educating them on what design looks like, what it is that people are expecting to see; being able to—to lead a conversation about design. All of those things are critical for—for what we’re looking for for product designers here, and we’ve built a team around that. We don’t have a Creative Director at Postlight. That’s not part of how we think about design as a discipline. We trust the people in the room and we put them in a position to be autonomous and make the right calls for our clients, and that’s a rare thing to find, and we’ve really built out a team centered around that. 

RZ [Laughing] Run with that! This was great. I think there’s a lot people can take away in a universal sense, even beyond what we’re doing here at Postlight—

PF Well you need a—I mean you need a process; you need constraints. Don’t lie to yourself that it’s all gonna get solved but the key thing is to get a tool that you can use for communication. 

RZ Yup. Thank you so much, guys! This was a lot of fun and very, very informative. 

MQ Thanks for having us, we’re excited to talk about Relay more [music fades in]. 

SB Yeah, it’s been great. 

PF Hey, Rich, just before we go: [email protected] 

RZ postlight.com/relay if you wanna learn a little more about this. 

PF No, that’s right. That’s right. We’d love—we’ve already gotten quite a bit of interest and we wanna talk to more people who want to solve big design problems in a big hurry. 

RZ Have a great week, everyone! 

PF Bye [music ramps up, plays alone for six seconds, fades out to end].