Bureaucrats, emailconfirmed
1,221
edits
no edit summary
(Testing) |
No edit summary |
||
| Line 101: | Line 101: | ||
[[File:UndoRedo.png|thumb|undo-redo-buttons]] | [[File:UndoRedo.png|thumb|undo-redo-buttons]] | ||
You should as well prevent that the user selects data-destroying functions by accident. E.g. putting the "save" and the "close" entry close to each other in a menu will cause data loss: if the user wants to save, he may press "no" after a | You should as well prevent that the user selects data-destroying functions by accident. E.g. putting the "save" and the "close" entry close to each other in a menu will cause data loss: if the user wants to save, he may press "no" after a dialogue window appears: "don't bother me now. I want to save my data!" - and the data is lost, "close" was selected by accident and the dialog-window that was dismissed by choosing "no" was the final warning. | ||
Even if you prevent accidental actions the users data is not save. Users may misunderstand the name of an action or just try out what the result will look like. Therefore you should provide an undo-facility. This means the user can do an action and if it turns out that this has been a bad idea it can be undone. This is a great feature that demands a bit of thinking when the code is written but it is worth it. As a side effect your application becomes more learnable as well: users are able to learn by doing without any worries. | Even if you prevent accidental actions the users data is not save. Users may misunderstand the name of an action or just try out what the result will look like. Therefore you should provide an undo-facility. This means the user can do an action and if it turns out that this has been a bad idea it can be undone. This is a great feature that demands a bit of thinking when the code is written but it is worth it. As a side effect your application becomes more learnable as well: users are able to learn by doing without any worries. | ||
| Line 116: | Line 116: | ||
Well, when I think about products for everybody I think of facebook for example. It has a vast number of users so this is enough "everybody" for a beginning interaction designer I think. Though strangely, Facebook started with a very restricted target group: Students of the Harvard University. Slowly and controlled it was opened to more people. First Students of other elite US universities ("Ivy League"). Than all other US universities. Than Highschool students, employees of several big companys and finally it was open for everybody. I don't want to put them on a pedestal for great interaction design. I just want to illustrate that they are successful and did not "desgin for everybody". | Well, when I think about products for everybody I think of facebook for example. It has a vast number of users so this is enough "everybody" for a beginning interaction designer I think. Though strangely, Facebook started with a very restricted target group: Students of the Harvard University. Slowly and controlled it was opened to more people. First Students of other elite US universities ("Ivy League"). Than all other US universities. Than Highschool students, employees of several big companys and finally it was open for everybody. I don't want to put them on a pedestal for great interaction design. I just want to illustrate that they are successful and did not "desgin for everybody". | ||
What this illustrates as well is that it is always easier to add features. Removing them if you note that they don't help you is very hard. You can do so but nobody likes it. What if a function that you particularly use would disappears after an upgrade of your | What this illustrates as well is that it is always easier to add features. Removing them if you note that they don't help you is very hard. You can do so but nobody likes it. What if a function that you particularly use would disappears after an upgrade of your favourite software? People suffer incredibly if you take something away, even if the most of them would be better of it what they had would have never existing anyway. Strange, but that's the way it is. | ||
If you release a successful 1.0 Product you can still extend it in the 2.0 version even with features that are not very-super-crucial. But I write this to help you to release a successful 1.0 version so I did put emphasis on the simplicity. | If you release a successful 1.0 Product you can still extend it in the 2.0 version even with features that are not very-super-crucial. But I write this to help you to release a successful 1.0 version so I did put emphasis on the simplicity. | ||
| Line 122: | Line 122: | ||
<!-- | <!-- | ||
=Research= | =Research= | ||
The research is the | The research is the preparation for the actual design process. Doing research will help you to design for what the users want to archive and to avoid common problems. It is also likely that some other people did work you can build on. This can save you a lot of time and pondering. | ||
It is useful to do research on | It is useful to do research on | ||
| Line 212: | Line 212: | ||
Prototypes are easy to make (especially compared to the final product) and don't waste resources if an idea does not work. Ideas that don't work get sorted out and you can try something new. Because it does not hurt to be wrong you can be creative and find new ways of doing things. | Prototypes are easy to make (especially compared to the final product) and don't waste resources if an idea does not work. Ideas that don't work get sorted out and you can try something new. Because it does not hurt to be wrong you can be creative and find new ways of doing things. | ||
==Getting people | |||
==getting people== | |||
Getting people for your testing will be similar to the interview process. It is generally easier to tell the people what you actually want from them: "try out stuff" sounds more graspable than "being interviewed about... stuff" | |||
Similar to the interviews as well is that you can do a person-to-person testing using any prototyping technique. In this case you need to ask friends, fellow students etc. to recruit people. | |||
If you have a coded prototype you can acquire participants via your blog, twitter, facebook or mailing list as well and do the testing remotely via screensharing. This can make it easier to find participants especially if you work as part of a open source project that is mainly working in collaboration via the web. | |||
To have meaningful testing results you should recruit people belonging to your targeted user group. Some products have a big user group: a TV-remote-control can be used by all sorts of people so gather a diverse group. But if your product is a source code editor you should recruit developers. | |||
==Choosing a task== | ==Choosing a task== | ||
So what shall your Testers do with the Prototype? You need to give them some tasks they are going to do. So you should follow some simple steps: | |||
* Write down typical tasks one can resolve using your product. This is a little brainstorming. | |||
* Out of the tasks you wrote down you choose the ones that you feel are typical for your software and crucial for using it. | |||
'''Write the tasks''' | |||
* You need to think about a suitable context for your tasks. So don't just write: "import the pictures from the SD card into the Program" but something like "You are a Photographer and just finished shooting. Please import the pictures into the program for doing further work with them" | |||
* 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. | |||
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 programm" | |||
* Use language that is easy to understand. If the task's description is not comprehensible nobody can test. | |||
==Writing a scenario== | ==Writing a scenario== | ||
==Build a Prototype== | ==Build a Prototype== | ||