Bureaucrats, emailconfirmed
1,221
edits
No edit summary |
(typos) |
||
Line 91: | Line 91: | ||
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! | ||
It is important to get to know what your users | It is important to get to know what your users want to achieve – what their goals are. User goals are not activities - like using a feature in your product. | ||
* "Finding that funny picture from the last holiday" is a goal the user might have, searching for it is not a goal the user has. If search would not be needed to find the picture she would not search! | * "Finding that funny picture from the last holiday" is a goal the user might have, searching for it is not a goal the user has. If search would not be needed to find the picture she would not search! | ||
* Having a collection of good references for a scientific paper you are writing is a goal, but keeping track of the references, ordering and categorizing is not | * Having a collection of good references for a scientific paper you are writing is a goal, but keeping track of the references, ordering and categorizing is not | ||
* Give friends a good impression of the place where you live is a goal. Hoovering the rooms is not. | * Give friends a good impression of the place where you live is a goal. Hoovering the rooms is not. | ||
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 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. | ||
===Conducting Interviews=== | ===Conducting Interviews=== | ||
Line 123: | Line 123: | ||
====Ask the right questions==== | ====Ask the right questions==== | ||
As designers is that we love to focus on | As designers is that we love to focus on innovation and future things. But now we need to look at the current situation and the way the user does things now in order to find out the goals behind actions and to discover existing problems because they reveal a lot about the way users think as well as good starting points for improvements. | ||
A good way to do find out about this is asking open questions and not direct ones. So the answers you should aiming for are not "yes" or "no" but e.g. the ones the user can tell you experiences or explains you something. Often it will be useful to follow up something the user said. When you ask '''"why"''' a decision was made in a specific way or '''how''' something works you can reveal important facts about the user's way to act. Focusing on current goals and problems means as well that you shouldn't make the user a designer. Users are very bad in telling what is good for them and what is bad. In this case you better do a test with a prototype. | A good way to do find out about this is asking open questions and not direct ones. So the answers you should aiming for are not "yes" or "no" but e.g. the ones the user can tell you experiences or explains you something. Often it will be useful to follow up something the user said. When you ask '''"why"''' a decision was made in a specific way or '''how''' something works you can reveal important facts about the user's way to act. Focusing on current goals and problems means as well that you shouldn't make the user a designer. Users are very bad in telling what is good for them and what is bad. In this case you better do a test with a prototype. | ||
Line 141: | Line 141: | ||
====Write your findings down:==== | ====Write your findings down:==== | ||
Take some time to do the review and gather all | 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.'' | ||
Line 155: | Line 155: | ||
===Formulate your goals, user's problems and other findings=== | ===Formulate your goals, user's problems and other findings=== | ||
Your coming design work will be based on your research findings. | Your coming design work will be based on your research findings. Since they are very important because of that, you should write them down. This is especially important if you work in a team - it helps to stay focused and eases communication. | ||
You can write down your '''original project idea''' first, as well as | You can write down your '''original project idea''' first, as well as your target group. Describe your potential users as clear as possible. Than write down what you want to do. This will be supporting the '''user goals''' you found out via your research. During the interviews you found out about the '''problems''' of the users. Being aware of problems will help you not to repeat errors and reveals a lot about the way the user deal with current technology. Making these errors is something you want to avoid to do. You should write down as well what could distract you in the design process. This is often rebuilding existing products that appear to have a similar focus or including functions that are often suggested but don't support your actual product vision. | ||
You can simply write down these in a simple bullet-point-style: | You can simply write down these in a simple bullet-point-style: | ||
Line 184: | Line 184: | ||
Reading papers may feel difficult when you start and often they contain graphs and numbers that tell you nothing at the first moment. But you will see that they all follow a common structure so after you got this you will easily find the parts that are of an interest for you - most likely the introduction telling what the paper is about and the conclusions about what they found out. | Reading papers may feel difficult when you start and often they contain graphs and numbers that tell you nothing at the first moment. But you will see that they all follow a common structure so after you got this you will easily find the parts that are of an interest for you - most likely the introduction telling what the paper is about and the conclusions about what they found out. | ||
Especially great about scientific papers is, that the authors quote other authors' findings and that the paper is again quoted by other researchers. So everything is connected – and once you found a paper that you like and find useful you get connections to all sorts of related papers. | |||
You can search for papers by using [http://www.google.com/scholar google scholar] or the [http://portal.acm.org/dl.cfm ACM Library]. The search is free in both cases but | You can search for papers by using [http://www.google.com/scholar google scholar] or the [http://portal.acm.org/dl.cfm ACM Library]. The search is free in both cases but only google scholar links often directly to the papers while you need a ACM membership to access the papers on the ACM webpage. If your university has one, you are a lucky student! But even if you find a paper on ACM or google scholar links on a pricy database too you should give it a try and search specifically for that papers title. Often the researchers have published accessible versions on their webpages. | ||
==Basics of Psychology== | ==Basics of Psychology== | ||
Line 489: | Line 489: | ||
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.--> | ||
[[Category:Design]] | [[Category:Design]] | ||
[[Category:Courses]] | [[Category:Courses]] |