IFD:Course Interaction Design: Difference between revisions

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

<!--==What do you want to do?==

Everything starts with an Idea. So does your interaction design project. Before you start you should take a moment (or a few more) to consider what you aim for. Sometimes it is not that difficult: A client or you professor will state in which direction you shall go.  

If you need to write down something in a clear and concise way you will note if there is anything unclear about your goals. It is difficult to build on a unclear vision. And a good way to test this is to write it down.  

Having a goal is even more important if you work in a team. If everybody supposes everybody works on kind-of-the-same but actually everybody images something very different it is likely that at some point this will have bad consequences like people being upset because there work was not cosidered as useful or fights about the actual direction of the project that would not be necessary and just cause bad mood or in the worst case the whole project breakes down.  -->

[[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 that need to be met. 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|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.

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|150px| "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.

[[File:PalmPilot5000.jpg|thumb|150px|the original palm - simple design focused on what was needed for organizing a work day]]

When I say simplicity I do neither mean "ease of use" nor "looking shiny and smooth". 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.

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.

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 term "user goals" is taken from Alan Coopers "About Face". Sometimes the term "goals" leads to confusion because people assume that goals are always something conciously planned - like your goals you write down in planning a project. Its often easier to talk about "motivations" instead.  

   

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.

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.

:* What in particular do they aim for when they try to refind previously accessed pages.

-->

A very useful tool for doing research are interviews.  

These key findings will guide you when you create your designs, because you now know what you need to concentrate on.

* [http://incontextdesign.com/articles/helpful-tips-to-improve-your-contextual-inquiry-techniques/ tips for a very similar technique called 'contextual inquiry']

* [http://www.adaptivepath.com/ideas/essays/archives/000041.php great tips for your questions]

* [http://www.boxesandarrows.com/view/extreme-user article concentrated on getting to know general fact about your users]

Using existing resources is useful in later project stages when you need to solve specific problems and already know about your users goals.

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 just google scholar links sometimes directly to the papers while you need a membership for ACM. 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.

"Designing" in this context means turning your ideas in somehow graspable representations. This is needed for refinement, communication and testing. In these areas the different techniques have different strengths.  

Even if this is not seen commonly as "design" you can turn your ideas into words to communicate them or to check if you are clear about what you want to do. This is a technique that is very useful in earlier stages after the first big research on your users and their goals. Guided by what you find out you can write down what you want to provide to meet these goals. Though one is tempted to start directly with the "real" design (sketches, programming etc.) you should make your mind what the system needs to do. It prevents you to overlook things.  

There my be other kinds of requiremets that you need to consider when developing your product. This could be size of the product, speed, final price, that it needs to feel "cool" for teens to have it etc.

[[File:UI-Sketch-Flickr-Kyle_McDonald.jpg|thumb|50px|left]]

Sketches are helpful in generating different ideas. They help you to structure your thoughts and keep good ideas for later refinement or combination with other ideas. Don't worry about your sketches as long as you can understand them yourself! They are just for dealing with your own ideas and especially used in early project phases directly after research and whenever you have and idea you want to remember.

[[File:Wireframe_Flickr-JoeCrawford.png|thumb|150px|left]]

Mockups are more advanced than sketches: often cleaner and more carefully crafted. Mockups are used for communicating in a team and to see how the elements of your interface play together in the screen layout. They are a graphic representation of what will be visible on the computers screen. So you can communicate your ideas about an application to your team-mates. It is usually decent to just draw the element's outlines - this type of mockup is known as "wireframe" as well.

For Mockups you use in your team or for trying out screen layouts you don't want to waste time on shiny graphics. In contrast to this you may want to do a Mockup to present it to somebody who does not know about the design process and is just interested in how the finished project looks like. In this case you need to spend more time on graphics. Often you can use "Stencils", pre-created Interface-Element collections that are used with the diagramming applications above or an image-editor like Photoshop.   

But before you eagerly start designing it may be helpful to explore some basic knowledge and principles that will help you designing products that offer a great user experience!

Interaction Design is heavily influenced by psychology. No wonder - we are dealing with creating things that are used because of the [http://en.wikipedia.org/wiki/Motivation motivations] of the users and are easy to use because it matches the way they [http://en.wikipedia.org/wiki/Cognitive_science think.]

If you are the engineer who build these systems it is totally clear for you how they work. As well it will be often the case that your mental model is differs from the one the users have. This itself is nothing to worry about and it happens all the time. But even if you are very clever you just can spot the problems that it can cause if you test your ideas with your users and see if they act like you intended.

There are some principles in interaction design that should be followed. It is no crime to break the rules – but you should have a good reason to do so. During the years quite may of them emerged. I collected and explained the ones that I consider as important and easy to apply.

One way to ease the dealing with a something new is to suggests that it works similarly to something the user already knows. This is often done to transferring real world principles to software interfaces and is also known as using a "metaphor". Like metaphors in language the metaphor transfers some aspects while some are not transferred - thats often good: if you do otherwise and try to transfer every single aspect you often end up with a use that has no advantages over the real world thing the metaphor is drawing from but is far more difficult to use.  

Metaphores can ease interaction - but bad metaphors can cause a lot of trouble. It is often better go see if any standard exists - thats what the following chapter is about.

In contrast to metaphors, Standards have been learned at some point. You learned that you can move a window dragging it on its title-bar, that clicking on a button triggers an action an that you find "save" and "open" in the file menu.

Like metaphors standards ease learning because you can build on something the user already knows - as it is a standard you can assume that applications the user used before taught him how to interact.

So what is the way around this? Most importantly: design you product carefully and only include functionality that serves the users goals well. If there is no way around than you can use "progressive disclosure": The interface has some main functions that are always visible and some advanced functionality that is visible when the user demands it. Often this is done by displaying important stuff at the top and offering a button that shows the additional functions. Using this way there are no arbitrary changes nor a whole new order is introduced as the basic functions remain in place.

[[File:VW_Passat_CC_Cockpit.JPG|thumb|300px|car cockpit: great example for visibility]]

It is far harder to recall from memory than to recognize. It is the same with functionality of product. If you see the control that triggers a function you will immediately know that the function exists and that you can use this control to trigger it. In contrast if you use a command line or a special gesture you need to retrieve the correct command from memory without any help. This is much harder to do.

Often the principle of visibility is ignored to make the interface disappear in order to make the product look nicer. Sometimes it really adds a bit of aesthetics but for the price of easy use and learning. So don't do so. What can be invisible are accelerator mechanisms like shortsćuts as long as the functions they trigger are accessible in an other, visible way.

[[File:746px-Eric_'slowhand'_Clapton.jpg|thumb|200px|Could Eric Clapton play guitar without feedback? Probably not!]]

While visibility ensures that users easily know what you can be done, offering feedback ensures that users know which results their actions have.  

Not offering feedback will confuse and frustrate users - immediate and well designed feedback will make them feel good as they feel in control of the system.

[[File:AppleCapsLock_PD.jpg|thumb|200px|Caps Lock Key. The little light offers feedback, but the users attention is drawn to the screen]]

Everybody knows about the problems "modes" create though you may never heard about this term. But for sure you already had trouble with the Caps-Lock-Key that changes the rESULT oF tYPING. If you push the Caps-Lock you enter a mode. This means that:

Modes should be avoided. E.g. introducing a navigation mode- and editing mode will just confuse your users. Make the different functions available without the demand to enter a mode. If there is no way to avoid a mode, indicate clearly and visible that the mode is triggered and how the user can escape the mode.

A frequently used list for design principles are the [http://www.useit.com/papers/heuristic/heuristic_list.html heuristics by Jacob Nielsen]:  

# '''Help and documentation:''' It is good if no help is needed to learn the program but some questions will appear, so provide searchable, easy to access information how to use the product

After we developed ideas it is again time to check with reality! This is known as prototyping and testing.

First you look what you need to test, like ''"does or Web-Page navigation work?", "Do people find the preference dialogue?", "do people get along with a totally direct Manipulation approach or are we better of implementing it point-and-click?"''  

Prototypes are easy to make (especially compared to the final product) and don't waste resources if an idea does not work. Ideas that don't work get sorted out and you can try something new. Because it does not hurt to be wrong you can be creative and find new ways of doing things.  

Getting people for your testing will be similar to the interview process. It is generally easier to tell the people what you actually want from them: "try out stuff" sounds more graspable than "being interviewed about... stuff"

To have meaningful testing results you should recruit people belonging to your targeted user group. Some products have a big user group: a TV-remote-control can be used by all sorts of people so gather a diverse group. But if your product is a source code editor you should recruit developers.   

So what shall your testers do with the Prototype? You need to give them some tasks they are going to do. So you should follow some simple steps:

* Write down typical tasks one can resolve using your product. This is a little brainstorming.

* Use language that is easy to understand. If the task's description is not comprehensible nobody can test.  

Now as you know what you are going to test you can build your prototype. It needs to simulate the situations that can occur when the participants do the task you gave them. So at least you need to cover the possibilities to resolve the task and some sideways that don't lead to the task's solution. Otherwise the Participant will try to interact and your prototype will not be up to responding and "crashes". I will show two possibilities: Paper-Prototyping and coded prototyping.  

Now, as you are finished building the prototype you need, you can finally do the actual test!

* If the user forgets about thinking aloud just ask ''"What do you think at the moment" ''  

After the tesing you will have a bunch of protocols. You review them to see how you can improve your product. So have a look where people got stuck or where they thought about a feature, menu entry et. differently than you expected.  

In latter stages of your project testign will serve more the purpose of improvement: evolution. not revolution. So it is the best to write an organized list of the problems that you observed and that need to be fixed.Order your findings after priority: Problems that could prevent an essential step from happening are improtatant to resolve.(e.g. importing a picture into a photo-organizing application or changing the channel on a TV) Watch out for patterns – some problems will occur over and over again and should have as well a high priority in resolving them.  

   

Having a list with what causes the user problems you know can refine your work. In early satges you will have seen which of some different ways will be dismissed and which will be further explored.

In later phases of your project you will have a list with ranked problems that need to be resolved. Start with the ones you consider the most serious and solve the problems. In doing so you often can build on the think-aloud-protocol you wrote. It give insight in the way the users think about the actions they took and about the responses of the software. This will help you to find a decent solution that will work better.