IFD:Course Interaction Design: Difference between revisions

Mitarbeit willkommen. Bitte beachtet dass eure Beiträge unter Creative Commons Lizenz stehen werden.

[http://creativecommons.org/licenses/by-sa/3.0/ http://i.creativecommons.org/l/by-sa/3.0/88x31.png]

'''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.

<!--

I suppose when you hear about "Interaction Design" you probably think about computer applications. He or she will probably decide how the functions of the software are represented to the user as icons or menu entries. You are not wrong with these assumptions: The most people who work as "Interaction Designer" deal with applications or websites and among other things they design what appears on the computer screen.

[[File:IterativeDesign.png|300px|iterative design process]]

What you do now is trying out different ways to make the type-selection easier, so you just repeat the "mini-cycle" of testing and design.

The usability goals are a  collection of the very basic user needs. They are broad, but you will have no trouble to understand them.

If your product's functionality matches the needs of your users and enables them to reach their goals it has a good utility.

You can find out your users needs and goals by doing "user research" which means that you apply some research methods. One of these methods is doing a special kind of interview with some users. I will cover this technique in a latter chapter.   

A good learnability exists if the users you target can use your product without putting a lot of effort learning. This is especially important for the very basic functions.  

You can improve the learnability of your application by learning common principles of design like "visibility" or "consistency" and by testing your ideas with your users. Material for learning this will be provided in latter chapters.

[[File:ComandLine.png|thumb|200px|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.

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.

[[File:SicherheitNutzerdaten.png |thumb| "Close" and "Save" close to each other: not save!]]

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.

When I say simplicity I do neither mean "ease of use" nor "looking shiny and smooth". The kind of simplity 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 ressources you use to add features (you are probably student so it is: time) can't be used for refining the really crucial features.  

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:Interaktion]]

[[Category:Interface-Design]]

[[Category:Design]]

[[Category:Courses]]