Design Prototype | Alex Poterek

So that's kind of a really quick intro to what XD is. And like I mentioned before, this is a new product. This is us having to pitch to the company that this is something you need to put resources to. So it's not a given. It's a very kind of steep hill to climb to get this into production. So how do we build new products at Adobe? It's just like starting up a new company. We have to build those relationships. We have to get resources. We have to convince designers that they should come work on this with us. Not all the time as a full-time thing, but sometimes as a side note. And kind of work our way up and kind of prove things out. So all our new initiatives kind of revolve around this. There's this design aspect. There's business. And there's engineering aspects of it. And the product fits really nicely in between all of those things. At Adobe, we have a really nice relationship where input comes from every direction. Engineers have a lot of input on how design tools should work, and designers actually have input on how engineers should approach this, because a lot of us can also program, but not to their level. And then obviously the business unit, they need to see a path for money. So the story behind XD is kind of reskinning what the creative process is. And that's make, show, and learn. And that's what we showed you before. It was essentially like, I'm going to make this thing. I'm going to share it. And then we're going to kind of learn and react to it. So when I say reskinning of that, I mean we approach it more like this. It's design. It's prototype. And then it's share. And you can see that. Pretty obviously in our actual frame of the application, you have Design, Prototype, and Share. That's the foundation. That's the core. That's what we want to focus on. We want to stay focused. We don't want to become what Illustrator or Photoshop have become. They're very powerful, very great tools, but they lose focus. They're kind of all over the place. And since I made the switch to XD, going back to any of those apps, it's really frustrating. They're great for certain things, but for designing and prototyping an application, XD is just really quick, really focused, and it gets you to where you want to be. So where do we go from here? We have this very basic concept, and we're in this weird position where we're designing a design tool for designers. And we're designers ourselves. So do you design for yourself? I'm the user of this product, and that's a trap you're going to fall into. You can work at Facebook. You can work at Google. You're going to be designing these apps where you're going to be using this application yourself. But you don't want to fall into this trap where you're designing for yourself, because you're going to be wrong a lot more than you think you will. So you want to design for your user. Pretty obvious advice, but it's really sound advice and something you have to constantly remind yourself as you're building new products. And also remember that you are not the user. You have all of this context in your head. You're filling in all of these mental gaps that the user's not. So these gaps might be too large for the user to jump. And what it really comes down to is instinct versus insight. Your instinct is what you know and what you think is right. And insight's something that you're going to have to do work to get to. So instincts is designing for yourself. And then insight is designing for others. And this is why we prototype. The 2 large pillars of prototyping for me are building consensus and test usability. And there's so many things in between there, but to break this down a little bit, building consensus is incredibly important. You can go into a meeting and you can have an idea and try to verbally explain it, but so is everybody else. And building a consensus around one idea is crucial, and prototyping goes a long way. And then on the other end is testing usability. Could you expand more on building consensus? Sure. So if you're given a problem and you're tasked with a team to find a solution to it, people are going to come at that problem from a ton of different directions. And if you feel strongly about yours, explaining it, you're on the same level as everybody else. But if you actually build a prototype to actually show them, even if it's just a quick A couple screens, or maybe it's a motion prototype or something else, you are kind of on another level than everybody else, and everybody else can kind of see where your mind is. And so consensus building is probably one of the most important parts of prototyping, in my opinion. And then there's the whole testing usability part of it, which is, does this thing actually work the way I, as a designer, intended it to work? And that's a kind of different end of the spectrum.

Yeah.

But like I said, in between, there's so many different things. There's validating a direction. There's decreasing the risk. So if there's something we feel strongly about, there's this whole concept of, is it worth the risk? So getting to that point quicker is always better. And you want to shrink the task down to something a little bit more manageable. And prototyping helps to get sign-off and approval. So prototyping also lets you get this in front of users early and often, which is incredibly important, because when you're building a real product, there's this pretty linear thing where you're like, here's one feature, let's build to it, and let's get to it, and the users are going to test it. But at that point, you've put a lot of resources into engineering, so if it fails, you're going to double down on it, and you might just make a bad choice to continue with something. But if you build a prototype, you're going to get to the real enough test real soon. And there's this great quote, which is, if a picture's worth a thousand words, a prototype is worth a thousand meetings. And I can't really find the source of it, but everybody kind of, sort of attributes it to a guy at IDEO. But it's a great quote. It's incredibly true. So when you're prototyping, you want to start small, and you can increase your fidelity. as you go. So you want to start with something small, show it, react, build higher fidelity, higher fidelity, and higher fidelity. And a great example of this is from the best movie ever.

Without much further ado, I give you the Derek Zoolander Center for Kids Who Can't Read Good.

What is this?

A center for ants?

What?

How can we be expected to teach children to learn how to read if they can't even fit inside the building?

Derek, it's just a—

I don't want to hear your excuses! The center has to be at least 3 times bigger than this! He's absolutely right. Thank you. They have a vision. And so do I. Let me show you why.

So, I love that movie. So any excuse to play that, I will. But it's actually a good example of showing somebody a prototype that's too high fidelity too soon. They get hung up on details you don't want them to get hung up on. It might be like, how is this flow going? But they're going to say, hey, I don't like that icon in the top corner. I don't like these colors. Then they're going to start giving you suggestions on how to solve those things, and then you're kind of on the line to take their consideration, and it's not what you wanted feedback on at the time. So you don't want to confuse your users. Too soon in the process either. You want to make it understandable and believable. And that goes to how high fidelity you want to make it, because if it's early on in the process and it's incredibly simple and they're just wireframes, your user's going to understand that this is not the final thing, and they understand that, and they'll give you related advice.