Prototyping For Your Stakeholders

Lorenzo Guadalupi at UXDX Community: Europe South. Video: https://youtu.be/M_HIo4RVjFE

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From product design to the digital world

[00:00:00] Thank you everybody for being here. I am Lorenzo Guadalupi, and today I would like to drive you and dig into the prototyping world. I would like to introduce you to how my experience taught me to adapt to the different circumstances and the different stakeholders you may be involved with and may relate to, and to choose your prototyping technique and prototype accordingly. It's going to be a quick guide.

[00:00:30] I'll give you a little bit of an introduction about myself. I am Lorenzo Guadalupi. I am an interaction designer working for Sketchin, and I have been working in this field as an interaction and user experience designer for the past six years, more or less. Nevertheless, my background wasn't always in the digital world. I started as a product designer, so I studied product design, actual physical products.

[00:00:58] But I soon learned, when I moved to the digital world, how the two things are actually quite similar to each other. Things for product design can be very well applied also to the digital world, and within this category it also fits the prototyping, the whole prototyping world.

Why prototyping matters

[00:01:19] Why am I talking, and why would I like to talk, about the prototyping part? Because I believe it is really important, as important as design. Once you are done with designing your components, your screens, that's just a part of the job. What you need to do is to connect the dots, to make your designs alive, to make them way more understandable for people that are seeing and using it, and to design also inputs and feedbacks. That's what all the prototyping in the end is.

[00:01:51] It also may help you to uncover unexpected paths and unexpected features that you may have not thought about in the beginning, so it's helpful both ways.

[00:02:02] Besides that, prototyping is also a fundamental tool and plays a fundamental role in the design process. I have distinguished two main groups, let's say, where prototyping plays a very big role. The first one is when you want to communicate something, which is your designs, when you want to communicate what you meant with your screens and when you want to deliver a message. Delivering a message means also picking the right target and picking the right tools to deliver the message the most effective way. The second is when you want to test what you design, so when you want to use your prototype as a tool, as a means, to test what you actually designed and to check that everything works as planned, which most of the time it never does.

Communicating: three moments, three targets

[00:02:49] Let's start with the first group, so let's do the first part, the communicating. What I want to highlight is that it's very important to pick the right target in the right moment and deliver the message you want to deliver. It's important to prototype according to different situations: the right animation, the right transition, the right feedback that you want to have from the system, so that the different stakeholders understand, build and eventually also use your product.

[00:03:17] When do you prototype, in terms of a timeline, when you use it to communicate something? I simplify the design process into these three main stages. The very first moment is when you want, in a way, to surprise your client. You want to convince him that you are the perfect designer for that moment, that you are able to think outside the box, that you are creative. So it's when you want to show your capabilities and you want to win the deal, eventually.

[00:03:51] Once you've got the client, you're going to use your prototype to review your work. It's much more effective if, instead of showing the static screens, you show an actual prototype. It is way more efficient to deliver a certain message, and it may happen in daily, weekly or monthly design reviews that you may have with your client.

[00:04:14] And finally, when you want to submit your project, when you want to deliver everything you designed, everything you worked on, and you want someone else to take over and take what you designed and make it a real product. So when you want to submit it, essentially, to the developers, so they can put their hands on it.

[00:04:33] As I said, it is really important to define these three moments. Then it's very much important to know the target you're talking to, because these three moments are always related to a specific target. The first one is the client, then it comes to the developers, and then it comes to the users eventually.

The client

[00:04:49] Let's start with the client. When talking about the clients, it's very important to distinguish the two moments. The very first one is when you want, in a way, to impress them, when you want to convince them that you are able to solve their problems and to find a creative solution for the problem. In this moment you need something that doesn't have to be fully structured. It has to be a prototype with animations, maybe, that can show your capabilities, what potentially you can achieve.

[00:05:26] That's in the very first part. Once you actually start building a relationship with them, so you got them, you convinced them and you want to start building and make sense of your design, then you can be a bit more simple. You should go more about the flows, connecting your screens. It's much more efficient, as I was saying before, to show a certain path or a certain flow you designed or you thought of by using prototypes, instead of showing them different screens one after the other.

[00:05:56] As an example, you have three screens which happen in a sequence when you do a certain click on a button or something like that. It's way more efficient, and more understandable, if you actually show them a simple prototype. It can be done with InVision, it's just a simple click and go to the next screen.

[00:06:15] So here you have to be sure you keep it simple, that you make it very clear what you're communicating. It's very important that you explain what you want to design. Just remember they are not you, and you're not in their mind, and no one actually is. What for you may be obvious, for others always remember it's not that obvious.

The developers

[00:06:43] The second group and the second target I want to talk about is the developers, and here you need a different kind of prototype. Once you are delivering your product, if you are handing it over to the developers that actually have to build it, you have to be very, very precise, because you have to design every single animation, every feedback, every kind of transition and so on.

[00:07:10] Remember, everything you don't design will be designed by someone else. If you don't show how a certain feedback is received by the users, someone else is going to design it for you. You put so much effort into our work, so you may want to put attention also on that.

[00:07:26] We used to write functional specifications to say this thing works in a certain way, but I believe, and I learned, how showing it is way more efficient than actually just writing it. If you can make your prototype in a way that you show the details of the different feedbacks, the transition, the animation and so on, that's way more helpful than just writing it down.

[00:07:57] What I usually do is create a mix of prototypes when I have to communicate to the developers, when I essentially have to hand my project to the developer. What I usually do is to create a prototype which is more architecture-oriented, so you have a clear structure of your pages, a clear connection between the pages, so from here you go to B, to C, to D, and it has to be super clear what you're following. And I usually add specific animations, or specimen videos can be used as well, to show how to display and how to design a certain feedback, for instance, or a transition, as I said before. So it works also to mix different kinds of prototypes sometimes.

The users

[00:08:49] The last group and the last target is the users, and here I cheated a little bit, because you're not really communicating directly to the users. You may pass always through the developers, because in a way they are going to put what you design into the final product. But what I meant with the user is that you are actually using the feedbacks that you're prototyping, your transitions, your animations, everything that is actually interactive, to enhance your user experience.

[00:09:20] Nowadays users are very much used to very complex digital products, so they expect to be engaged all the time with their products. They see animations and cool micro effects in every digital product they interact with, and these may also play a big role in the user experience.

[00:09:42] To make a quick example: when you are in an e-commerce and you see a list of products, you select the product and you want to add it to the cart. What you do is click on the little heart or the cart on the CTA, and you see the dot moving from the bottom to the top. That's something that really communicates many things. It communicates where you are going to find that product: the product was there, and now you're going to find it in the top right corner. It also helps users to locate the cart in general, so not just where you put it, but to understand also that icon. The little dot that may appear on top of that icon communicates the fact that there's actually something in there. So just by having this little transition, this little movement, these little micro animations and micro interactions really help your user experience to reach the next level.

Choosing your tools

[00:10:36] Where to start? It's important not to be software-dependent[?]. What I always try to do is to experiment with different software, not to stick with a single software, a single tool, because you may need different things, different tools, according to the distinctions I explained to you. Before, I was telling you about how I usually build a structured prototype with something that was more architecture-oriented, and something that is way more animation or transition oriented. In these cases it's very important that you try and you experiment with different tools.

[00:11:19] I have no tools in particular to suggest to you, as everyone has his own flow, his own peculiarity, so you can try and find yourself what you are more comfortable with, and that's going to be the right one. But just don't stick to a single one, and always try to innovate and try new things, because nowadays there may be five or six tools that are very great, tomorrow it will be 12, in a year it will be 20. So try always to explore and to find new tools and new software.

[00:11:51] The only parameters and criteria you have to have in mind when you want to choose a tool for a specific moment of prototyping, or a specific target as we said, are: time, so how much time you are going to need on that prototype, because there is software that is way more time consuming than others; the audience, so the target you are talking to, for the things we explained before, so be aware who is your target, who you are communicating to; then the realism, so the level of fidelity you want to reach with your prototype, it can be basic but it can be really complex, so almost looking like a final product; and the format, so the output essentially, or the file you are using to deliver your message, which could be a movie, it could be an HTML, it could be many different things, or an app.

Testing your design with users

[00:12:43] So this was for the first part, communicating, and we covered, let's say, what it is to communicate for the stakeholders: developers, clients and users. But in the end your final goal is to design for the users, so they are active stakeholders, because they have to be involved in your whole design process. And how do you do it, how do you involve them? By testing your products, by gathering feedback from them, and you do it by letting them use your design through different kinds of prototypes.

[00:13:22] When do you test? Testing your prototype can happen really anytime in the design process. We know it's an iterative process, and you can do it from day one, minute two, when you started your process, to the very, very, very last day of your design process. It's very important that you do it often and as many times as you can, because you will always find flaws and things that can be fixed.

[00:13:51] You can do it in a very early stage, where you have simple basic rectangles and you want to understand how a specific transition you had in mind, or an animation, or scrolling you had in mind works, so super, super basic. Or when you have something way more advanced and complex and you want to understand whether the whole feedback you are communicating is not too overwhelming, and what you're trying to deliver, and so on.

[00:14:19] What I'd like to say is that it's important to fail: do not be scared of failing. Actually, you should be worried if you don't fail in a user test, because it may be that you missed something. It is very, very rare to get something right on the very first shot, and if you have not found something that is not right, it's probably because you were not looking in the right place. So do not be scared of failing and continuously failing, because as we say, this is an iterative process. You may fail in the beginning, you may fix some things, test it again and fail over and over, but that you should not see as a bad thing. It's actually a good one.

[00:15:00] And most importantly, fail fast. It's very, very important that you do not postpone your test to the very end of your design process, because it will be way more painful to make adjustments or to edit your designs. The sooner you do it, the quicker it will be for you to go in the right direction. If you wait too long it will be way more painful to go back and fix. It could be painful just for the format you're using, the software you're using, but also for the amount of things you have designed so far and that you have to change.

Knowing what you want to test

[00:15:40] It is very important, when you test the design through a prototype, to know your final goal, because you may have different goals when testing a design. You may want to focus on certain specific parts. You may want to focus just on the user interface, so you may want to know whether your design looks good and understandable. You may want to focus on the architecture, on the structure of your pages, on the interaction, on the data.

[00:16:10] On the user interface, let's say you want to know whether: okay, I see this loader, I understand what that means, I understand the different colors, what they mean, the color coding, the validation behavior, what small components mean. Or, in the pages, the architecture: I want to be sure that you understand that you are navigating and your flow is from A to B to C to D, and D is related to A in a way, and how C agrees with the previous pages. When navigating your product you will have to be able to understand the structure of the product you are navigating.

[00:16:53] The interaction: as I said, it's important that the elements they design are perceived as interactive, and that the feedbacks that you gain from them communicate the right message, so that the user doesn't misunderstand what you designed or what you were trying to communicate.

[00:17:12] And finally, data. As another example, maybe there's a dependency of data in your design, so you may want to test whether, in a complex CRM-like product, the user understands that adding a certain piece of data in a certain input field has a consequence in another part of the pages, and understands that the consequence was really related to what they just put in. It can be also the whole validation process of a form, so entering a certain amount of data and information that has to be validated, and then the user has to understand the whole part of validation, and that it is related to what data are validated and why something went wrong, in case something went wrong.

Quick prototypes, split into pieces

[00:17:59] An important tip. What I usually do, when I have any doubt about whether something could work or could not work in my designs, is that I prototype it. It can be very quick, very quick and dirty. It doesn't have to be very precise, but if I want to know that something is working the way I am thinking, I usually run a quick prototype about it. And when I say quick, it should take less than 30 minutes. If you take longer than that, it's not quick anymore. It might still be very dirty, but it's not going to be quick.

[00:18:48] Also, what I usually do is to try to split my prototype into pieces. Do not try to achieve the perfect prototype where you have everything in a single file, in a single product, in a single flow. I think it's much more useful to split your product into different parts, so you can test or communicate one thing. That also applies for the communication of the message: if you want to test the communication message, try to focus on that part.

[00:19:19] Maybe on the home page you want to test how a certain interaction works, and if you have also designed and prototyped other parts, like different flow types, do not try to put everything in a single file, which is going to be way more complicated to handle and to edit if you have to edit something. Also for people that are receiving it, it's harder to understand, because if they have to navigate a whole prototype that is fully interactive, they may get lost in the prototype.

Wrapping up

[00:19:57] Just a few things to wrap up, a few things I would like you to remember about this presentation. The first one is, do not be software-dependent[?]. As we said, try, experiment and test out new tools and new features, because they can always make your life easier and better, and you can always find something more up to date with what you want to try and design.

[00:20:23] According to the target: pick your target, prototype for them and deliver the right message according to the target. We saw how the clients, the developers and the users need different kinds of prototypes according to the situations.

[00:20:40] Do not be scared of failing, and do it fast. The sooner you fail the better it is, and if you are failing it's just a good thing, because you found room for improvement in your design, which is a good thing, because you're going to make it better than before.

[00:20:55] And divide your prototype into pieces. Do not try to achieve the super complex UI[?] with many different features. You can split it into different parts and test or communicate them separately.

[00:21:10] So that was it. Thank you very much, I hope you liked the presentation, and see you.