Bureaucrats, emailconfirmed
1,221
edits
→Explore your idea
m (fixed wiki syntax and formatting) |
|||
| (8 intermediate revisions by the same user not shown) | |||
| 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==== | ||
| Line 156: | 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=== | ===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. | 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") | 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") | ||
| Line 163: | Line 181: | ||
====Write Notes==== | ====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) | 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: | 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: | ||
| Line 169: | Line 188: | ||
* "The work piled up sice the machine was down. This caused a lot of disstress" | * "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" | * "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) | 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) | ||
| Line 174: | Line 195: | ||
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. | 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. | 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==== | ====Create Meaning==== | ||
| Line 182: | Line 203: | ||
[[File:Affinity Diagramming 2.png|200px|thumb|...and later on]] | [[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. | 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 | |||
The grouping process will require restructuring as well. Don't stick to the groups | 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. | For these top-groups again write descriptive notes. | ||
<!-- | <!-- | ||
State findings, Create Goals based on the analysis. | State findings, Create Goals based on the analysis. | ||
| Line 565: | 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]] | ||