IFD:Course Interaction Design: Difference between revisions

IFD:Course Interaction Design (view source)

Revision as of 12:49, 16 November 2010

No change in size , 16 November 2010

no edit summary

JanD

Bureaucrats, emailconfirmed

1,221

edits

@@ Line 43: / Line 43: @@
 The steps are:
 # '''Research:''' in which you gather informations about user goals, existing problems and already existing solutions.
-#'''Formulating you aims:''' Helps you to know what you actually want to archive with your design (and what not!). This can be seen as belonging to research but it is crucial to make the research useful, so it's got its own bullet-point!
+#'''Formulating you aims:''' Helps you to know what you actually want to achieve with your design (and what not!). This can be seen as belonging to research but it is crucial to make the research useful, so it's got its own bullet-point!
-#'''Design:''' Is creating solutions for what you want to archive. You start with a broad design of that is fairly abstract and make your ideas more concrete over time. For minor things new research would be too elaborate - than you repeat the smaller cycle of designing and testing in succession.
+#'''Design:''' Is creating solutions for what you want to achieve. You start with a broad design of that is fairly abstract and make your ideas more concrete over time. For minor things new research would be too elaborate - than you repeat the smaller cycle of designing and testing in succession.
 #'''Testing:''' After you designed you need to test if your ideas work as you expected. This is can be a hard thing to do because some things that seem to be great turn out to be unsuitable for your users. You will get all sorts of interesting insights that will help you in improving your ideas.
@@ Line 91: / Line 91: @@
 ====Efficiency====
 [[File:ComandLine.png|thumb|150px|Great efficiency but hard to learn]]
-Your product has a good efficiency if the user can archive a high productivity. This simply means he/she can do more in less time once it is known how one uses the product.
+Your product has a good efficiency if the user can achieve a high productivity. This simply means he/she can do more in less time once it is known how one uses the product.
-Efficiency can be archived with optimizing the ways the functions are accessed and with providing additional ways of interaction like keyboard shortcuts.
+Efficiency can be achieved with optimizing the ways the functions are accessed and with providing additional ways of interaction like keyboard shortcuts.
 Efficiency is important, but in my experience it is easiely over-emphasized as one does not need to learn one's own designs and efficient stuff feels just great. But a command line interfaces or gestural interaction are cool and really efficient if you can use it but they need to be explicitly learned before they can be used. And the difficulties of learning are often underestimated by interaction design beginners.
@@ Line 117: / Line 117: @@
 ==Research==
-The research is the preparation for the actual design process. Doing research will help you to design for what the users want to archive and to avoid common problems. It is also likely that some other people did work you can build on. This can save you a lot of time and pondering.
+The research is the preparation for the actual design process. Doing research will help you to design for what the users want to achieve and to avoid common problems. It is also likely that some other people did work you can build on. This can save you a lot of time and pondering.
 It is useful to do research on
-* Your users goals (what they want to archive)
+* Your users goals (what they want to achieve)
 * Existing Problems
 * Solutions, Experiences and Problems others had in similar projects.<br>
@@ Line 136: / Line 136: @@
 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 what to archive – what their goals are. User goals  are not activities - like using a feature in your product.
+It is important to get to know what your users what 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!
 * 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.
-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 archive 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.
+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.
 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.