A Students Guide to Interaction Design Solltest ihr irgendwetas ändern: bitte beachtet, dass eure Beiträge unter Creative Commons Lizenz stehen werden. If you change something, please note that this work and you edits are licensed under a Creative Commons
Licence: This work is licenced under Creative Commons Attribution-ShareAlike 3.0 Unported.
Preface
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.
Foundations
Iterative Design Process
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 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!
- 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.
- 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.
The model is called iterative because you will go through the all or a part of the steps several time. Doing all steps one after the other one time is known as an "iteration". Each time you do so, you improve your product and former abstract things will become more concrete.
The model can be applied for designing the general product as well as for designing a small feature. You don't need to do all steps each time you try to solve a problem. It is very common to design, test and refine the design based on the test's results to test again. But you should at least consider the possibility to research.
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.
During this process you will see that you need to answer smaller questions like how to implement sending messages: Is it better to have different facilities for SMS, MMS and e-mail, or shall they be combined in one view so that the user can ignore the differences between the different techniques?
For getting to know how to deal with this you can again use the cycle model:
1) Find out how the users think about messages and how they use them.
You may find out that users think of their messages all in the same way when they get them but in technical terms when they write them
2) Write down what you need to keep in mind when you design
I want to design a unified view for incoming messages while still providing explicit control over self initiated or reply-messages
3)Than you design...
4)...and test.
Example:It turns out that your design was overall easy to use but that some users had trouble with selecting the message type while sending
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.
Usability Goals
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.
Utility
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.
Learnability
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.
Ideally users don't have to bother about new concepts and unknown terms.
Learnability is what will be the first thing that comes into your mind if you think about interaction design. Paradoxically it is a principle that is ignored in many products: Industry often uses a lot of functions that diminish learnability and many student projects ignore learnablity and focus on efficiency. 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.
Efficiency
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 can be archived 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.
Safety
Safety is protecting the user and his/her creations from undesired outcomes. Very basic is that you provide a product that does not crash and destroys the users work by doing so.
You should as well prevent that the user selects data-destroying functions by accident. E.g. putting the "save" and the "close" entry close to each other in a menu will cause data loss: if the user wants to save, he may press "no" after a dialogue window appears: "don't bother me now. I want to save my data!" - and the data is lost, "close" was selected by accident and the dialog-window that was dismissed by choosing "no" was the final warning.
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.
Simplicity
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. 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 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.
But what about the products that are used by everyone? In case you want to design something like this you should not apply the suggestions above, right? Well, when I think about products for everybody I think of facebook for example. It has a vast number of users so this is enough "everybody" for a beginning interaction designer I think. Though strangely, Facebook started with a very restricted target group: Students of the Harvard University. Slowly and controlled it was opened to more people. First Students of other elite US universities ("Ivy League"). Than all other US universities. Than Highschool students, employees of several big companys and finally it was open for everybody. I don't want to put them on a pedestal for great interaction design. I just want to illustrate that they are successful and did not "desgin for everybody".
What this illustrates as well is that it is always easier to add features. Removing them if you note that they don't help you is very hard. You can do so but nobody likes it. What if a function that you particularly use would disappears after an upgrade of your favourite software? 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.
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.
It is useful to do research on
- Your users goals (what they want to archive)
- Existing Problems
- Solutions, Experiences and Problems others had in similar projects.
not to underestimate is:
- Getting inspiration
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 what 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 via research.
In the beginning of your Project the main research 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
- 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.
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.
- "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.
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
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.
For doing research you need to find out what is it you are dealing with actually? In the above example this is:You want to ease refinding webpages they previously liked.
If you just have a problem in mind that you want to solve you have it easier. Make your mind what you want and need to find out. This is often:
- What are the goals and motivations behind a certain behaviour that is connected to your idea
- What are current problems with current solutions similar to what you have in mind.
When you do qualitative research you need to do interviews - so see as well
- Which user group you want to target
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.
Interviews
A very useful tool for doing research are interviews. They are best done early in the design process in order to find out for which user needs you design. 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 can use a couple of ways to contact these potential users: Use your universities Mailing List, ask friends of friends. As you can do the interviews via skype as well, you can state that you search for interviewees on your twitter-page or blog. (Remember: you don't search for everybody, so state for which people you are looking for) State what you are going to do and what it is for. As a student you have probably no money you can offer as compensation. So at least you should offer some coffee and cookies to your interviewees!
Before you start brief tell again what the interviews are for. Some people may feel kind of "tested" on computer literacy or something like that. Tell them they don't need to worry and that hearing about problems will help you as much as anything else.
The interview should be pleasant for the interviewee, so don't stretch it too long. Being a attentively and a good listener will help as well.
The first steps are the most difficult but once the interviewee talks it usually runs smooth.So it is a good idea to start with some questions that are useful for you to know and have clear and simple answers like the profession, years of experience etc.
The important thing about the interview is that you don't ask specific and direct questions but open 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. Asking why a decision was made in a specific way or how something works can reveal important facts.
Here are some open Questions as an example
- What motivates you to do this?
- What was the best day at work in the last weeks? (Follow up with "why?")
- What annoys you when you work on this?
When you do interviews there are some common problems that can occur.
- You ask "yes/no" Questions
You: "Do you like this mobile phone?" Interviewee "Yes!"
What do we know now? Nothing.
Solution:"What do you like about the phone?" - The Interviewee answers in very abstract ways
Interviewee answer: "In general these things make me think about..."
The answer does not tell us something interesting about the real life of the user.
Solution:"Can you tell me about the situation it happened the last time?" - The Interviewee demands a specific feature
Interviewee answer: "Well... You just need to put a red button here!"
Users don't know what would make a design that is good to use for everybody. We don't know either for sure, so we do research!
Solution:"How would the red button help you?" - You want to know if a feature you have in mind would be good
You: "Would it help you to have a green lever that does [whatsoever]?"
This is similar to the situation above. What the user understands will be just "...help you?" or "...feature..." so help and features are considered as good so the answer will be "yes"!
Solution:Don't ask this question! In a latter section you will read about testing and prototyping such ideas. If you want to gather information on the specific feature in the interview nevertheless: gather informations about the user and his/her context that could reveal if the user needs the feature that you have in mind.
During the interview you take notes or record the audio (Ask for permission if you do the latter) So you will be able to review the interviews.
Take some time to do the review and gather all you notes or recordings. Read or listen through them. Remember, whe 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 is to improve their CVs and to get known. Write down common problems as well so you know which traps to avoid and where new solutions are needed.
These key findings will guide you when you create your designs, because you now know what you need to concentrate on.
Ressources
- tips for a very similar technique called 'contextual inquiry'
- great tips for your questions
- article concentrated on getting to know general fact about your users
Use what is already out there
Using existing resources is useful in later project stages when you need to solve specific problems and already know about your users goals.
If the topic you want to work on is new for you it might be a good start to start with a book that offers an overview on the field of interest. It will help you as well to get to know the special terms that are used in a more specialized topic. This can be crucial: I often searched for papers of other resources on the web. What often took the most time was getting to know the name of what I was actually looking for. For a recent project on online collaboration in design I googled a lot about "Open Design", Collaborative Design" etc. finally I found out, that the term that gave me some interesting links was "open source design" – which was not what I would have guessed initially.
This leads us to the very common possibility to use a search engine to find interesting sites on your topic. The UX community blogs a lot and there is a lot of stuff out there.
In case you have a specific problem you can consider scientific papers. If you need an answer on questions like "what do people remember about their documents?" or "is bimanual interaction an advantage for navigating in virtural space?" than you should go for science!
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.
What is especially cool 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 google scholar or the 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
"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.
...in words
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.
A structured approach of this is defining "Requirements". This is defining the things your product needs to do at the end – in early phases the very essential ones.
Sketches
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.
Mockups
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.
Like sketches mockups can be drawn on paper. Chequered sheets are useful here cause they provide a grid so your wireframe will look better and organized.
There are a couple of tools for creating Mockups like Balsamique. Many people use Visio or OmniGraffle (two popular diagramming applications) 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.
Prototypes
All ways of design above have in common that they can more or less look like the intended product but they dont have any functionality. "Models" of your software that provide functionality are called "Prototypes". They are mainly used for testing your ideas. In latter chapters I will teach how to build a prototype and to conduct a test with it.
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!
Basics of Psychology
Interaction Design is heavily influenced by psychology. No wonder - we are dealing with creating things that are used because of the motivations of the users and are easy to use because it maches the way they think.
What you should be aware of is that there are some things that are "expensive" regarding our cognition. One of thiese things is learning new things and getting them into our long-term memory e.g. how you do a certain action in a program. An other is keeping things in short term memory. An example for this would be to remember which function you triggered previously or which item you copied into the clipboard.
Mental Models
The way real world things work is represented in our mind as a so-called mental model. The whole world with all its properties can't get in our mind. It would be too much data and what we percieve is heavily filtered anyway by our senses. A "good" mental model maintains - despite of the reduction of the real thing - the things that are relevant for the way we deal with the thing the mental model represents.
Lets take an example: The mental model about what the depicted controls do is the same for the most people. The mental model derives from the way the controls looks like and which effect turning them will have. Truning them more makes the room eventually hotter. Because they are turned we suspect a kind of valve working behind of them: turn more increases some kind of opening that allows more heat to flow through.
Because both controls look almost the same it is absolutly no wonder that we assume they work the same way. But they differ. The first one is really a valve and you really can regulate how far it is opened. The second one though is a thermostat. It works in a different way: The user sets a temperature. The heat beginns to flow. If the pre-set temperature is reached it stops, if the themperature is lower it starts again.
The mental model breaks if you want to use a thermostad to seed up the heating process. This often causes burned food as an oven has a thermostat too. So if you are hungry and want to get the pizza fast and you think "I just turn the knob a lot"... well, it does nothing except turning your food into a black-charcoal like whatsoever.
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 poblems that it can cause if you test your ideas with your users and see if they act like you intended.
Basic Principles& Best Practices
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.
Metaphors
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.
There are many metaphors around when you take a look at your computer's applications. The most times you will use metaphors by choosing a suitable name or icon for a function or desinging the workflow like a well known process. Though here are two examples of well known metaphers that almost rule the way we deal with the applications they are used in:
- The Desktop: A classic Metaphor. Like in you real desktop you can put documents you currently deal with, on your desktop and organize your workspace. Many aspects of a real world desktop were not transferred for good reasons. The recycling bin e.g. is usually not seen on top of your real world desktop. But it is pretty useful that it is on your computer's desktop.
- Tools:
You hardly notice this metaphor. Its pretty good. We use tools all the time in our real life and we easyly know how to use the tools on the toolbar in our image editing program: The eraser deletes stuff, the brush paints with color etc.
Metaphors seem to be simply great at the first glance. But they can cause a lot of problems too. They can constrain the user because real world constrains do not apply in the computer. In bad cases the whole interface just follows the metaphor instead of the users needs. This happened in "Microsoft Bob" which was a desktop replacement using a house as metaphor. To access different kinds of applications you needed to go to different rooms. To start the word processor you clicked on a sheet of paper on the desk in the living room etc. The use was cumbersome and unintuitive, so Bob did not succeed. Not as bad as Bob but worth mentioning is the interface of QuickTime 5 that used a wheel to change the sound intensity. So... how do you turn a wheel using your mouse? It turned out that it the usual linear movement worked as well - the same you do when you use a normal slider.
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.
Standards and Consistency
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.
Some Examples:
- The cockpit of a car - we could use a joystick for steering and push-buttons for setting the direction indicators but we don't in order to enable everybody to drive any car without relearning driving.
- There is just a very rough connection of Application windows to windows in the real world, but we learned what a it is.
- A right-click triggers a context menu
- Files are organized in Folders
The last example illustrates as well, that many standards are metaphors we agree on. We could do many things differently but if we would e.g. rename "folders" to "boxes" we would break the standard, and users would need to relearn what "boxes" are. Standards are crucial - if each application would invent their own ways of doing things users need to relearn all the time. There are styleguides for applications made by the people who create the operating system or desktop to help programmers and designers to use the standards the most people agree on.
Radio Buttons are used for selecting when just one of the alternatives can be chosen. What is depicted turns a standard element into something else though it looks the same.
What should never be done though is making standard-looking widgets (Elements of the Interface) behave in a non-standard way. E.g if you use something that looks like a menu it should behave like a menu and not else.
Often designers break standards thinking they have a better solution. Sometimes there are reasons to come up with non-standard methods but it is rarely the case. You should only break standards and do things in way that is not known to the users in case...
- ...you really need a way that is superior to the standard-way
- ...you carefully crafted such a way
- ...and you tested it to ensure that it works like intended.
This is often done for a good reason in applications like 3D Modelling Environments. These applications often have a steep learning curve, are very powerful, complex and deal with something (3D) that is not common in the most applications (mostly concerned with 2D stuff.
"Standards" are concerned with having not to relearn things with an perspective to different applications and systems. We don't want that the user needs to relearn while using a single product as well. This is often refereed to as "consistency". This mean in your application you use the same conventions all over the place. If you e.g. enable changing the color of items via the contextmenu, this should be possible with all times. If you enable to drag and drop items drag-and drop should work application wide. Doing so means that the user just has to learn that your application allows this and that way of interaction. If the interaction is inconsistent on the other hand, users would need to learn in which places something works.
An other inconsistency are functions that change the way of visual organisation. This is often done by introducing automatic functions that shall show the "most important" items on top. If often fails. Microsoft did this with the menu entries in Windows 2000. And the constant and inconsistent reordering of menu items made it a cumbersome experience. Similar are "Expert" or "Beginner Modes" that reorder the whole interface. They mostly confuse. The problem that should be tackled is clear: too many functions clutter the interface.
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.
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.
The proverb "out of sight, out of soul" is quite right: what we don't see is seldom in our working memory (the part of memory we use to solve problems) and needs to be conscious retrieved - a costly process regarding cognitive resources.
There are many invisible functions we face everyday: Water-tabs that are triggered if you weave a hand in front of them, keyboard shortcuts and touch-gestures. Functionality is invisible as well if you need to go to a certain place to see a visual representation. So the folder you save your work in is invisible as long as you don't open the file manager and navigate to your folder. Same with deeply nested menus.
A positive example of a interface that does a great job concerning visibility is the of a car. Everything you need is immediately visible.
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.
Feedback
While visibility ensures that users easily know what you can be done, offering feedback ensures that users know which results their actions have. Feedback is a well known real world experience. When you cut bread you know see the knife moving and feel the change resistance. When you play an instrument you experience that a movement of you hand immediately changes the sound. Imagine you would not have feedback in the above examples: Having no resistance and visibility of the knife while cutting bread would cause you carrying on with slicing the table after the bread is done. If you would need to play guitar without hearing the sound you would need to check afterwards if you got it right.
Ideally feedback is immediate and and directly visible. Feedback seems to be such an basic experience that everybody is confused if there is no feedback within a few moments. Without feedback people often start pushing buttons many times or they assume that the system has crashed, though it may just be busy doing what the user wants. To prevent this confusion an widget called "progessbar" is very useful. It is often seen when copying bigger amounts of data from one place to another. The movement of the progressbar shows that the computer works.
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.
Modeless Design
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:
- The same actions cause different results now
- You attention is not necessary directed on the status of the mode, which means it can be triggered and used unnoticed.
If an application behaves strange and you actions have results you did not expect it is likely that you entered a mode. If you are lucky you notice it and know how to get out of this. If not - which is far more often the case - you mess up your work, loose data and think the application in corrupt.It is but not its functionality but the design!
One of the rare examples of modes that don't cause confusion are the tools in image editing applications. They introduce modes too, because a mouse click will cause a selection (using the select tool), painting (brush) or deleting something (eraser) But it does not cause problems because we know the tool-modes from the real world, we have direct feedback and the cursor changes as well. So we are aware of the mode.
Very often you encounter modal dialogs. They pop up in front of your main window and block the interaction with it. So clicking the main window will have a different result that usual and it is: nothing. This is especially bad if the modal window just is a notification that something worked or not. Modal notifications can be turned into non-modal ones as a bar that slides into the window from above ("infobar"), Modal windows for editing (like the depicted font-dialouge above) can be often realized as sidebars.
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.
Get to know if your ideas work!
Heuristic Evaluation
Heuristics are "rules of thumb" derived from experiences that are used to solve problems efficiently. The rules are no guarantee to get an optimal or even a good solution but in the most cases heuristics work good and especially fast.
A frequently used list for Heuristic Evaluations are the heuristics by Jacob Nielsen:
- Visibility of system status
- Match between system and the real world
- User control and freedom
- Consistency and standards
- Error prevention
- Recognition rather than recall
- Flexibility and efficiency of use
- Aesthetic and minimalist design
- Help users recognize, diagnose, and recover from errors
- Help and documentation
Introduction to prototypes
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?" For answering your questions you will need to build a prototype. (You can and should test finished products too, but I assume you design) Prototyping is creating a "model" of your software that enables you to try out certain things. Think of building a model aircraft: It will be sufficient to show if an engineers idea will be work in general. There are several techniques to create a prototype. You will read about paper prototypes and coded prototypes. Paper prototypes can be made by everybody who can use a pen and scissors. The system responses are simulated by you as you will change the prototype manually. Coded prototypes need to be programmed and are therefore more difficult to make. They can simulate some more things in hi-fidelity and you can test them remotely via screensharing as you don't have to be with your tester as you don't have to change anything manually.
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
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"
Similar to the interviews as well is that you can do a person-to-person testing using any prototyping technique. In this case you need to ask friends, fellow students etc. to recruit people. If you have a coded prototype you can acquire participants via your blog, twitter, facebook or mailing list as well and do the testing remotely via screensharing. This can make it easier to find participants especially if you work as part of a open source project that is mainly working in collaboration via the web.
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.
Choosing a task
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.
- Out of the tasks you wrote down you choose the ones that you feel are typical for your software and crucial for using it.
Write the tasks
- You need to think about a suitable context for your tasks. So don't just write: "import the pictures from the SD card into the Program" but something like "You are a Photographer and just finished shooting. Please import the pictures into the program for doing further work with them"
- It needs to be clear when a task is finished. So don't write any open ended tasks but one that have a clear goal and condition one needs to reach.
E.g. the example above could be improved by changing the end to "Please import the pictures into the program, so that you can see the images thumbnails in the program"
- Use language that is easy to understand. If the task's description is not comprehensible nobody can test.
Build a Prototype
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.
Paper Prototyping
Simple Interactive Prototypes
Coded Prototyping
Do the test
Now, as you are finished building the prototype you need, you can finally do the actual test!
If you test with paper prototypes it will be useful to get an additional person before you start: besides of doing the actual testing, somebody needs to be the "computer" and change the prototype according to the users interactions.
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.
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.
You want to know what participants think while testing your product - so you should ask them to "think aloud": during the testing process they shall tell what is in their mind at the moment. This will sound like this "I think this menu entry will import the images... so I click... well... I know that..." To get the people talking you should ask them a few simple questions like if they have already experience with similar products and things like this.
After this introduction the test can start. Tell the participants the task, or better, hand them a paper with the task and the context scenario.
While the user does the task you write down your notes. Its not that easy to write, keep your eyes on the screen and listen to the users thinking-aloud – but you will get used to it.
As with the interviews there are some things you should avoid. Most importantly you should not influence the tester or help him or her.
- If the user does anything and you have the urgent feeling that you should show the right way: don't do so. It will spoil what you actually want to know: where problems occur and how the user deals with them.
- If the user asks you questions about solving the task like "is this right?" or "can I..." just answer:What you like" or "What would you do if I were not here?"
- If the user really gets stuck you can gradually help. First with something with "where do you think could the [whatever] function be?" if this not helps in any way you can point to the solution so you can move further: "what do you think does this button do?"
- If the user forgets about thinking aloud just ask "What do you think at the moment"
Formulate your findings
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.
If you are in an early phase of your project you probably need to decide about very basic things e.g. if your users understand a new way of approaching a common task. In this case you need to decide which of some solutions you will choose. If you hear or see anything intersting and/or inspiering, write it down, because it can help you in your further desgn process.
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.
Improving your Product
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.