Your layout will be tested! Will it be able to survive? That's what we're going to talk about today.
About design testing. What do we have so far, my friends? We went through a long journey on this Bootcampinho.
And now all we need to do is test our layout. If you managed to follow everything so far you are a trooper! God bless you.
We are at the end. I'm glad you put up with me until now, there's only a little bit left, okay? If you've followed me this far, you should have a working prototype of your project.
And the question is, is this solution that you prototyped actually good? That's what we're going to talk about today. We're going to put that layout to test.
Remember what the test was? Do you remember those first lessons of ours when we talked about Design Thinking when I explained to you that the objective of the tests was to validate the solution? Exactly!
You're going to validate this layout of yours, and when I say validate the layout, I don't necessarily mean validating: "Is it beautiful or is it ugly? What do you think of this layout? " No, guys, it's not necessarily that.
Testing your layout is trying to understand some things, for example, trying to understand if your user will be able to perform the tasks expected of them. What are the most important tasks in your layout? What does a user need to be able to do in your layout, for example?
Write the tasks, in one line, what is the main task, what are the secondary tasks, what do you need to test to know if your layout is really working. In addition, testing your layout can also be, for example, trying to understand brand perception. What do users think?
Can they understand what this product is? What do users feel when they access this website? What do they think about it?
Are you experiencing the sensations that are expected? Is it working correctly in that sense? A test can also serve, for example, to validate a new idea, for you to try to understand with the user, "Oh, what if we did it this way?
Would it work? " Ideally, just like we do in the discovery stage, try not to make too many leading questions and let user talk most of the time. But sometimes, to understand an idea, "Oh, would it work this way?
Wouldn't it work? What do you imagine would work", you know? This can help validate new ideas even to evolve your prototype.
At the end of the testing phase you will probably have a new problem hypothesis, and then you will have to measure a bit if, based on this problem hypothesis, it is worth it, sometimes it is just a small adjustment that you make and it will fix the layout, you can test again. Or it may be that depending on the suggested adjustment, it may be worth it for you to do all the steps again, discover again, see if that user's problem really is the problem of other users and that way you can continue to evolve your product. And usually when we talk about testing we are thinking about Usability Tests.
Remember when we talked about usability? It's to know if your product is usable, if the user can really use that product. And in that sense, what will work very well is what we talked about.
Write what the main tasks are, what you need to validate. What do you think is important for the user to be able to do in your service and then you can research it with users. It can be quantitative research, it can be qualitative research, for example, in the case of a qualitative research, you can send the prototype to the user, normally this is a recorded call, in short, you can record the screen and everything, the user, the person commenting on the layout.
You can ask the user to narrate what he is doing or not and basically what you are going to do is take those tasks that you have listed and tell the user: "You need to do this on my website", for example, it is an e- commerce, you need to be able to add a product to the cart and complete the purchase and you just tell the user that and let the user do the task on their own. Then you can observe the user in what way he is doing, where he is trying to click or not, if he managed to perform the task or not. If you want, you can ask him to narrate it as well.
It all depends on how you are going to do this user testing. Also, if it is a quantitative survey, there are several apps that help with this. The first one I can think of is Maze, but there are lots of other sites, apps that help you run user tests.
Then you set up your screens, where you can click and where you can't and the application itself measures whether users were able to do it, yes or no, anyway, this can be cool to have solid data like percentages, but again the qualitative research helps to bring these insights beyond what you had thought, alright? It can also be just for observation, let the user test it freely. Usually, if possible, do this in a normal work environment, for example, it may be an application for people to use while they are working on a specific function.
If you send her to test it at home, this test may already be a bit of a false test, because it does not match the real conditions and so on. So it's cool that you also try to understand the situation in which the test takes place. And still in this test stage I want to bring you some extra points.
Like, for example, the test doesn't need to be done only at the end of your process. Only after you've prototyped everything. What you can often do is, try to run simpler tests.
Sometimes just talking to the stakeholder. Stakeholder is usually the person or the company that hires you. Often times these conversations alone help to validate many things.
One other extra important point related to this is that you cannot get attached to your layout. Wow, I used to do that a lot, a lot, a lot when I got into the design field, especially when I was in college, I thought to myself a lot: "Wow! My God!
Who said bad things about my design? What do you mean my design doesn't work? Oh my God!
". Guys, you have to be a little humble. It won't work, guys.
There are will always be things that need to change. Design is made of changes, guys. If you don't want to evolve your interface, it's no use even testing it, okay?
But it's normal for them to have alterations. It's normal for your client to say, "Ah, I think, could it be like. .
. wouldn't it work better this way? And what about that way?
" It's okay to have this conversation. And then, you as a designer, you have to measure a little. To what extent is it worth defending a layout, or defending a certain feature, for example, "I know this will work well", "I've tested it in other cases", "I've seen it in such place", "I suggest we do the same thing this big company is doing.
Will it work? Then we'll test it. .
. ", and so on, but it may be that in some cases defending your design is not going to work. If you don't know, if you're in doubt, don't even try to defend it, say, "Let's test it, guys", no problem.
You can even suggest to the client, "Look, I did it this way, but the ideal thing is for us to test it", that's what I always do with my clients. I say "Look, we did it this way, but the ideal thing is that we test it with users, because only then will we know what really works and what doesn't". This is maturity in design, okay?
You understand that your layout will undergo changes, it's maturity, it's normal, it's not because your layout is bad, it's not because you're a bad designer, it's because it's the process, guys, it's normal that there are changes and it's okay, alright? Take a breath, make the change there, and if necessary, defend your layout a little, but understand to what extent it is worth defending it. Furthermore, as I was also saying, the test, it doesn't have to be only at the end of the process.
That is, sometimes you made a wireframe there, you already have something to show. You can try to do a quick test there, even if it's in the form of a conversation, in a more informal way, because many times, with an idea that you haven't even prototyped you can already see that "Oops, this isn't going to work" or "If I change this it will work much better". Sometimes you get ideas from other people, your client, the person who is building it with you, who asked you for this service, they are not your enemy, they are your friend.
Join forces and make that people. . .
The developer, for example, bring the developer to the conversation as well, guys. We want to know technical limitations. The sooner you know the technical limitations, the better, because if you don't know, you'll make it and when you have everything ready "Oh my God, I can't believe I'm going to have to change my layout" right?
So bring this to the conversation, it's important to test, document everything, everything you have, every conversation, every meeting, every data, research data, every test, document everything, try to find patterns, try to group data that this will help the layout evolve more and more. And for us to finish before our little friend comes into action, what have we already talked about, guys? The test is just the beginning of a new assumption of the problem, it can restart the cycle, sometimes the test won't make you start the cycle again, but sometimes you can go back one step or another.
It's up to you to understand this feeling and that's when Design Thinking starts to become that mess that you see that it's not totally linear and your role as a designer is also to question the process, it's not to blindly follow a process, it's up to you to understand: "It works here", "Maybe I have to adapt it here" and when you get to these test phases, it becomes a little clearer and you see what worked, and what didn't and you can even adapt it for future projects, alright? And we're not leaving without our little friend talking to you. Alfredinho has a challenge for you and guess what it's about?
About tests, of course. You will analyze the screens you created and you will answer these questions here: (1) What is essential? What is very important to know to be able to launch this product?
That is, what do you need to know about your user before you can launch this product? Another question is the following: (2) What are the most important tasks that the user needs to be able to accomplish with your product or service? And the third is that, very classic: (3) What needs to be tested in order to work?
From that, after answering these questions, after having everything noted, write in one or two sentences what these main tasks are, because in the next lesson you'll be. . .
already start looking for users by the way, alright? You should already start looking for people, because later on we're going to test it, okay? And of course, if you want to know how we could, for example, apply this to my Amazon Web project, click on this card on the screen and we'll talk a little bit about it in the next lesson.
