Bureaucrats, emailconfirmed
1,221
edits
→Explore your idea
| (21 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
Licence: | Licence: | ||
This | This text is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported. | ||
[http://creativecommons.org/licenses/by-sa/3.0/ http://i.creativecommons.org/l/by-sa/3.0/88x31.png] | [http://creativecommons.org/licenses/by-sa/3.0/ http://i.creativecommons.org/l/by-sa/3.0/88x31.png] | ||
| Line 22: | Line 22: | ||
'''goals:''' This guide is aimed at students who want to develop new products, services, software or websites. We cover the whole interaction design process in a brief and understandable way and enable students to understand the most important terms so that they can read the literature. | '''goals:''' This guide is aimed at students who want to develop new products, services, software or websites. We cover the whole interaction design process in a brief and understandable way and enable students to understand the most important terms so that they can read the literature. | ||
'''No-Goals:''' Include material that is non-relevant for practical work or can be only applied in project in bigger teams or with reasonable funding. (thats the reason for not having e.g. [ | '''No-Goals:''' Include material that is non-relevant for practical work or can be only applied in project in bigger teams or with reasonable funding. (thats the reason for not having e.g. [[wikipedia:Persona (marketing)|personas]] in here) | ||
==Introduction== | ==Introduction== | ||
| Line 98: | Line 98: | ||
In the beginning of your project your main activity will be doing user research and getting to know the goals and problems of your users. Later on you will probably solve more specific problems and use more books and online resources to solve these problems. | In the beginning of your project your main activity will be doing user research and getting to know the goals and problems of your users. Later on you will probably solve more specific problems and use more books and online resources to solve these problems. | ||
===Familiarize yourself with the domain=== | |||
You do research to get to know about activities, problems and motivations of people who will usually work in another field like you do (it is unlikely that you will do user research on other user researchers). The work of e.g. a statistical analyst demands specific terms (e.g. "significance tests") and has specific tools ("ANOVA"). | |||
It is a good idea to get an overview of the field before collecting data. It will not only help you to understand better what people are telling you, furthermore, you can set yourself more specific goals on what you want to find out and check, if your research idea makes sense (e.g. you could get the conclusion that what you actually want to find out might be better determined by sampling another group of people and not the one you first expected) | |||
This preliminary research should not prevent you from asking questions, even if you read what might be answered in a book. What the pre-research in books or wikipedia articles yields, is a idealized, often rather abstract description. It is good to know these ideas and procedures. However, they are often applied very differently in the real world and a term which is well defined in the book may mean something different to the people you work with. So you should ask if a term or a process is mentioned what it actually means. As a outsider this is o.k. (''they'' are experts in their field) – and often are happy to explain their practices regarding a term, problem or method. | |||
===User Goals/User Motivations=== | ===User Goals/User Motivations=== | ||
<!-- Here we actually need some sort of "Framework: What is importatnt for users?--> | |||
Talking about design you often hear things like that you should improve the x function because users are assumed to want y. This is common and it is common as well that these assumptions are wrong. And even if they are right you should know ''why''' the user wants to use a certain function. Nobody does anything just to execute a program on a computer to keep the machine busy! | Talking about design you often hear things like that you should improve the x function because users are assumed to want y. This is common and it is common as well that these assumptions are wrong. And even if they are right you should know ''why''' the user wants to use a certain function. Nobody does anything just to execute a program on a computer to keep the machine busy! | ||
| Line 109: | Line 117: | ||
What the goals of your users are is best to find out using research methods like interviews. Goals are hard to guess. You may not even always be aware of why exactly ''you'' do something - and it is even harder to tell what drives other people. Especially if you are new to a field you should use research but even people who think they are experts are often wrong about the users goals. Don't try to guess harder. You want to know. | What the goals of your users are is best to find out using research methods like interviews. Goals are hard to guess. You may not even always be aware of why exactly ''you'' do something - and it is even harder to tell what drives other people. Especially if you are new to a field you should use research but even people who think they are experts are often wrong about the users goals. Don't try to guess harder. You want to know. | ||
=== | ===Ask and Observe === | ||
A very useful tool for doing research | <!-- We need a more thorough structure and introduction here | ||
A very useful tool for doing research is combining observation with asking questions. | |||
They are best done early in the design process and will help you to find out for which user needs you design and what problems need to be solved. Interviews are not difficult to do, very versatile and you will get a lot of insight. | They are best done early in the design process and will help you to find out for which user needs you design and what problems need to be solved. Interviews are not difficult to do, very versatile and you will get a lot of insight. | ||
====Recruit users==== | ====Recruit users==== | ||
You want to | <!-- that should come *after the user understood what intervies are good for--> | ||
You want to find out about potential users of your future product, so you need to see who could use it. Than you try to get these people to an interview. | |||
You can use a couple of ways to contact these potential users: Use your universities Mailing List, ask friends of friends. As you can do the interviews via skype as well, you can state that you search for interviewees on your twitter-page or blog. (Remember: you don't search for everybody, so state for which people you are looking for) State what you are going to do and what it is for. As a student you have probably no money you can offer as compensation. | You can use a couple of ways to contact these potential users: Use your universities Mailing List, ask friends of friends. As you can do the interviews via skype as well, you can state that you search for interviewees on your twitter-page or blog. (Remember: you don't search for everybody, so state for which people you are looking for) State what you are going to do and what it is for. As a student you have probably no money you can offer as compensation. | ||
| Line 119: | Line 130: | ||
Using interviews we want to find out about | Using interviews we want to find out about | ||
* User goals and motivations | * User goals and motivations | ||
* | * Their Actions and the reasons for doing them | ||
* Which Problems exist currently in doing so | * Which Problems exist currently in doing so | ||
====Mind the context==== | ====Mind the context==== | ||
[[File: | [[File:Typicalbusyoffice20050109 PublicDomain WikipediaUser-AlainV.jpg|200px|thumb|the place where the user interacts with the product conveys useful information]] | ||
The interview should be done where the interaction happens. This gives you the possibility to observe the workflow and the user interacting with a current product that he uses currently to archive his goals. You can as well watch out which cues the environment provides e.g. how documents are organized on the table, what is on the sticky notes at the monitor etc. In your questions you can refer to these things like "why do you..." or "how does... work?" | The interview should be done where the interaction happens. This gives you the possibility to observe the workflow and the user interacting with a current product that he uses currently to archive his goals. You can as well watch out which cues the environment provides e.g. how documents are organized on the table, what is on the sticky notes at the monitor etc. In your questions you can refer to these things like "why do you..." or "how does... work?" | ||
====Record the interview==== | |||
You need some way to record what the interviewee is saying and doing in order to ananayse the data later. A common way is to take notes of what is said and done. But writng down everything said during the interview can be distracting for you as well as for the interviewee. If you need to do the interview alone audio-record the interview and take notes of what you find striking and of anything that can't be recorded on audio. (For example a certain movement or an arrangement of items) | |||
If two people can do the interview you can split into an interviewer and a note-taker. So one can fully concentrate on recording and one on the interview itself. Tell the interviewee clearly who is doing the interviewing so the interviewee knows to whom he/she is talking to. The note taker will stay mostly silent. | |||
It is important to tell the interviewee how you record the interview – especially if you do an audio recording of it. Get their consent befor you start and treat the recordings as confidential. | |||
====Interview Process==== | ====Interview Process==== | ||
Before you start tell briefly again what the interviews are for. Some people may feel kind of "tested" on computer literacy or something like that. Tell them they don't need to worry and that hearing about problems will help you as much as anything else. | Before you start tell briefly again what the interviews are for. Some people may feel kind of "tested" on computer literacy or something like that. Tell them they don't need to worry and that hearing about problems will help you as much as anything else. | ||
[[File: | [[File:Notetaking Flickr-CreditTo kristin wolff.jpg|200px|thumb|take notes during your interviews]] | ||
The interview should be pleasant for the interviewee, so don't stretch it too long. Being a attentively and a good listener will help as well. | The interview should be pleasant for the interviewee, so don't stretch it too long. Being a attentively and a good listener will help as well. | ||
The first steps are the most difficult but once the interviewee talks it usually runs smooth.So it is a good idea to start with some questions that are useful for you to know and have clear and simple answers like the profession, years of experience etc. | The first steps are the most difficult but once the interviewee talks it usually runs smooth.So it is a good idea to start with some questions that are useful for you to know and have clear and simple answers like the profession, years of experience etc. | ||
====Ask the right questions==== | ====Ask the right questions==== | ||
| Line 149: | Line 168: | ||
#'''The Interviewee demands a specific feature'''<br>Interviewee answer: '''"Well... You just need to put a red button here!"''' <br>Users don't know what would make a design that is good to use for everybody. We don't know either for sure, so we do research!<br>Solution:''"How would the red button help you?"''<br><br> | #'''The Interviewee demands a specific feature'''<br>Interviewee answer: '''"Well... You just need to put a red button here!"''' <br>Users don't know what would make a design that is good to use for everybody. We don't know either for sure, so we do research!<br>Solution:''"How would the red button help you?"''<br><br> | ||
#'''You want to know if something you have in mind would help the user'''<br>You: '''"Would it help you to have a green lever that does [whatsoever]?"'''<br>Here you make the user a designer. This is similar to the situation above. <br>Solution:Don't ask this question! In a latter section you will read about testing and prototyping such ideas. If you want to gather information on the specific feature in the interview nevertheless: gather informations about the user and his/her context that could reveal if the user needs the feature that you have in mind. | #'''You want to know if something you have in mind would help the user'''<br>You: '''"Would it help you to have a green lever that does [whatsoever]?"'''<br>Here you make the user a designer. This is similar to the situation above. <br>Solution:Don't ask this question! In a latter section you will read about testing and prototyping such ideas. If you want to gather information on the specific feature in the interview nevertheless: gather informations about the user and his/her context that could reveal if the user needs the feature that you have in mind. | ||
=====Ressources===== | |||
[http://de.wikipedia.org/wiki/Fragetechnik Fragetechnik, Wikipedia] (roughly:"Question Practices"), deutsche Wikpedia – Übersicht über mögliche Fragedimensionen und -Arten | Overview of possible kinds of questions and question dimensions. | |||
===Analysis=== | |||
''„The greatest challenge to any thinker is stating the problem in a way that will allow a solution.“'' – Bertrand Russell | |||
To make sense of the interviews you should analyse them. Although the interviews itself can provide a great help for creating empathy with the user and find the most common problems an analysis can show you the patterns in the data, hidden connections and things you oversaw earlier. | |||
When you are finished with the interviews you will have a lot of data on paper and possibly in audio files as well. I will show a way to structure your data in a process which is called "Affinity Diagramming". This Process is taken out of "Contextual Design: Defining Customer-Centered Systems" by Hugh Beyer and Karen Holtzblatt, but we use an easy and especially more rapid to do version of it. It consists of writing down small pieces of information on sticky notes and arranging them into a meaningful pattern. This is not a hard-science-method and there is no "one true finding" you will get. Nevertheless, so called "qualitative analysis" techniques are common in the social sciences too. (e.g. the so called "Grounded Theory") | |||
====Write Notes==== | |||
You will gather your findings by going through the interview recordings. It is recommanded to do this with somebody else in order to balace out personal biases. (In similar methods like contextual design you even use a whole team to do this) | |||
What goes on the notes? A Note carries a so called "singular finding" or simple statment that can stand on its own. (It needs to fit on a note, right?) Such statements can be: | |||
* "The first thing I did today is to check the mails" | |||
* "It annoyed me that I needed to call a technican. They make me feel silly" | |||
* "The work piled up sice the machine was down. This caused a lot of disstress" | |||
* "I love the 'clip' function. It saved me a lot of switching between applications" | |||
Despite of the "singular finding" principle notes can and should contain a reason for an action or its result, as you see in the examples above. Compare "I needed to call a technican" with "I needed to call a technican. They make me feel silly". While the former is just something that is done, the latter helps us to understand the situation. | |||
Everytime one of you finds a statement he/she consideres as important wirte it down. (You will get around 40-80 Notes for a 45min Interview) | |||
To each note write as well a "user code", so the first user you interviewd gets U1, the second U2 etc. So you can ensure anonymity for the interviewes while being able to still distinguish them. | |||
Write the statements on Notes (There are larger sticky note that have the right size to do so) or write them in a Spreadsheet and print the notes later. In the latter case you will need some restickable glue to turn your printouts into sticky notes. | |||
====Create Meaning==== | |||
The goal of this step is to create a structure in which you have your notes grouped at the lowest level. For these groups you will write notes that summerize the groups meaning and you will group these groups again and again write a short summary. | |||
[[File:Affinity Diagramming 1.png|200px|thumb|early in the Affinity Diagramming process]] | |||
[[File:Affinity Diagramming 2.png|200px|thumb|...and later on]] | |||
You can do the process alone or better in a team (2 to 6 People), after you introduced the process to them. If the team is not yet familiar with the method, one note at the time. Once they understood the method you can work simultaneously. | |||
Decide for each note where it can go and group notes together when they share a similar principle or meaning. Resist of putting all notes with the same things mentioned together like "All about mail" or "The Kitchen". Rather try to find the pattern behind the mere content. For example, Notes like "I needed to hurry, the meeting was in 5 minutes" and "the machine takes always way to long to brew the coffee" could possible go under the principle "time pressure" though they don't mention the same things. | |||
The grouping process will require restructuring as well. Don't stick to the groups you created– if you or somebody else needs to rearrange them or take notes out of them and put them somewhere else that's fine. | |||
After you created groups of 2–5 Notes find suitable descriptions for the group and write them sticky notes in a color different from the one you already use. With these groups you will go through the same process of group creation again, now rearranging whole note-groups. This is not as cumbersome as it sounds especially since similar groups often tend to be close to each other anyway. | |||
For these top-groups again write descriptive notes. | |||
<!-- | |||
State findings, Create Goals based on the analysis. | |||
--> | |||
<!--- | |||
====Write your findings down:==== | ====Write your findings down:==== | ||
Take some time to do the review and gather all your notes or recordings. Read or listen through them. Remember, we want to find out about user goals and existing problems. Write what you consider as important down. Now you should get an overview by grouping the findings. Some will occur more often or add up to a kind of problem field. | Take some time to do the review and gather all your notes or recordings. Read or listen through them. Remember, we want to find out about user goals and existing problems. Write what you consider as important down. Now you should get an overview by grouping the findings. Some will occur more often or add up to a kind of problem field. | ||
After doing so you should try to put your key findings in a few short sentences. An example is: ''"The goals of our potential users to participate in a design challenge is to improve their CVs and to get known.'' | After doing so you should try to put your key findings in a few short sentences. An example is: ''"The goals of our potential users to participate in a design challenge is to improve their CVs and to get known.'' | ||
Write down common problems as well so you know which traps to avoid and where new solutions are needed. | Write down common problems as well so you know which traps to avoid and where new solutions are needed. | ||
These key findings will guide you when you create your designs, because you now know what you need to concentrate on. | These key findings will guide you when you create your designs, because you now know what you need to concentrate on. --> | ||
====Ressources==== | ====Ressources==== | ||
* ''Observing the User Experience (Kuniavsky) beschreibt Interviewing und Affinity Diagramming. | |||
* Die vorgestellten Methoden gehören zur "qualitativen Forschung". Mehr dazu in ''Qualitative Sozialforschung: Ein Arbeitsbuch (Przyborski, Wohlrab-Sahr)'' | |||
* [http://incontextdesign.com/articles/helpful-tips-to-improve-your-contextual-inquiry-techniques/ tips for a very similar technique called 'contextual inquiry'] | * [http://incontextdesign.com/articles/helpful-tips-to-improve-your-contextual-inquiry-techniques/ tips for a very similar technique called 'contextual inquiry'] | ||
* [http://www.adaptivepath.com/ideas/essays/archives/000041.php great tips for your questions] | * [http://www.adaptivepath.com/ideas/essays/archives/000041.php great tips for your questions] | ||
| Line 201: | Line 271: | ||
==Basics of Psychology== | ==Basics of Psychology== | ||
Interaction Design is influenced by psychology. No wonder - we are dealing with creating things that are used because of the [ | Interaction Design is influenced by psychology. No wonder - we are dealing with creating things that are used because of the [[wikipedia:motivation]]s of the users and are easy to use because it matches the way they [[wikipedia:Cognitive science|think]]. | ||
<!-- | <!-- | ||
===Memory=== | ===Memory=== | ||
| Line 216: | Line 286: | ||
===Mental Models=== | ===Mental Models=== | ||
[[File: | [[File:Honeywell round thermostat.jpg|200px|thumb|thermostat]] | ||
[[File:Warmwasserheizung.jpg|200px|thumb|This works like you think]] | [[File:Warmwasserheizung.jpg|200px|thumb|This works like you think]] | ||
The way real world things work is represented in our mind as a so-called mental model. The whole world with all its properties can't get in our mind. It would be too much data and what we perceive is heavily filtered anyway by our senses. | The way real world things work is represented in our mind as a so-called mental model. The whole world with all its properties can't get in our mind. It would be too much data and what we perceive is heavily filtered anyway by our senses. | ||
| Line 229: | Line 299: | ||
If you are the engineer who build these systems it is totally clear for you how they work. As well it will be often the case that your mental model is differs from the one the users have. This itself is nothing to worry about and it happens all the time. But even if you are very clever you just can spot the problems that it can cause if you test your ideas with your users and see if they act like you intended. | If you are the engineer who build these systems it is totally clear for you how they work. As well it will be often the case that your mental model is differs from the one the users have. This itself is nothing to worry about and it happens all the time. But even if you are very clever you just can spot the problems that it can cause if you test your ideas with your users and see if they act like you intended. | ||
====Ressources==== | ====Ressources==== | ||
* More on [ | * More on [[wikipedia:Mental model]]. | ||
==Basic Principles& Best Practices== | ==Basic Principles& Best Practices== | ||
| Line 242: | Line 312: | ||
* '''The Desktop: ''' A classic Metaphor. Like in you real desktop you can put documents you currently deal with, on your desktop and organize your workspace. Many aspects of a real world desktop were not transferred for good reasons. The recycling bin e.g. is usually not seen on top of your real world desktop. But it is pretty useful that it is on your computer's desktop. | * '''The Desktop: ''' A classic Metaphor. Like in you real desktop you can put documents you currently deal with, on your desktop and organize your workspace. Many aspects of a real world desktop were not transferred for good reasons. The recycling bin e.g. is usually not seen on top of your real world desktop. But it is pretty useful that it is on your computer's desktop. | ||
[[File: | [[File:Tools GIMP.png|thumb]] | ||
*'''Tools: '''<br> You hardly notice this metaphor. Its pretty good. We use tools all the time in our real life and we easyly know how to use the tools on the toolbar in our image editing program: The eraser deletes stuff, the brush paints with color etc. | *'''Tools: '''<br> You hardly notice this metaphor. Its pretty good. We use tools all the time in our real life and we easyly know how to use the tools on the toolbar in our image editing program: The eraser deletes stuff, the brush paints with color etc. | ||
| Line 252: | Line 322: | ||
===Standards and Consistency=== | ===Standards and Consistency=== | ||
[[File:DialogBox- | [[File:DialogBox-standards openSource.png|thumb|200px|Some Standards you can see here:A Bar on top you can drag the window with; A cross in the corner that closes the window; Buttons with descriptive Text triggering functions - and the whole dialog is a standard in itself because it always appears when one closes an application without prior saving]] | ||
In contrast to metaphors, Standards have been learned at some point. You learned that you can move a window dragging it on its title-bar, that clicking on a button triggers an action an that you find "save" and "open" in the file menu. | In contrast to metaphors, Standards have been learned at some point. You learned that you can move a window dragging it on its title-bar, that clicking on a button triggers an action an that you find "save" and "open" in the file menu. | ||
Like metaphors standards ease learning because you can build on something the user already knows - as it is a standard you can assume that applications the user used before taught him how to interact. | Like metaphors standards ease learning because you can build on something the user already knows - as it is a standard you can assume that applications the user used before taught him how to interact. | ||
| Line 266: | Line 336: | ||
The last example illustrates as well, that many standards are metaphors we agree on. We could do many things differently but if we would e.g. rename "folders" to "boxes" we would break the standard, and users would need to relearn what "boxes" are. Standards are crucial - if each application would invent their own ways of doing things users need to relearn all the time. There are styleguides for applications made by the people who create the operating system or desktop to help programmers and designers to use the standards the most people agree on. | The last example illustrates as well, that many standards are metaphors we agree on. We could do many things differently but if we would e.g. rename "folders" to "boxes" we would break the standard, and users would need to relearn what "boxes" are. Standards are crucial - if each application would invent their own ways of doing things users need to relearn all the time. There are styleguides for applications made by the people who create the operating system or desktop to help programmers and designers to use the standards the most people agree on. | ||
[[File: | [[File:Radio button WRONG.png|thumb|Radio Buttons are used for selecting when just one of the alternatives can be chosen. What is depicted turns a standard element into something else though it looks the same.]] | ||
| Line 287: | Line 357: | ||
* [http://www.useit.com/alertbox/990822.html Do Interface Standards Stifle Design Creativity?] | * [http://www.useit.com/alertbox/990822.html Do Interface Standards Stifle Design Creativity?] | ||
*Example Interface Guidelines by [http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html Apple] and [http://library.gnome.org/devel/hig-book/stable/ Gnome] | *Example Interface Guidelines by [http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html Apple] and [http://library.gnome.org/devel/hig-book/stable/ Gnome] | ||
* Jef Raskin: why [http://www.asktog.com/papers/raskinintuit.html intuitive equals familiar] | |||
===Visibility=== | ===Visibility=== | ||
[[File: | [[File:VW Passat CC Cockpit.JPG|thumb|300px|car cockpit: great example for visibility]] | ||
It is far harder to recall from memory than to recognize. It is the same with functionality of product. If you see the control that triggers a function you will immediately know that the function exists and that you can use this control to trigger it. In contrast if you use a command line or a special gesture you need to retrieve the correct command from memory without any help. This is much harder to do. | It is far harder to recall from memory than to recognize. It is the same with functionality of product. If you see the control that triggers a function you will immediately know that the function exists and that you can use this control to trigger it. In contrast if you use a command line or a special gesture you need to retrieve the correct command from memory without any help. This is much harder to do. | ||
The proverb "out of sight, out of soul" is quite right: what we don't see is seldom in our [ | The proverb "out of sight, out of soul" is quite right: what we don't see is seldom in our [[wikipedia:Working memory|working memory]] (the part of memory we use to solve problems) and needs to be conscious retrieved - a costly process regarding cognitive resources. | ||
There are many invisible functions we face everyday: Water-tabs that are triggered if you weave a hand in front of them, keyboard shortcuts and touch-gestures. Functionality is invisible as well if you need to go to a certain place to see a visual representation. So the folder you save your work in is invisible as long as you don't open the file manager and navigate to your folder. Same with deeply nested menus. | There are many invisible functions we face everyday: Water-tabs that are triggered if you weave a hand in front of them, keyboard shortcuts and touch-gestures. Functionality is invisible as well if you need to go to a certain place to see a visual representation. So the folder you save your work in is invisible as long as you don't open the file manager and navigate to your folder. Same with deeply nested menus. | ||
| Line 300: | Line 371: | ||
Often the principle of visibility is ignored to make the interface disappear in order to make the product look nicer. Sometimes it really adds a bit of aesthetics but for the price of easy use and learning. So don't do so. What can be invisible are accelerator mechanisms like shortsćuts as long as the functions they trigger are accessible in an other, visible way. | Often the principle of visibility is ignored to make the interface disappear in order to make the product look nicer. Sometimes it really adds a bit of aesthetics but for the price of easy use and learning. So don't do so. What can be invisible are accelerator mechanisms like shortsćuts as long as the functions they trigger are accessible in an other, visible way. | ||
====Ressources==== | ====Ressources==== | ||
* Closely related to the idea of visibility are two terms dubbed by Don Norman:[http://jnd.org/dn.mss/ | * Closely related to the idea of visibility are two terms dubbed by Don Norman:[http://jnd.org/dn.mss/affordances and design.html Affordance] and the more appropriate term [http://jnd.org/dn.mss/signifiers not affordances.html signifier]. | ||
===Feedback=== | ===Feedback=== | ||
[[File:746px- | [[File:746px-Eric 'slowhand' Clapton.jpg|thumb|200px|Could Eric Clapton play guitar without feedback? Probably not!]] | ||
While visibility ensures that users easily know what you can be done, offering immediate feedback ensures that users know which results their actions have. | While visibility ensures that users easily know what you can be done, offering immediate feedback ensures that users know which results their actions have. | ||
Feedback is a well known real world experience. When you play an instrument you experience that a movement of you hand immediately changes the sound. | Feedback is a well known real world experience. When you play an instrument you experience that a movement of you hand immediately changes the sound. | ||
| Line 309: | Line 380: | ||
Imagine you would need to play guitar without hearing the sound! You would need to check afterwards if you got it right and would have no opportunity to improve while playing and listening. | Imagine you would need to play guitar without hearing the sound! You would need to check afterwards if you got it right and would have no opportunity to improve while playing and listening. | ||
[[File: | [[File:Progress bar gnome ubuntu.png|thumb|200px|a widget dedicated to feedback: the progressbar]] | ||
Ideally feedback is immediate and and directly visible. Feedback seems to be such an basic experience that everybody is confused if there is no feedback within a few moments. Without feedback people often start pushing buttons many times or they assume that the system has crashed, though it may just be busy doing what the user wants. To prevent this confusion an widget called "progessbar" is very useful. It is often seen when copying bigger amounts of data from one place to another. The movement of the progressbar shows that the computer works. | Ideally feedback is immediate and and directly visible. Feedback seems to be such an basic experience that everybody is confused if there is no feedback within a few moments. Without feedback people often start pushing buttons many times or they assume that the system has crashed, though it may just be busy doing what the user wants. To prevent this confusion an widget called "progessbar" is very useful. It is often seen when copying bigger amounts of data from one place to another. The movement of the progressbar shows that the computer works. | ||
| Line 318: | Line 389: | ||
===Modeless Design=== | ===Modeless Design=== | ||
[[File: | [[File:AppleCapsLock PD.jpg|thumb|200px|Caps Lock Key. The little light offers feedback, but the users attention is drawn to the screen]] | ||
Everybody knows about the problems "modes" create though you may never heard about this term. But for sure you already had trouble with the Caps-Lock-Key that changes the rESULT oF tYPING. If you push the Caps-Lock you enter a mode. This means that: | Everybody knows about the problems "modes" create though you may never heard about this term. But for sure you already had trouble with the Caps-Lock-Key that changes the rESULT oF tYPING. If you push the Caps-Lock you enter a mode. This means that: | ||
* The same actions cause different results now | * The same actions cause different results now | ||
* You attention is not necessary directed on the status of the mode, which means it can be triggered and used unnoticed. | * You attention is not necessary directed on the status of the mode, which means it can be triggered and used unnoticed. | ||
[[File: | [[File:OpenOffice Modal openSource.png|200px|thumb|A modal dialogue window. It blocks the interaction with the rest of the application. The toolbars (visible as well) are in contrast non-modal]] | ||
If an application behaves strange and you actions have results you did not expect it is likely that you entered a mode. If you are lucky you notice it and know how to get out of this. If not - which is far more often the case - you mess up your work, loose data and think the application in corrupt.It is but not its functionality but the design! | If an application behaves strange and you actions have results you did not expect it is likely that you entered a mode. If you are lucky you notice it and know how to get out of this. If not - which is far more often the case - you mess up your work, loose data and think the application in corrupt.It is but not its functionality but the design! | ||
| Line 334: | Line 405: | ||
Besides of modes there are other conditions that can cause errors and problems. The following chapter will explain more. | Besides of modes there are other conditions that can cause errors and problems. The following chapter will explain more. | ||
====Refereces==== | ====Refereces==== | ||
*Jeff Raskin's | *Jeff Raskin's "The Humane Interface" has a lot of information on Modes and Modeless Design. ISBN 0-201-37937-6 | ||
===Preventing Errors and Dealing with them=== | ===Preventing Errors and Dealing with them=== | ||
| Line 344: | Line 415: | ||
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. | ||
[[File: | [[File:Fehlermeldung Sprache-schlecht linux.png|thumb|200px|an almost useless error message]] | ||
In some cases you will use error messages. This is common for errors that derive from the way the technology that is used. E.g. if an application syncs files via a network and the network can not be accessed, the application can not work as intended. Many applications show error messages in a case like this: "IP Level 3 Error! Syncing process failed". This will trouble the user: The message uses system oriented terms that are only understandable for programmers and the user does not know how to solve the problem and does not know what happened to the data. A good error message uses simple and known terms and helps the user to recover the problem. This could look like this:"It seems that the necessary network connection is not available at the moment. Please put in your network cable or establish a wireless connection and try again to sync. Click the help button for further information". But before we consider that, we should make up our mind if it would be possible to make the system handle the error: The syncing actions could be remembered, the application could check if the problem is just because there is no network connection at the moment and that inform the user that the files will be synced later. | In some cases you will use error messages. This is common for errors that derive from the way the technology that is used. E.g. if an application syncs files via a network and the network can not be accessed, the application can not work as intended. Many applications show error messages in a case like this: "IP Level 3 Error! Syncing process failed". This will trouble the user: The message uses system oriented terms that are only understandable for programmers and the user does not know how to solve the problem and does not know what happened to the data. A good error message uses simple and known terms and helps the user to recover the problem. This could look like this:"It seems that the necessary network connection is not available at the moment. Please put in your network cable or establish a wireless connection and try again to sync. Click the help button for further information". But before we consider that, we should make up our mind if it would be possible to make the system handle the error: The syncing actions could be remembered, the application could check if the problem is just because there is no network connection at the moment and that inform the user that the files will be synced later. | ||
| Line 352: | Line 423: | ||
===Sketches=== | ===Sketches=== | ||
[[File:UI-Sketch-Flickr- | [[File:UI-Sketch-Flickr-Kyle McDonald.jpg|thumb|50px|left]] | ||
Sketches are helpful in generating different ideas. They help you to structure your thoughts and keep good ideas for later refinement or combination with other ideas. Don't worry about your sketches as long as you can understand them yourself! They are just for dealing with your own ideas and especially used in early project phases directly after research and whenever you have and idea you want to remember. | Sketches are helpful in generating different ideas. They help you to structure your thoughts and keep good ideas for later refinement or combination with other ideas. Don't worry about your sketches as long as you can understand them yourself! They are just for dealing with your own ideas and especially used in early project phases directly after research and whenever you have and idea you want to remember. | ||
===Mockups=== | ===Mockups=== | ||
[[File: | [[File:Wireframe Flickr-JoeCrawford.png|thumb|150px|left|wireframe]] | ||
Mockups are a graphic representation of what will be visible on the computers screen. They are used for communicating ideas in a team and to see how the elements of your interface play together in the screen layout. | Mockups are a graphic representation of what will be visible on the computers screen. They are used for communicating ideas in a team and to see how the elements of your interface play together in the screen layout. | ||
| Line 362: | Line 433: | ||
There are a couple of tools for creating Mockups like Balsamiq. Many people use Visio or OmniGraffle (two popular diagramming applications) as well. Often you can use "Stencils", pre-created Interface-Element collections that are used with the diagramming applications above or even an image-editor like Photoshop to have control down to each pixel. | There are a couple of tools for creating Mockups like Balsamiq. Many people use Visio or OmniGraffle (two popular diagramming applications) as well. Often you can use "Stencils", pre-created Interface-Element collections that are used with the diagramming applications above or even an image-editor like Photoshop to have control down to each pixel. | ||
[[File: | [[File:Mockup Fennec.jpg|thumb|250px|real-looking mockup]] | ||
Consider the effects of your mockups appearance. A simple sketch may take a few minutes to make, a pixel-perfect screen hours or days! So only design what needs to be communicated. Often you just want to try out screen layouts or want to communicate where which element of the interface goes. Usually it is enough to just draw the element's outlines - this type of mockup is known as "wireframe" as well. | Consider the effects of your mockups appearance. A simple sketch may take a few minutes to make, a pixel-perfect screen hours or days! So only design what needs to be communicated. Often you just want to try out screen layouts or want to communicate where which element of the interface goes. Usually it is enough to just draw the element's outlines - this type of mockup is known as "wireframe" as well. | ||
| Line 377: | Line 448: | ||
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: | [[File:PaperPrototyping Zeug.jpg|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. | ||
====Materials==== | ====Materials==== | ||
[[File: | [[File:PaperPrototyping Materialien.jpg|200px|thumb|Almost everything is in your office already]] | ||
*'''Paper itself''': The core material. You can draw your interface on it, you can apply glue, sellotape etc. and you can stack it and have e.g. consitent background and changing parts like dialogue boxes oir sitebars. Not to mention that it is very cheap. So it is no problem to restart or apply changes. | *'''Paper itself''': The core material. You can draw your interface on it, you can apply glue, sellotape etc. and you can stack it and have e.g. consitent background and changing parts like dialogue boxes oir sitebars. Not to mention that it is very cheap. So it is no problem to restart or apply changes. | ||
*'''pens''': You need them to draw your Interface. | *'''pens''': You need them to draw your Interface. | ||
| Line 392: | Line 463: | ||
====Interacting with a Paper-Prototype==== | ====Interacting with a Paper-Prototype==== | ||
<gallery widths=200px caption="Interacting"> | <gallery widths=200px caption="Interacting"> | ||
File: | File:PaperPrototyping manipulation.jpg|the computer changes parts of the interface | ||
File: | File:PaperPrototype TextInput.jpg|text input via pen | ||
</gallery> | </gallery> | ||
| Line 422: | Line 493: | ||
* 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. | ||
===getting people=== | ===getting people=== | ||
| Line 521: | Line 591: | ||
[[Category:Design]] | [[Category:Design]] | ||
[[Category:Courses]] | [[Category:Courses]] | ||
[[Category:Jan Dittrich]] | [[Category:Jan Dittrich]] | ||
[[Category:Jens Geelhaar]] | [[Category:Jens Geelhaar]] | ||
[[Category:Interaktion]] | [[Category:Interaktion]] | ||
[[Category:Interface-Design]] | [[Category:Interface-Design]] | ||