Bureaucrats, emailconfirmed
1,221
edits
structure
(Research) |
(structure) |
||
| Line 18: | Line 18: | ||
== | ==Before you start== | ||
===Your idea=== | |||
I assume that you have some kind of idea for what you want to realize. | |||
=== | <!-- | ||
* Guide will help to realize it | |||
* What do you really want? Put it more abstract in case you have something in mind to allow exploration. | |||
* Communicate in a team | |||
--> | |||
===iterative design=== | |||
[[File:IterativeDesign.png|300px|iterative design process]] | [[File:IterativeDesign.png|300px|iterative design process]] | ||
<!-- | |||
* You canb apply this to your problems. small and big ones. | |||
*established | |||
--> | |||
The iterative design process helps you to structure your design process. It is an easy to use cycle model, which steps you can follow. The Process of doing so is explained in this guide. | The iterative design process helps you to structure your design process. It is an easy to use cycle model, which steps you can follow. The Process of doing so is explained in this guide. | ||
| Line 38: | Line 47: | ||
So what is all that good for? Following the steps helps you to understand your users by doing research. So you don't design for non-existing needs or interfaces nobody can use. It helps as well to be more creative at the end: by dealing with your users, you will see your designs from a new perspective and so develop new ideas. | So what is all that good for? Following the steps helps you to understand your users by doing research. So you don't design for non-existing needs or interfaces nobody can use. It helps as well to be more creative at the end: by dealing with your users, you will see your designs from a new perspective and so develop new ideas. | ||
'''A small Example:''' | |||
Imagine you design a new mobile phone. You can use the process that is suggested here to design the general product: You will research how people will use the phone, you will determine which features you need for meeting the users needs. Than you will design how all features work together in the phone and how it will look like. At the end you test it. | Imagine you design a new mobile phone. You can use the process that is suggested here to design the general product: You will research how people will use the phone, you will determine which features you need for meeting the users needs. Than you will design how all features work together in the phone and how it will look like. At the end you test it. | ||
| Line 53: | Line 62: | ||
==Explore your idea== | |||
==Explore your idea | |||
Having your idea you could start designing right away. It can save you a lot of time and pondering to do some research and exploration first. This typically concerns: | Having your idea you could start designing right away. It can save you a lot of time and pondering to do some research and exploration first. This typically concerns: | ||
* Your users goals (what they want to achieve) | * Your users goals (what they want to achieve) | ||
| Line 73: | Line 68: | ||
* Solutions, Experiences and Problems others had in similar projects.<br> | * Solutions, Experiences and Problems others had in similar projects.<br> | ||
You may think that it is not necessary to do research as you are a clever person who knows already a good bunch of stuff about | You may think that it is not necessary to do some kind of research as you are a clever person who knows already a good bunch of stuff about the people you design for. Cognitive Psychologist and UX Professional Don Norman rightly says: "we tend to project our own rationalizations and beliefs onto the actions and beliefs of others". In other words:You think others are like you. But the interesting thing is: they are not the same. So you need to find out. | ||
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. | |||
===User Goals/User Motivations=== | ===User Goals/User Motivations=== | ||
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 86: | Line 79: | ||
* 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 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. | ||
<!-- | |||
===Research Questions=== | ===Research Questions=== | ||
Many design projects start with an clear idea how the final design could look like and work. Often this is a good idea, though you don't know - and you can't be sure if you tackle existing problems. An example: you think it would be great if webpages would be visualized and indexed if you have them in your bookmarks. | Many design projects start with an clear idea how the final design could look like and work. Often this is a good idea, though you don't know - and you can't be sure if you tackle existing problems. An example: you think it would be great if webpages would be visualized and indexed if you have them in your bookmarks. | ||
| Line 108: | Line 100: | ||
Having made up your mind about that you can formulate what you want to do and can do research on this. Write down these things. | Having made up your mind about that you can formulate what you want to do and can do research on this. Write down these things. | ||
:You find out that you should think about:<br> | :You find out that you should think about:<br> | ||
:* What people remember about webpages they prevoiusly used. | :* What people remember about webpages they prevoiusly used. | ||
:* How they organize files, webpages etc. now | :* How they organize files, webpages etc. now | ||
:* What in particular do they aim for when they try to refind previously accessed pages. | :* What in particular do they aim for when they try to refind previously accessed pages. | ||
--> | --> | ||
=== | |||
===conducting interviews=== | |||
A very useful tool for doing research are interviews. | A very useful tool for doing research are interviews. | ||
They are best done early in the design process | 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. | ||
You want to '''interview potential users of your product''', so you need to see who could use your product. Than you try to get these people to an interview. | You want to '''interview potential users of your product''', so you need to see who could use your product. Than you try to get these people to an interview. | ||
| Line 167: | Line 158: | ||
* [http://www.boxesandarrows.com/view/extreme-user article concentrated on getting to know general fact about your users] | * [http://www.boxesandarrows.com/view/extreme-user article concentrated on getting to know general fact about your users] | ||
===Formulate your goals, user's problems and other | ===Formulate your goals, user's problems and other findings=== | ||
Your coming design work will be based on your research findings. As 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. | Your coming design work will be based on your research findings. As 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 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 researched as well '''problems''' of the users. Being aware about 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 write down your '''original project idea''' first, as well as you 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 researched as well '''problems''' of the users. Being aware about 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. | ||
| Line 453: | Line 444: | ||
If your testers never tested an prototype before they are likely to wonder what is going to happen. So it is important to give them a brief introduction. | If your testers never tested an prototype before they are likely to wonder what is going to happen. So it is important to give them a brief introduction. | ||
At first you | At first you introduce yourself and state that the test participant will try out a new product in order to help you to find which things work and which not. | ||
A very common thought is that ''they'' are going to be tested if they are clever enough to figure out how your software works. This causes them distress and it causes you less useful results because they don't act normally. So tell them: ''"Please note, that the product/software/website is going to be tested and not you! Occurring problems are part of the process and not a reason to worry. As well you should not worry about hurting our feelings - because we do this to find out what we could do better"'' They probably will feel better now. Tell them as well that they can cancel the testing if they feel uncomfortable ant any given moment. | A very common thought is that ''they'' are going to be tested if they are clever enough to figure out how your software works. This causes them distress and it causes you less useful results because they don't act normally. So tell them: ''"Please note, that the product/software/website is going to be tested and not you! Occurring problems are part of the process and not a reason to worry. As well you should not worry about hurting our feelings - because we do this to find out what we could do better"'' They probably will feel better now. Tell them as well that they can cancel the testing if they feel uncomfortable ant any given moment. | ||
| Line 502: | Line 493: | ||
<!--LEGACY --> | <!--LEGACY --> | ||
<!-- In Alan Coopers Book "About Face 3.0" there is another great example about the difference: Traveler's goals are to travel "quickly, comfortably and safely". In 1850 archiving safety included to bring along a rifle - an activity to achieve the goal. The goals remained the same for today but for flying quickly, comfortably and safely we leave our weapons at home – different activities, same goal.--> | |||
<!-- | <!-- | ||
==Introduction== | ==Introduction== | ||
| Line 551: | Line 542: | ||
--> | --> | ||
<!--===Simplicity=== | |||
[[File:PalmPilot5000.jpg|thumb|150px|the original palm - simple design focused on what was needed for organizing a work day]] | |||
The kind of simplicity I mean in this chapter is implementing only the features that are important for your idea and to implement them in a way that they work together greatly. You should not add anything because it is a nice to have or one in ten people thought it would be useful. | |||
Every time you add a feature, you need to make it fit to the rest of your product. It potentially will make it slower, less solid and more difficult to use. And keep in mind: the resources you use to add features (you are probably student so it is: time) can't be used for refining the really crucial features. | |||
So how do you decide which features you are going to implement? I don't have any instant solution, but two aims. One aim is to understand as much as possible about the users, | |||
their work, and the context of that work, so that the system under development can | |||
support them in achieving their goals; this we call "identifying needs." Building on | |||
this, our second aim is to produce, from the needs identified, a set of stable require-wo aims. One aim is to understand as much as possible about the users, | |||
their work, and the context of that work, so that the system under development can | |||
support them in achieving their goals; this we call "identifying needs." Building on | |||
this, our second aim is to produce, from the needs identified, a set of stable require- | |||
ments that form a sound basis to move forward into thinking about design. This is | |||
not necessarily a major document nor a set of rigid prescriptions, but you need to | |||
be sure that it will not change radically in the time it takes to do some design and | |||
get feedback on the ideas. Because the end goal is to produce this set of requirements, we shall sometimes refer to this as the require | |||
ments that form a sound basis to move forward into thinking about design. This is | |||
not necessarily a major document nor a set of rigid prescriptions, but you need to | |||
be sure that it will not change radically in the time it takes to do some design and | |||
get feedback on the ideas. Because the end goal is to produce this set of require- | |||
ments, we shall sometimes refer to this as the require | |||
this might help: | |||
* keep in mind that you should create a unique, easy-to use product that does do what it does greatly. | |||
* During this course you will learn how to do user research to find out about the goals and problems of your users. Try to find out what really matters for all of them. | |||
*If you see that you have two different groups of people, find out if they are similar enough to serve them one product. If they differ too much, say goodbye to one of them and design just for one of the groups - maybe you come back later to the other, but first concentrate on one thing. | |||
It as as well always easier to add features later than to take away features that bloat your product. 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.--> | |||
[[Category:Design]] | [[Category:Design]] | ||