Let's talk about how you get really great outcomes with your design team. This may be a dedicated designer on your product team, or it might be a pool design talent that you have access to. Regardless, I think a good way to look at this is identifying more specifically the jobs where design is pertinent and then thinking about ways we can interact with the talent and identify the talent we need that get us to better outcomes with the team as a whole and the product as a whole. Well, starting out with the job, we have this area of continuous design and we have this metric here that tells us how we're doing, which we think about is S_d in this equation. If we look at F, this question of how much does it cost us to release a successful feature? Then, we can see this is enormously sensitive to S_d. For example, in the simplest terms, I think maybe if we took this from 0.5 to 100 percent, nobody is going to be perfect like that. But just as being that close, that'd be like doubling the amount of output from your engineering team with regard to F, which is a pretty big deal. It's pretty exciting if you think about it. The way that we've unpacked the job of design even further is into this right problem, right solution unpacking, and then to layer in our hypothesis-driven approach to doing things with the product pipeline, we've unpacked it into these hypothesis areas. Designers will be relevant all across this and not even in just strictly this area, but certainly, this area of continuous design is a big focal point, is one where you probably are most likely to be a significant individual contributor as well as the product manager. That and hypothesis testing are generally areas where product managers end up doing a lot of work as individual contributors. Given that though, we still want to think about how we effectuate a solution with the design talent because A, of course, we can't do everything, and B, design is a job. The designers are very good at doing certain things that we can't possibly do as well by ourselves, at least not consistently, unless we put ourselves through that rigorous training. As we look at the design talent and how we help them, help us help the product, I think a good way to unpack what we might mean by design, because even in this very specific domain, it can mean several really distinct things, is this model of user cognition that Donald Norman uses in his book, The Design of Everyday Things. The idea is that a user goes from having a goal through these feed-forward steps, they interact with an item like a piece of software and then there's a feedback loop. In the example in his book, The Design of Everyday Things, which is excellent intro to product design if you're interested, the example he gives is he's sitting in an armchair near a window, it's getting too dark though and he can't read his book anymore. He starts off with his goal of continuing to read the book, which is really analogous to a job to be done in the way we've been unpacking things. The planning step at this reflective layer sounds more elaborate than it really is. What this means is he's going to choose between alternatives. He could go to another spot in the house, he could quit reading, he could turn on the light. Maybe he has this thing on his Kindle as well and he'll just start reading it on his phone. He's going to choose between alternatives, is what we mean by plan. He is going to specify the steps of his choice, which in this case is turning on the light. Here again, we're talking about behaviors that are very innate. He's done it a million times. He knows how to reach up and turn on the light without even really consciously thinking about it. Then at this visceral layer, he notices certain things like, did it click or does it feel like it's moved from the off position to the on position, for example. Then he's going to perceive the light turned on or it didn't work, it flash because it's an incandescent bulb and it burned out. He's going to see if he can still read or not. Then he's going to compare this to his goal. Well, should I just keep reading or am I good, or do I actually want to just go ahead and do something else? Now, how does this relate to effectuating good solutions and knowing the design talent you want? Well, at the visceral layer in digital, we're generally dealing with issues of how user relates to things visually. This is the area that used to be called more so graphic design. These designers who are good at this visual design are often trained in relatively traditional programs that have to do with print and things like that. Then they'll, they'll go out and work in digital. Some of them are trained in digital mediums from the start. That's their focus. They're really good at the human cognitive and emotional resonances of colors and shapes and how we see things and perceive them and behave around them. Then at this behavioral level, this is where you have what are generally called UX designers, people who are specifically trained to design digital experiences and test them and work with the product team. Those people are really useful at helping you think about user stories, which we'll talk about later, about comparable interface patterns that you might want to use that are present in digital. There may be a good fit or not as good a fit for what you're building. Then finally, we have this reflective layer and this is what you might hear called strategic UX, or just the role of the product manager even. What do you have on hand? What talent do you have available? What kind of talent do you need? Well, that's something you'll want to assess. But it is important to understand, I think that one designer may not be trained in all these different things, so it's important to figure out what they want to do, what they have experience doing, and then work together to fill in those gaps as best you can. The thing that probably designers most dislike or happen to the most that they dislike is hey, we made the product, can you make it look nice now? That makes things hard for them because design, even at the visceral layer, isn't just about make it look nice, it's about understanding what the user is after. It's a lot easier to work on in small batches iteratively before the factoring the fact, after the fact, rather than going back and retroactively figuring out how to achieve good design.
