Testing prototypes in software development
Dmitry Melentev, head of the design department of the Paneglif company, specifically for the Netology blog, spoke about his experience in testing prototypes when developing a software product.
In the development process, we often encounter the following dilemma: how to make a product well and quickly, but at the same time interesting and understandable for both users and customers. Nobody wants millions of similar questions to pour out about how it works at all.
')
The recipe is: test the product before entering the market.
Of course, you can test right before the release. Many companies do this: they release “beta”, look at the reaction, collect feedback, then bugs rule. Good practice, but it happens that users do not understand all the main functionality, and not just interface trivia. And it turns out that you need to redraw everything, redo everything. Or write a huge manual for users that no one, other than competing developers, will read.
Therefore, you need to test not at the end of product development, but much earlier, maybe even at the beginning.
We always want to avoid testing prototypes, pretending to be a vegetable. Why test, if so “everything is clear”? After all, it will take time to develop a product and add organizational problems — the same selection of people for testing is worth it. And the room needs to be taken somewhere quiet, and still be kind to all respondents, even when they, to put it mildly, are not somewhat oriented in what is happening. It seems that it is possible to cross out this small "episode", save resources, and no one will even notice. And all will be well!
But that doesn't work.
In reality, it is better to spend 30 minutes testing the prototype on users, than to make a design, impose, program, and then find out that you need to redo everything!
Even if the respondents are company employees, the main thing is not the ones responsible for the product design.
There are several time-tested and experienced ways to test a product: starting from the stage when it exists only in the form of sketches, and ending with testing the prototype on users who will think that this is a ready-to-work site, and no prototype at all. Sometimes it is true.
On paper, it is ideal to test concepts when there is access to a target audience and several people to conduct a study. It is best to test complex scenarios with multiple screens, a million buttons - in general, something that can be similarly tested only on the finished product.
Yes, the prototype will be very far from the real result, but respondents will not have any questions: “why the photo is not mine”, “why I clicked on the picture of the sneaker, but a belt appeared”, “why there is no beautiful animation in this window”, “ why the scroll doesn't move ”,“ why are the buttons curves here ”, etc.
Everyone understands that this is paper, and there are no strange questions about its interactivity. Yes, it is not very similar to a finished product, but it allows you to identify huge jambs in functionality, interaction with interactive elements, navigation through interface solutions and screens, and in understanding the meanings of buttons.
Once did a project of a single design of the site of municipal districts. At first, we conducted research in order to understand what can be placed on the site, what is impossible. Then they determined what will be important for visitors and what is not, but according to the law, they must be on the site.
Made prototypes on paper: all screens and windows. And we tested on paper with three participants from our side:
The moderator suggests solving the scenario, leads the respondent, the observer attentively follows the respondent, records his observations and is silent, the “robot” puts the necessary leaves with interfaces, is silent and does not show any emotions (the work of the robot is like this).
At first it seemed to us that the respondents would not understand this kind of prototype. It is difficult to imagine a deputy “clicking” on paper buttons, leafing through paper lists and maps.
But suddenly everything went well. Users clicked the prototype buttons, scrolled the page, navigated through the tabs and searched for information in the search. That is, they really “worked” with a paper prototype. Yes, a bit unusual, but quite a workflow.
The first plus is that you can draw a paper prototype in 3 hours, but to design a prototype in the program is at least a day. And even two. Then you need to insert content, align everything, prepare for testing.
The second plus: if during testing something is not so “working”, on paper it is quickly corrected with a pencil and eraser - and can be tested further. And the Internet is not needed for this.
In addition, people have not been rejected, misunderstanding or negative for such testing. Everything was clear and to the point. We managed to identify a lot of shoals in the navigation and user interaction with the site.
With the help of interactive prototypes it is good to test logic, especially simple, as well as user expectations. Of course, you can take up and difficult navigation, but you have to work with the number and quality of screens. The respondent often does not perceive the interactive prototype as a prototype, so he has to constantly remind about this.
What are such prototypes bad for:
Content in such prototypes should be as close to real as possible.
Such content is poorly perceived by the respondent, who often forgets that this is just a prototype for testing logic, and focuses on content and visual design.
So do not. And why, if it is very easy to find the "fish" on the topic:
It is believed that such prototypes should be made in black and white. Yes and no. Yes, you should not make color accents on the elements you need in an interactive prototype, as this is not true from the point of view of reality, when there will be no such accents. And yet it is not always possible to get by with a black and white prototype. If, for example, an art gallery and an emphasis on paintings are assumed, then it is better to immediately make the prototype look like reality and take the images from the search. So it will be immediately clear what this prototype is and why it is needed.
Interactive prototypes are ideal for testing on the target audience. You can Skype, many prototypes seamlessly share. The user will turn on the screen broadcast, and you can watch his actions.
If it is impossible to find people from Central Asia, and you do not need to check a too complex prototype, do a "corridor testing". Take the simple employees of the company, which are similar to Central Asia. The main thing in this situation is not to take those who perfectly know the whole product or are directly involved in the development.
Not all experts agree with the “corridor” approach, arguing that the sample does not represent the target audience. But I give a grudge, which is better this way than without testing at all: stupid interface errors often emerge that you will never see for anything. Never!
It's all quite simple. The designer makes a beautiful interface in which you mark up the areas, when interacting with which something should happen. This is usually just “on click” or “on move”. You can, of course, pokoldovat with a cutter and cut various elements, but it is too long. Although there are such perfectionists.
All this beauty is made interactive and tested on users: how quickly the color accents you set allow the user to find the right elements. The respondent can speak the actions out loud, and you just need to wait until he makes the desired action. Or do not wait and go cry - if you are a designer. And if you are not a designer, then your task is to send comments to the designer.
We test on target audience, it is possible on Skype. There is a small nuance: we must constantly be reminded that this is a prototype. Constantly! Because such a prototype is too much like reality. By the way, there is no longer any place for meaningless "fish": normal texts, pictures, icons are needed. You can take them from the Internet, just remember about the owners.
If the respondents make unimaginable logical errors, then either the designer made a really bad decision, or you tested the prototype very poorly at the previous stage.
Such testing helps evaluate:
If the user does not notice the desired item or clicks in vain, it means that you need to edit.
Consider that during testing, the UI or graphic designer who did all this should be silent, but it is better to be far away from the respondents. If next, then only with the expression "poker face". It will be difficult for him, he will periodically grab an ax, then a rope with soap, so it’s best to keep him a little away from the design testing process on the user.
Everything works as it should, but for now, instead of 1 billion users, you have 5 people - friends of the project, instead of 5 million SKU base, you still have 1 base for 100 products, and instead of dedicated servers on Amazon, virtual hosting on 1gb.ru. But everything works as it should.
Everything works as it should. This is the main condition!
Now you take the user from the target audience (no need to take programmers from the next room), give him a goal, and let him fulfill it. Everything has to go perfectly. Small bugs that prevent a real user from reaching the goal quickly and efficiently, we write them down, and then we rule.
Once again for those who are cunning. It is necessary to test on target audience! Do not test your product on the workers of the canteen in your office, if Central Asia is the girls from Barvikha Luhari Vilage.
The main thing is that everything works in the same way as in your future supercalculator of dust density of 1 gram of Sahara sand. You can also replace the ready-made solutions that are on the market.
From the side it all looks like an unnecessary expensive hell. But! You want to make a mobile application with complex functionality. This is a minimum of $ 5000 per creation, and for some non-trivial solutions this number can be multiplied by 100.
Decision:
This is the way of Yandex and large companies: to come up with a quick solution, release a beta version, make a pre-release, start up the millionth daily traffic and see how everything works.
Here I will not stop, because this option is unlikely to suit you. Unless you are from a company with a lot of traffic and a team from: UI-designer + quick-typesetter + quick-programmer + quick-BigData-specialist + quick-producer + quick-system. admin + fast-art-dira.
If from such a company, then assemble a team, quickly cut beta, upload to production, allow traffic through links and test hypotheses. If everything is ok, make full versions based on these bets.
Testing a similar product that you already have, or your competitors have, is perfect for those who want to make it “perfect like a competitor”.
Few people use this approach, but this is a really cool thing, especially before any process of redesigning a product, if you already have one. Or you do not, but your main enemy in the market - is.
This requires:
We take what we have, we invite Central Asia for testing (or a Skype session), we look at the screen what the respondent is doing. He spells out actions and thoughts at this time, we write down jambs, compile statistics on errors.
The method is especially recommended for those who think that their functionality is not working well, because the director’s son thinks so (who in 20 years will become a great designer). We test what we have and see the jambs. Real shoals. Everyone, for example, does not care that your site is turquoise, and that the buttons on it are not in Material Design, but with the gradient of the 90s. But all the bugs are noticeable. By the way, this is a very good way to screen out visual perfectionists who don’t like the color of the menu, as well as companies that conduct usability audits by the account manager who went to work a week ago.
It is called "The prototype of various cheap garbage", but is more suitable for industrial design. Used, for example, IDEO. But within the framework of this discussion I will not talk about it, because we are not here about design thinking.
In my work, I constantly use interactive prototypes, including in color. He made paper prototypes several times on real projects and another four times on various intensives and courses. Rather, I design complex elements on paper, but I do not test on it, since this is not particularly often required. However, if time is too close, then there is nothing better than paper. Testing with scripts did once, but this is a long history of creating such a MVP - you need to draw each small screen and the state of the buttons, all of the expanding lists and the execution of certain scripts. Often it spends a lot of time.
Make a conclusion for yourself: whether you should use testing prototypes or not. In any case, this is your decision. You risk not only your own time, but also the company's money.
However, if you do not offer to test the product on prototypes, the manual is unlikely to know about it. Hardly anyone knows at all that one can go through such testing: check early decisions on users and fix the main jambs that 9 out of 10 users will make. Or 7 out of 10. Or just 1 out of 10 - just some 10% of the market.
It is you who make this important decision: reduce the risks of launching a complete “non-usable” something on the market. Do you understand what I mean? If you are afraid and lazy, and this is not your money - you can not do it. Feel free to not do. Because you simply do not have three days to test, but there is half a year to rewrite the outrage that came out without testing. And three days of testing with the participation of three people - this is after all the same thing as six months of work of the team of programmers, right?
So it all depends on you.
In the development process, we often encounter the following dilemma: how to make a product well and quickly, but at the same time interesting and understandable for both users and customers. Nobody wants millions of similar questions to pour out about how it works at all.
')
The recipe is: test the product before entering the market.
Of course, you can test right before the release. Many companies do this: they release “beta”, look at the reaction, collect feedback, then bugs rule. Good practice, but it happens that users do not understand all the main functionality, and not just interface trivia. And it turns out that you need to redraw everything, redo everything. Or write a huge manual for users that no one, other than competing developers, will read.
Therefore, you need to test not at the end of product development, but much earlier, maybe even at the beginning.
Testing the prototype will help to cheat time and eliminate global problems at the very beginning of development.
We always want to avoid testing prototypes, pretending to be a vegetable. Why test, if so “everything is clear”? After all, it will take time to develop a product and add organizational problems — the same selection of people for testing is worth it. And the room needs to be taken somewhere quiet, and still be kind to all respondents, even when they, to put it mildly, are not somewhat oriented in what is happening. It seems that it is possible to cross out this small "episode", save resources, and no one will even notice. And all will be well!
But that doesn't work.
In reality, it is better to spend 30 minutes testing the prototype on users, than to make a design, impose, program, and then find out that you need to redo everything!
Even if the respondents are company employees, the main thing is not the ones responsible for the product design.
There are several time-tested and experienced ways to test a product: starting from the stage when it exists only in the form of sketches, and ending with testing the prototype on users who will think that this is a ready-to-work site, and no prototype at all. Sometimes it is true.
Paper prototype
On paper, it is ideal to test concepts when there is access to a target audience and several people to conduct a study. It is best to test complex scenarios with multiple screens, a million buttons - in general, something that can be similarly tested only on the finished product.
Yes, the prototype will be very far from the real result, but respondents will not have any questions: “why the photo is not mine”, “why I clicked on the picture of the sneaker, but a belt appeared”, “why there is no beautiful animation in this window”, “ why the scroll doesn't move ”,“ why are the buttons curves here ”, etc.
Everyone understands that this is paper, and there are no strange questions about its interactivity. Yes, it is not very similar to a finished product, but it allows you to identify huge jambs in functionality, interaction with interactive elements, navigation through interface solutions and screens, and in understanding the meanings of buttons.
From experience
Once did a project of a single design of the site of municipal districts. At first, we conducted research in order to understand what can be placed on the site, what is impossible. Then they determined what will be important for visitors and what is not, but according to the law, they must be on the site.
Made prototypes on paper: all screens and windows. And we tested on paper with three participants from our side:
- one "robot",
- one moderator,
- one observer.
The moderator suggests solving the scenario, leads the respondent, the observer attentively follows the respondent, records his observations and is silent, the “robot” puts the necessary leaves with interfaces, is silent and does not show any emotions (the work of the robot is like this).
At first it seemed to us that the respondents would not understand this kind of prototype. It is difficult to imagine a deputy “clicking” on paper buttons, leafing through paper lists and maps.
But suddenly everything went well. Users clicked the prototype buttons, scrolled the page, navigated through the tabs and searched for information in the search. That is, they really “worked” with a paper prototype. Yes, a bit unusual, but quite a workflow.
The first plus is that you can draw a paper prototype in 3 hours, but to design a prototype in the program is at least a day. And even two. Then you need to insert content, align everything, prepare for testing.
The second plus: if during testing something is not so “working”, on paper it is quickly corrected with a pencil and eraser - and can be tested further. And the Internet is not needed for this.
In addition, people have not been rejected, misunderstanding or negative for such testing. Everything was clear and to the point. We managed to identify a lot of shoals in the navigation and user interaction with the site.
Interactive prototypes in fine detail
With the help of interactive prototypes it is good to test logic, especially simple, as well as user expectations. Of course, you can take up and difficult navigation, but you have to work with the number and quality of screens. The respondent often does not perceive the interactive prototype as a prototype, so he has to constantly remind about this.
What are such prototypes bad for:
- for testing complex logic with serious scripts and animations;
- for the evaluation of visual design, which does not speak out except that the most lazy respondent.
Content in such prototypes should be as close to real as possible.
In interactive prototypes there should be no Lorem Ipsum, standard images with Axure mountains and crossed out rectangles.
Such content is poorly perceived by the respondent, who often forgets that this is just a prototype for testing logic, and focuses on content and visual design.
So do not. And why, if it is very easy to find the "fish" on the topic:
- take the text on fishtext.ru;
- download pictures from Yandeks.Kartinki;
- put the standard icons Bootstrap;
- place photos of users from search on VKontakte people;
- write the most realistic headers so that later it does not turn out that they do not fit into the width of the screen.
It is believed that such prototypes should be made in black and white. Yes and no. Yes, you should not make color accents on the elements you need in an interactive prototype, as this is not true from the point of view of reality, when there will be no such accents. And yet it is not always possible to get by with a black and white prototype. If, for example, an art gallery and an emphasis on paintings are assumed, then it is better to immediately make the prototype look like reality and take the images from the search. So it will be immediately clear what this prototype is and why it is needed.
Interactive prototypes are ideal for testing on the target audience. You can Skype, many prototypes seamlessly share. The user will turn on the screen broadcast, and you can watch his actions.
If it is impossible to find people from Central Asia, and you do not need to check a too complex prototype, do a "corridor testing". Take the simple employees of the company, which are similar to Central Asia. The main thing in this situation is not to take those who perfectly know the whole product or are directly involved in the development.
Not all experts agree with the “corridor” approach, arguing that the sample does not represent the target audience. But I give a grudge, which is better this way than without testing at all: stupid interface errors often emerge that you will never see for anything. Never!
Testing color prototype in programs like Axure
It's all quite simple. The designer makes a beautiful interface in which you mark up the areas, when interacting with which something should happen. This is usually just “on click” or “on move”. You can, of course, pokoldovat with a cutter and cut various elements, but it is too long. Although there are such perfectionists.
All this beauty is made interactive and tested on users: how quickly the color accents you set allow the user to find the right elements. The respondent can speak the actions out loud, and you just need to wait until he makes the desired action. Or do not wait and go cry - if you are a designer. And if you are not a designer, then your task is to send comments to the designer.
We test on target audience, it is possible on Skype. There is a small nuance: we must constantly be reminded that this is a prototype. Constantly! Because such a prototype is too much like reality. By the way, there is no longer any place for meaningless "fish": normal texts, pictures, icons are needed. You can take them from the Internet, just remember about the owners.
If the respondents make unimaginable logical errors, then either the designer made a really bad decision, or you tested the prototype very poorly at the previous stage.
Such testing helps evaluate:
- how much a specific element that was previously, for example, a large button, and now has become a pretty thin bar, is understandable to the user;
- accents and visibility of all important design elements.
If the user does not notice the desired item or clicks in vain, it means that you need to edit.
Consider that during testing, the UI or graphic designer who did all this should be silent, but it is better to be far away from the respondents. If next, then only with the expression "poker face". It will be difficult for him, he will periodically grab an ax, then a rope with soap, so it’s best to keep him a little away from the design testing process on the user.
Testing with scripts, or MVP testing for alfa-versions of the product
Everything works as it should, but for now, instead of 1 billion users, you have 5 people - friends of the project, instead of 5 million SKU base, you still have 1 base for 100 products, and instead of dedicated servers on Amazon, virtual hosting on 1gb.ru. But everything works as it should.
Everything works as it should. This is the main condition!
Now you take the user from the target audience (no need to take programmers from the next room), give him a goal, and let him fulfill it. Everything has to go perfectly. Small bugs that prevent a real user from reaching the goal quickly and efficiently, we write them down, and then we rule.
Once again for those who are cunning. It is necessary to test on target audience! Do not test your product on the workers of the canteen in your office, if Central Asia is the girls from Barvikha Luhari Vilage.
If you really need to check the complex expensive functionality that develop at least a year, then make a quick decision and check it out.
The main thing is that everything works in the same way as in your future supercalculator of dust density of 1 gram of Sahara sand. You can also replace the ready-made solutions that are on the market.
From the side it all looks like an unnecessary expensive hell. But! You want to make a mobile application with complex functionality. This is a minimum of $ 5000 per creation, and for some non-trivial solutions this number can be multiplied by 100.
Decision:
- make for $ 500 a mobile version of the site with the same functionality;
- check that it works as it should;
- Testing for Central Asia;
- lay out in expensive development. Or do not post - it depends on the result.
Testing for Big Data
This is the way of Yandex and large companies: to come up with a quick solution, release a beta version, make a pre-release, start up the millionth daily traffic and see how everything works.
Here I will not stop, because this option is unlikely to suit you. Unless you are from a company with a lot of traffic and a team from: UI-designer + quick-typesetter + quick-programmer + quick-BigData-specialist + quick-producer + quick-system. admin + fast-art-dira.
If from such a company, then assemble a team, quickly cut beta, upload to production, allow traffic through links and test hypotheses. If everything is ok, make full versions based on these bets.
Testing an existing product
Testing a similar product that you already have, or your competitors have, is perfect for those who want to make it “perfect like a competitor”.
Few people use this approach, but this is a really cool thing, especially before any process of redesigning a product, if you already have one. Or you do not, but your main enemy in the market - is.
This requires:
- website or application
- the target audience;
- usability research;
- personal presence in the habitat of Central Asia or Skype.
We take what we have, we invite Central Asia for testing (or a Skype session), we look at the screen what the respondent is doing. He spells out actions and thoughts at this time, we write down jambs, compile statistics on errors.
The method is especially recommended for those who think that their functionality is not working well, because the director’s son thinks so (who in 20 years will become a great designer). We test what we have and see the jambs. Real shoals. Everyone, for example, does not care that your site is turquoise, and that the buttons on it are not in Material Design, but with the gradient of the 90s. But all the bugs are noticeable. By the way, this is a very good way to screen out visual perfectionists who don’t like the color of the menu, as well as companies that conduct usability audits by the account manager who went to work a week ago.
There is another method ...
It is called "The prototype of various cheap garbage", but is more suitable for industrial design. Used, for example, IDEO. But within the framework of this discussion I will not talk about it, because we are not here about design thinking.
Conclusion
In my work, I constantly use interactive prototypes, including in color. He made paper prototypes several times on real projects and another four times on various intensives and courses. Rather, I design complex elements on paper, but I do not test on it, since this is not particularly often required. However, if time is too close, then there is nothing better than paper. Testing with scripts did once, but this is a long history of creating such a MVP - you need to draw each small screen and the state of the buttons, all of the expanding lists and the execution of certain scripts. Often it spends a lot of time.
Make a conclusion for yourself: whether you should use testing prototypes or not. In any case, this is your decision. You risk not only your own time, but also the company's money.
However, if you do not offer to test the product on prototypes, the manual is unlikely to know about it. Hardly anyone knows at all that one can go through such testing: check early decisions on users and fix the main jambs that 9 out of 10 users will make. Or 7 out of 10. Or just 1 out of 10 - just some 10% of the market.
It is you who make this important decision: reduce the risks of launching a complete “non-usable” something on the market. Do you understand what I mean? If you are afraid and lazy, and this is not your money - you can not do it. Feel free to not do. Because you simply do not have three days to test, but there is half a year to rewrite the outrage that came out without testing. And three days of testing with the participation of three people - this is after all the same thing as six months of work of the team of programmers, right?
So it all depends on you.
Netology conducts a set of courses:
- Interface design: UI-UX design from strategy to testing ;
- UX analytics: user research and common sense ;
- Mobile application design: interfaces, architecture, visual concept ;
- Adobe XD: the basics for the interface designer (freeware);
- The course of Python: programming for every day and ultra-fast prototyping .
Source: https://habr.com/ru/post/334694/
All Articles