This content was created by Tim Draper. This content was uploaded by Tim Draper. This is a YouTube presentation titled "4 Pillars of Prototyping | Alex Poterek" (posted March 6, 2018). It is a talk by Alex Poterek about designing and validating features in Adobe XD. He describes the product’s evolution, how the team gathers feedback (Twitter, UserVoice, user testing, eating their own dog food), how they question feature needs (example: adding layers and making them contextual/smart), and the importance of building on a design system (Spectrum). He outlines four prototyping pillars — figuring out what's needed, questioning why, building with a solid foundation, and choosing testing methods — and gives examples of paper prototyping, JavaScript prototypes, After Effects for motion finesse, and a visual versioning feature demo (referenced from Adobe MAX). Audience/participants implied: Alex Poterek presenting to a conference or user group (Adobe designers/audience).
Chapters
This is where we started with XD. It was an incredibly simple solution. It was, you have your tools, you have some contextual panels on the side, and then you have your main focus on the artboard. And then we grew this a little bit. We actually made this prototype where this was an actual working prototype that we got in front of users. And they tested it out. They used it. We got feedback, and we grew from there. And at the end, we had this frame. And then today we have a pretty powerful tool for designers. So now that you know a little bit about XD and what it does, I kind of want to talk to you about how you can remove a little bit of the friction in prototyping and the process. And there's 4 main pillars for this. There's figuring out what's needed. And that's like, what's the next feature? What's the big thing that you're trying to solve for? And then questioning why it's needed. You can get feedback from users. You can get your own opinions in there. But if you're not questioning why it's actually needed in the product, you're going to fail pretty quickly. And then you have to build with a foundation. And this is going to talk a little bit more about style guides and how we at Adobe do this. And then choosing how to test it. And that's different methods of testing. So let's start with figuring out what's needed. So at Adobe, we have this product that we have shared prototype design. So how do we decide what we're going to build on top of that foundation? We use our own expertise. We're designers, like I mentioned before. We user test. We are on Twitter pretty frequently. If you tweet Adobe XD, they're going to respond within a couple hours. Roundtables are great. So we really like to engage with the community, do something like this, get a little bit of feedback from users. And like I mentioned, people are actively just telling us what they want on Twitter. And then we use something called UserVoice, which is just set up to actually get feedback from our users that are using this product, and they can kind of Vote up different feature sets. And at the end of the day, we also eat our own dog food. So what that means is we actually build XD inside of XD. So there's this level of inception that's happening there. And since we actually do that, it's a proven— it can become a product from XD, which is always great. And I always click on that color swatch instead of that one, and it's annoying, and I hate it. So once we actually get all this feedback from people, it's why is it needed? And we're the design team at Adobe, so we should know what designers want in this product. But it's not always the case. So that's when people ask, when are you going to add layers into Adobe XD? We didn't have layers before. We have it now, so spoilers. But people kept asking us, when are you going to have layers in XD? And our reaction was, why do we need layers in XD? When I showed that whole demo, I didn't use layers once. Some people love layers. Layers are great. I personally don't use them. So that's why we were very adamant about asking that question. And it's a very obvious thing, too. Every product has it. Why wouldn't we have it? We can't just make that assumption that it's something we need, though. So like I said, we have our own biases and our own opinions, and other people we're requesting this. So we kind of looked at our own files and we're like, here are what layers look like in our products. And we don't manage them. It creates a lot of overhead. It's just kind of chaos at this point. So we asked other people to share with us their files. And we're still not convinced. At this point, people are sending us these files that they're not managing, they're not naming, they're not doing anything with. So if you look at what do you do with this? It's just chaos on the screen right now. It's a mess. It's a mess, right? Who wants to deal with that? I understand some people love layers, but remember, this was our vision. This simple, just blocks of tools, couple contextual panels, and that was it. It's like, I don't understand it. So we had to step back and kind of say, why are people using this? Why are people so adamant about having this in our product? So we did take a step back and we kind of looked through what people were using this for. And it was just like, yeah, that's a lot of things. That's a lot of reasons why we need this. And maybe we should take a— take a better look at this. And we did notice that our main problem was that layers weren't smart enough. So that was our next question. What if we made layers smarter? So this was actually a prototype. I don't know if it's playing. Oh, there we go. So as you can see on the right side, layers are usually pretty static. You have to open it up, go in, drill in, find what you're looking for on an asset level. But we asked ourselves, oh, what if I select something and it's only exposing the relevant information? This was great. It was a great thing to explore and prototype. And this is why prototyping was so important. We're like, we're onto something with this. But this was a little bit too far. We took it a little bit too far and made it too simple. So layers in XD now is a mix between what people are used to and what we envisioned, and that was Your standard layer list. But when I select an element on the artboard, it's going to only expose layers on that artboard. And when I dig into something, it's going to dig into that folder as well. So everything is really contextual. It gets the things that I don't need out of the way. And it allows people to lock layers and rename them, customize everything about it. And that's all great. And these are how we build features and we validate features through prototyping. But a really important part of that is building with a foundation. And at Adobe, we use a system called Spectrum, and that's our design language. And the Spectrum team is responsible for creating icons. They're responsible for just the smallest elements of the UI that I'm going to use. And what's really important about this is I can just take from them, and I can just use it like Legos and build this product really quick, and I don't have to worry about a lot of things. So they're also responsible with how big text is going to be for legibility, readability, accessibility. And I don't have to worry about these things as a designer, so I can quickly move through my prototypes fast. And just the smallest level of detail, too. You can see these little animations that kind of go in and out. This is finesse that I don't have to worry about. It's a really simple language, just a circle with a line. So you're saying that you're not worried about the lines, and it communicates really well. So it's an incredible team. If you think about Photoshop, we have over 1,000 icons in Photoshop, and they're responsible for maintaining just all the icons. And that's one product. So choosing how to test it. Like I said, we don't always have— we don't always make the right decisions. I, at one point, thought this hat was a good idea. And my grandma actually called me out on it. So you have to remind yourself that you make dumb decisions, and you have these weird biases, and you have to test this. And you have to go into a user test knowing that. So this is an example of a— oh. Let's see if it plays. All right. My video's not— oh, there it goes. Okay. So this is what paper prototyping is. Maybe some of you have heard of it, but it's essentially what you created in XD, we printed those things out, and we put it in front of users. So we set something down and we say, explain what you're looking at. Tell us what you're looking at. We don't give them any sort of indication of what it is. We say, okay, now that you're doing this, how would you do X? And then we would just be hands-off, and they would say it. And you kind of want to be like, just press that thing. But they will kind of digest it all, and you can kind of see where they have these questions. This is a good time to say, what did you expect to happen, before we show them what actually will happen. Then you can kind of get that high-level feedback from them. It's one of my favorite ways of testing a prototype. It's a little bit analog. It's physical. But it keeps me honest as a designer, because I put this in front of the user, and I put this in front of every user. I'm not going to my computer and saying, oh, if I just tweak this, they'll understand it. It's, let's make sure everybody that sees this is having the same reaction to it. And this is super high level. These are static images. And this is an example of just crudely creating something. This is a feature we announced at MAX, Adobe MAX, which is our big conference last year. It's visual versioning. It lets you actually scrub your timeline and show the history of your designs and actually go back and grab your assets and bring it to the present. And it was hard to get a feel for what this is like in static images. It was like, how does this feel? So I built this— it was a JavaScript prototype just real quick, just to see how dragging feels and how you want to interact with it and how you expect to. So you have these static images, which are great. You have this actual coding. But then sometimes you need the finesse. So maybe you'll go into After Effects, and then you'll actually design how these different things are going to feel. So you can see these— tweaks and transitions happening. So these are all part of the prototyping world. And you kind of have to figure out which one's best for you in each situation. So those are the 4 pillars of how you can really help yourself with prototyping. Thanks, Tim.
