Bureaucrats, emailconfirmed
1,221
edits
no edit summary
No edit summary |
No edit summary |
||
| Line 334: | Line 334: | ||
When testing with a prototype you give test participants a task to solve. A prototype needs to simulate the situations that can occur when the participants do the task you gave them. So at least you need to cover the possibilities to resolve the task. | When testing with a prototype you give test participants a task to solve. A prototype needs to simulate the situations that can occur when the participants do the task you gave them. So at least you need to cover the possibilities to resolve the task. | ||
[[File:PaperPrototyping_Zeug.jpg|right|200px|thumb|A paper prototype consists of Paper or Cardboard pieces and a few additional materials]] | |||
I recommend to build your prototype in paper. It may sound strange but it is easily done, costs almost nothing and usually has good results. The interaction is simulated by manually changing parts of the paper-Interface. E.g. You draw a dialogue box on paper and place it over the rest of the interface if the user triggers the action that shall make it appear. Or if a "link" is clicked you change all parts of the site that are supposed to be different from the old one. | I recommend to build your prototype in paper. It may sound strange but it is easily done, costs almost nothing and usually has good results. The interaction is simulated by manually changing parts of the paper-Interface. E.g. You draw a dialogue box on paper and place it over the rest of the interface if the user triggers the action that shall make it appear. Or if a "link" is clicked you change all parts of the site that are supposed to be different from the old one. | ||
| Line 355: | Line 357: | ||
The users interacts with the paper-prototype by using their fingers like the mouse cursor: If they tap an element this has the results of a mouse click, and the computer changes the interface accordingly. If you have special input modes e.g. right click you can tell the user that this can be told to the computer ("now I right-click") If you need text input you should give the user the possibility for text input via a non-permanent-marker. | The users interacts with the paper-prototype by using their fingers like the mouse cursor: If they tap an element this has the results of a mouse click, and the computer changes the interface accordingly. If you have special input modes e.g. right click you can tell the user that this can be told to the computer ("now I right-click") If you need text input you should give the user the possibility for text input via a non-permanent-marker. | ||
====Ressources==== | |||
* A List Apart on [http://www.alistapart.com/articles/paperprototyping/ paper-prototyping] | |||
* Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder. ISBN 978-1558608702 | |||
==Get to know if your ideas work!== | ==Get to know if your ideas work!== | ||
| Line 375: | Line 380: | ||
* It needs to be clear when a task is finished. So don't write any open ended tasks but one that have a clear goal and condition one needs to reach. <br> E.g. the example above could be improved by changing the end to "Please import the pictures into the program, so that you can see the images thumbnails in the program" | * It needs to be clear when a task is finished. So don't write any open ended tasks but one that have a clear goal and condition one needs to reach. <br> E.g. the example above could be improved by changing the end to "Please import the pictures into the program, so that you can see the images thumbnails in the program" | ||
* Use language that is easy to understand. If the task's description is not comprehensible, nobody can test. | * Use language that is easy to understand. If the task's description is not comprehensible, nobody can test. | ||
| Line 428: | Line 423: | ||
* If the user does anything and you have the urgent feeling that you should show the right way: don't do so. It will spoil what you actually want to know: where problems occur and how the user deals with them. | * If the user does anything and you have the urgent feeling that you should show the right way: don't do so. It will spoil what you actually want to know: where problems occur and how the user deals with them. | ||
You will facilitate the test and interact with the user - while not altering the user's | You will facilitate the test and interact with the user - while not altering the user's behavior as well: | ||
* If the user asks you questions about solving the task like "is this right?" or "can I..." just answer: What you like" or "What would you do if I were not here?" | * If the user asks you questions about solving the task like "is this right?" or "can I..." just answer: What you like" or "What would you do if I were not here?" | ||
* If the user really gets stuck you can gradually help. First with something with ''"where do you think could the [whatever] function be?"'' if this not helps in any way you can point to the solution so you can move further: '' "what do you think does this button do?" '' | * If the user really gets stuck you can gradually help. First with something with ''"where do you think could the [whatever] function be?"'' if this not helps in any way you can point to the solution so you can move further: '' "what do you think does this button do?" '' | ||