Bureaucrats, emailconfirmed
1,221
edits
IFD:Course Interaction Design (view source)
Revision as of 11:22, 14 November 2010
, 14 November 2010→Get to know if your ideas work!
| Line 413: | Line 413: | ||
==Get to know if your ideas work!== | ==Get to know if your ideas work!== | ||
===User Interface Design Heuristics=== | <!-- ===User Interface Design Heuristics=== | ||
Heuristics are "rules of thumb" derived from experiences that are used to solve problems efficiently. The rules are no guarantee to get an optimal or even a good solution but in the most cases heuristics work good and especially fast. | Heuristics are "rules of thumb" derived from experiences that are used to solve problems efficiently. The rules are no guarantee to get an optimal or even a good solution but in the most cases heuristics work good and especially fast. | ||
| Line 429: | Line 429: | ||
# '''Aesthetic and minimalist design:''' Let form follow function and dont add visual clutter by over-advanced visual design. | # '''Aesthetic and minimalist design:''' Let form follow function and dont add visual clutter by over-advanced visual design. | ||
# '''Help users recognize, diagnose, and recover from errors:''' In case an Error cant be prevented or handled by the application itself, the error message should state problem and possible solutions in plain, non-technical terms. | # '''Help users recognize, diagnose, and recover from errors:''' In case an Error cant be prevented or handled by the application itself, the error message should state problem and possible solutions in plain, non-technical terms. | ||
# '''Help and documentation:''' It is good if no help is needed to learn the program but some questions will appear, so provide searchable, easy to access information how to use the product | # '''Help and documentation:''' It is good if no help is needed to learn the program but some questions will appear, so provide searchable, easy to access information how to use the product--> | ||
===Introduction to prototypes=== | ===Introduction to prototypes=== | ||
| Line 462: | Line 462: | ||
====Coded Prototyping==== | ====Coded Prototyping==== | ||
=== | ===Brief Observers=== | ||
===Brief Participants=== | |||
Now, as you are finished building the prototype you need, you can finally do the actual test! | Now, as you are finished building the prototype you need, you can finally do the actual test! | ||
| Line 475: | Line 476: | ||
After this introduction the test can start. Tell the participants the task, or better, hand them a paper with the task and the context scenario. | After this introduction the test can start. Tell the participants the task, or better, hand them a paper with the task and the context scenario. | ||
===Conducting the actual test=== | |||
While the user does the task you write down your notes. Its not that easy to write, keep your eyes on the screen and listen to the users thinking-aloud – but you will get used to it. | While the user does the task you write down your notes. Its not that easy to write, keep your eyes on the screen and listen to the users thinking-aloud – but you will get used to it. | ||
| Line 485: | Line 487: | ||
===Formulate your findings=== | ===Formulate your findings=== | ||
After the | After the testing you will have a bunch of protocols. You review them to see how you can improve your product. So have a look where people got stuck or where they thought about a feature, menu entry et. differently than you expected. | ||
If you are in an early phase of your project you probably need to decide about very basic things e.g. if your users understand a new way of approaching a common task. In this case you need to decide which of some solutions you will choose. If you hear or see anything | If you are in an early phase of your project you probably need to decide about very basic things e.g. if your users understand a new way of approaching a common task. In this case you need to decide which of some solutions you will choose. If you hear or see anything interesting and/or inspiring, write it down, because it can help you in your further design process. | ||
In latter stages of your project | In latter stages of your project testing will serve more the purpose of improvement: evolution. not revolution. So it is the best to write an organized list of the problems that you observed and that need to be fixed.Order your findings after priority: Problems that could prevent an essential step from happening are important to resolve.(e.g. importing a picture into a photo-organizing application or changing the channel on a TV) Watch out for patterns – some problems will occur over and over again and should have as well a high priority in resolving them. | ||
===Improving your Product=== | ===Improving your Product=== | ||
Having a list with what causes the user problems you know can refine your work. In early | Having a list with what causes the user problems you know can refine your work. In early stages you will have seen which of some different ways will be dismissed and which will be further explored. | ||
In later phases of your project you will have a list with ranked problems that need to be resolved. Start with the ones you consider the most serious and solve the problems. In doing so you often can build on the think-aloud-protocol you wrote. It give insight in the way the users think about the actions they took and about the responses of the software. This will help you to find a decent solution that will work better. | In later phases of your project you will have a list with ranked problems that need to be resolved. Start with the ones you consider the most serious and solve the problems. In doing so you often can build on the think-aloud-protocol you wrote. It give insight in the way the users think about the actions they took and about the responses of the software. This will help you to find a decent solution that will work better. | ||
[[Category:Design]] | [[Category:Design]] | ||
[[Category:Courses]] | [[Category:Courses]] | ||