Thoughts on Interaction Design

Computer applications are not humans, they are ‘machines’, we all know that. Yet, they have a behavior, not always very human-like but it is a behavior. Applications show me things, they tell me things, they make sounds and they react in a certain way when I try to make them do something. We interact with each other as I react on what it tells me and vice versa. It is perhaps not always sophisticated behavior and it is perhaps better not compared to human behavior at all, but it somehow almost feels like you are interacting with a person.

So if we think about an application as a person, what kind of person would it be? Is it a rude person or a very gentle one? Is it a blunt person or very tactful person. Does it like me, or is it just doing what I asked? You may wonder why I ask all these questions. The main reason is that as a designer of an application we basically have the ability to determine what kind of ‘person’ the application will be and how it will behave.

Examples of application behavior

Let’s look at some examples and think about it in terms of behavior:

• An application that talks to me in capitalized text seems to be shouting to me. Not very nice behavior for most of us.
• An application that uses loud harsh sounds is not very subtle and can be perceived as rude, whereas applications that use swelling mild sounds can be perceived as gentle.
• An application that first lets me fill in a form and only when I press the ’submit’ button tells me I filled it in wrong is quite careless. It could have told me before and not let me submit things it knows are wrong anyway!
• Applications that tell me I made an error are patronizing. We people don’t make mistakes, but perhaps we misunderstood what the application was expecting to receive from me. Or perhaps there is an ‘issue’ the application wants me to deal with that I could not have known up front.
• Applications that throw windows promptly in my face are rough where as windows that fade onto the screen are far more graceful.
• Applications that require me to click on small things are intentionally trying to make me suffer whereas applications with pleasantly large buttons and links to click on care about me and take my own human limitations into account.
• An application that keeps on telling me about things I don’t understand such as error codes, format errors, compatibility issues is obviously more busy with itself rather than assisting me. A bit selfish perhaps?
• An application that keeps on telling me irrelevant stuff that don’t seem to impede normal usage is nagging.

Perhaps you are thinking I am exaggerating but then I urge you to look at the examples again and image it was a real person instead of an application doing these things. How would you feel then?

Application behavior and brand personality

When we design an application we usually want it to be a nice, useful and usable application that behaves well. Except perhaps for people who create viruses or other nasty applications. So as a designer we consciously want to control the way the application behaves. The application’s behavior is as good as the behavior the designer wanted it to have.

If you think about applications demonstrating a certain behavior, you could say they have a certain ‘personality’. It is a ‘designed’ behavior that is the result of the design and final impletation of the application’s user interface.  In the field of branding there is a the concept of ‘brand personality’. By ‘‘ we mean the set of human characteristics associated with a brand (Aaker 1997).  According to Aaker, the five core dimensions that make up the brand personality are:

• Sincerity (down-to-earth, honest, wholesome, cheerful)
• Excitement (daring, spirited, imaginative, up-to-date)
• Competence (reliable, intelligent, successful)
• Sophistication (upper class, charming)
• Ruggedness (outdoorsy, tough)

According to brand theory every brand has a certain brand personality, although it is often not clearly defined. In all communications the brand values and the brand personality should be reflected. This is what makes branding much more than simply defining the company’s logo, typeface and colour palette. The brand personality and the resulting behavior should be consistently communicated. This leads to definitions of tone of voice, layout principles, photography standards and so on. But that is all about non-interactive behavior, it does not say anything about how the brand behaves when you have a dialogue with it, just like you could have a dialog with a person.

What we need for Interaction Design to be ‘on brand’ is to translate, or define, the brand behavior when having an interactive dialogue between end-user and the brand, mediated by the application’s user interface.

Designing application personality

If we want to carefully construct a personality into an application’s behavior we need to know which elements of application behavior determine the perception of a ‘personality’. Here is a start of a list of things that determine the perceived application persionality:

Presentation layer

• Speed of interaction. Applications that are swift in their actions create a positive perception and they emphasize that everything is well within the boundaries of the application’s capacities. Slow is not necessarily bad but needs to be accompanied by sufficient feedback about its doings. When applications are perceived as unnecessarily slow it communicates disrepect and self centeredness.
• Alerting. The fewer alerts an application gives, the more reliable or trustworthy it seems. Alerts should be given at the right time and not be in the way of normal function if they don’t have to be. Otherwise they are a source of irritation and cause a negative perception.
• Gesturing. Things that appear gracefully and sublte (e.g fade-in) create positive preceptions where as sudden appearances or unnecessarily complex appearances (e.g sliding and turning) which are blunt or exaggerated.
• Strong visuals. Something in a big red box signals very strongly but usually the issue is not that grave and a less strong visual is more appropriate. Using too strong signals is normally perceived as creating unnecessary panic, therefore negative perception.
• Continuity. Usually people prefer the application to communicates in a continuous fashion rather than in staccato, such as when it seems to ‘hang’. We don’t want our application to stutter. Stuttering suggests that it is incapable of handling the users request whereas continuity suggests perfect control and capability.
• Visual layout. Screens or windows fille with elements and no use of grids are perceived as ‘messy’ and communicate a lack of ‘effort’. Apprently other things were considered more important. When screen are open, with pleasant spacing and good use of whitespace, the applications shows good decent behavior with a feel for etiquette.

Interaction

• Errors. When errors are entirely avoided the application must be smart and understanding for it never needs to tell me I did something wrong. If it somehow must tell me there is a problem it can tell it politely and constructive or bluntly and disrespectful. Applications that don’t do this are more distant and will feel more ‘technical’.
• Giving input. Applications that ask for a lot of data often use forms. Forms may create a negative perception especially when it is not clear why all the data is necessary for the task. Therefore, an application that asks the minimum amount of data and that is really necessary for the task is perceived as modest, unobtrusive and ‘light’. When applications even help us fill in forms by autocompleting what we type, the application becomes helpful and intelligent.
• Clicking. When users interact they usualy have to click on something. If click targets are large they are easier to click on. Click targets that are placed next to where they belong to create a stronger mental model and make it easier to use. Application that don’t do this are annoying and require me to repeat my efforts. Hence they are perceived as unsympathic, nerdy or techy.
• Feedback. Every time users do something there should be feedback to tell users about its doings and when it is actually done. See also last month’s article. Applications that don’t tell users what it is doing are somewhat mysterious. When it doesn’t tell users it is finished it simply rude.  Applications that give proper feedback are friendly, polite, informative and clear.
• Task optimization. Some tasks are often performed that others and even with the task there are certain defaults that usually apply. Applications that make the basic tasks easy are clever and intelligent. In contrast applications that make basic things difficult cause irritation and communicate arrogance and disrespect.

Functionality

• Prioritization of functionality. Some applications want to show all their functionality at once, some try to hide everything and some strike a perfect balance. Functionality for regular tasks should be at hand while less often used functionality or collateral functionalty can be hidden at bit, but be available in case it is needed. Application that have the prioritization spot on are perceived as very insightful and clever, but applications that get it wrong are perceived as either ‘ridiculously complex’ or ‘overly puristic’.
• Amount of functionality. Some applications really want to offer every possible function you can think of to end-users. Most users will only use a subset and usually the applies.  Applications that show only a clear subset demonstrate a focus, chosen with care and insight. When applications want to be everything to anyone, they loose credibility and show a lack of focus.

Content

• Tone of voice. Just as with offline communication, applications need a certain tone of voice. Online people tend to scan rather than read. Application that takes this into account communicate pleasantly and are usually quite concise. That that are lengthy and show a ‘wall of words’ communicate a lack of insight into the reader and its needs. They are perceived as formal and perhaps even distant.
• Data display. Displaying data is a precarious thing, has gone through great lengths to tell us that. So applications that simply show rows of text are taking the easy route. But applications that show insightful graphs communicate information rather than just data. That shows dedication and interest in why you need the information/data. In addition what I can do with the data is important. If I can set filters, timelines,  or change the type of graph I give full control to the users and communicate a thorough understanding of their needs.

Take your position!

Now that we have identified some aspects of application behavior that influence the perception of ‘personality’ the only thing left to do for any brand is to choose a position on each of the elements and be consistent in its execution. Then designers can apply the position in their work and hence design applications that are ‘on brand’.

One thing that needs to be said is that if you compare all of the aspects above to generally preferred ‘good usability behavior’ you could argue that the space to differ is quite limited.  That is probably true, but I think that the consistent application of the position can really communicate a clear brand personality. Just think about how Apple takes a position that is quite different from Microsoft or SAP.

So what about the brand(s) you design for? Is the behavior of your application ‘on brand’?

This entry was posted on Sunday, June 15th, 2008 at 1:29 pm and is filed under Theory. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.