The most difficult thing about UX design is not creating the experience, but making sure it gets delivered as conceived. Whilst it might be terribly easy to blame the developers, or worst still the client, the reason why delivery may not match the concept is a little closer to home.

A shared vision?

The truth is: there is rarely a shared vision or understanding of the end experience amongst all parties. This is not down to the abilities of the UX designer, but the way in which the experience gets communicated. We have come to rely on a set of tools and documentation that instead of giving a unified view, allows different people to project different outcomes from it.

So I found myself nodding furiously at Jeff Gothelf’s article Lean UX: Getting Out Of The Deliverables Business, calling for a more agile UX process less defined by the deliverables. We have trained clients to believe that the value lies in the documentation itself, demoting the UX to a sign-off phase. It means we disengage decision makers at the very point their input is most crucial.

we disengage decision makers at the very point their input is most crucial

Whilst we have been advocating this ‘rapid-prototyping’ approach for some time it does not remove the need for documentation altogether, but we do need to create a better understanding of its purpose and application.

Communicating the vision

Our stock-in-trade site map, wireframe and visuals are very poor at communicating the vision to a user or stakeholder, but are essential for documenting it. I link this to the electrical wiring diagram for your house. The electrician needs it, but you just need to know that all the sockets are in the right place.

Some document types and techniques are great for concepting, but not great for sharing. We need others to describe the user context we are designing for (semantic arguments aside see Helge Fredheim’s articles on Why User Experience Cannot Be Designed). Neither promotes the shared vision we need – although they are vital to making sure we understand the users’ mental models. This is where the interactive prototype, the video and the storyboard come in. They are real and give the reviewer a true picture of the end experience. It’s an approach more akin to the way advertising agencies and TV producers work and more in tune with the kinds of digital assets we are making now. It is only with this more accessible view that a proper assessment can be made as to whether the experience meets both the needs of the user and the demands of the business.

This is where the interactive prototype, the video and the storyboard come in. They are real and give the reviewer a true picture of the end experience.

Where has this come from?

As UX professionals we are used to working with closed, task based infrastructure systems, led by technology constraints or a CMS – basically desktop applications and websites. This is where the documents have evolved from, as they define and codify the closed system and how a user interacts with it. If this is the context we are designing within, then the more ‘traditional’ approach fits. It gives the blueprint needed to make sure that the end result is usable and fit for its purpose.

The thing is these infrastructure builds form a very small proportion of today’s UX output. The adaptive design of content-led sites and mobile or social apps needs a different approach. As does the creation of rich content. We also need to build a proper appreciation of how the UX reaches beyond the interaction with the technology or content itself, to interact with other systems and the physical world.

No one size fits all

The key, as usual, is in avoiding the one size fits all approach. It’s not about throwing out the tools and techniques we have honed, but knowing when and where to apply them. An ‘agile UX’ approach has a place in this but is not a solution in itself. We need a flexible, fluid framework that focuses on the specific experience, within the specific context, to bring the vision to life.

A new order

So perhaps we need to turn it all on its head. Perhaps it’s time for a new order where the site map and wireframes are the end, not the start point. Where content creation, prototyping and storytelling take point in a collaborative process that unifies the user, the designer, the developer and the brand in a shared vision.

Humans have a natural affinity for stories. We know this intuitively. When we’re trying to teach a child important lessons about ethics, caution and quick-thinking, we don’t work them through a series of Powerpoint slides on the subject in the hope that it will get our point across.

Rather, we tell them the story of Hansel and Gretel. Over the course of the narrative – as the siblings walk through the forest, dropping breadcrumbs, as they get taken in by the cannabilistic witch and then delay their transformation from youngster into dinner until they can turn the tables on their would-be murderer – the young audience engages, empathises, and learns.

Adults have a similar experience when it comes to stories. Whether it is the ancient oral tradition of encoding information about hunting or farming into folktales, or contemporary storytelling developments like management case studies, stories have a way of reaching us that mere description can’t match.

This cognitive resonance is what makes design stories a powerful prototyping tool. People can understand complex concepts underpinning a design more easily if they’re embedded in the narrative form. And there are even more reasons to use stories to prototype your design:

• They can be created right at the beginning of the design process, based on concepts and ideas. No coding or process engineering required – only brainstorming and a bit of writing time (although supporting user research efforts can be extremely valuable inputs).
• Used well, they paint a vivid, holistic picture of a future user experience in a way that users and stakeholders can engage with and empathetically critique.
• They provide context – in a story, the focus is not on the solution (eg a website), but on the users and how they go about interacting with it, to their benefit or peril.

And, incredibly importantly:

• Design stories create a mental “scaffold” for their audience. Once people have understood and embedded the user experience story, you can use that mental model to start adding in complexity. Discussions about business processes, technology, user interfaces can be tied back to the story, to help people make consistent sense of it all.

Planning an example speculative design story

Let’s look at how we’d go about using a design story to speculate on the future user experience – say, showing how some of the major technology and social trends we’re seeing today will change the world in the next decade. To plan out our story, we might first consider a few key storytelling elements:

1. Story coverage and size – what should the story cover, and how big should it be?

In terms of coverage, because the story is going to be speculative, I’ve decided to be a bit ambitious throw in a bunch of trends that I think will be influential in how we live our lives in a decade’s time. These are:

• Crowdsourced personal decision-making (asking your online social networks to help you decide on what to do, both in your personal and professional life)
• Social benchmarking (rating yourself against your online social networks)
  Augmented reality, bolstered by ubiquitous GPS usage (technology knowing where you are I a geospatial sense, and being able to “overlay” what you are seeing with additional information)
• Connected home appliances that are actually useful,
• Further convergence of many information devices into a single device (so that your smartphone, iPad, MP3 player, television etc all become functions of a single gizmo),
• Standards unification turning into integrated services across vendor siloes (so that your experience across the online services you use don’t fragment through the need to sign-on multiple times, duplicate information across services, not have access to data from service A while you’re using service B etc).
• Gestural and eye-tracking interfaces displacing (although not replacing) touch and mouse interfaces (getting UI’s off a screen and more integrated with natural interfaces like your hands and your eyeballs).

As for story size, I’m pretty confident that I can show how the world has changed by telling the story of a single, universal experience – waking up in the morning, and going to work.

2. The narrator – Who is telling the story?

Because the story introduces many new societal and lifestyle concepts, it’s important to focus on the protagonist’s thoughts, motivations and feelings, to help the reader quickly make a connection that will ground the speculative future being canvassed. To achieve this, I’ve decided to write in first person.

3. The protagonist – who is the story about?

I want to make the story about someone that the readers can at least somewhat identify with. So I’ve decided on a character who has certain types of common characteristics (25-35 age bracket, professional, urban, cares about health, relationships and appearance, tech-savvy) without making any of those characteristics come across so strongly that people who fall outside of the aggregate demographic will switch off to “owning” the experience that they’re reading about.

4. “Plot-driven” or “slice-of-life” – how is the story structured?

If I were writing a story about a specific service and its value to the protagonist, I might use a traditional plot-driven story with a beginning, a middle and an end, and where the protagonist faces a conflict that the service being designed helps him/her overcome to achieve his/her goal.

However, I am trying to show how life in general has changed as a result of an accumulation of trends. This makes me lean towards writing the story in the “slice-of-life” mode, where I can show a brief snapshot of a person’s life. I don’t need a plot, or too much context, or for the protagonist to develop over the story’s course – I just need people to give people a sense of what life is like in the “new world” I’m speculating on.

An example of a speculative design story:

So, taking all of that into account, here’s the speculative design story. Interestingly, I’ve had two distinct types reactions from people about it, which I’ll summarise with two actual quotes: “I want this now!”, and “Gee. It sounds like…a nightmare.”

This story could be told using many types of experiences as a basis – visiting a doctor, shopping for groceries, going to dinner. As long as the experience is one the audience can relate to and benchmark against their current state , it’s possible to scaffold the complexity and paint a vision that people can thoughtfully consider.

Regardless of the specifics of the story, the freedom that the storytelling form gives you means that you are only limited by your ability to imagine the world in a way where your ideas – as wildly ambitious as they might be – have played out.

Top image: Pawlowski

I confess – I’m for it. And I’ll go even further – I think “making it up as you go along” is one of the greatest, and most important processes of any age.

No great explorer set out with a detailed set of explorer guidelines. They adjusted and discovered.

No great inventor set out with a detailed set of inventor guidelines. They experimented and adapted.

No great leader set out with a detailed set of leadership guidelines. Leaders point the way and rally followers when their faith fails.

“Making it up as you go along” means that you recognize a good foothold on your way up a mountain and know how to take advantage of it (in other words, you understand your craft). But you don’t need (literally) a step-by-step instruction book (because you understand your craft). In software development terms, the “step-by-step” equivalent is a requirements specification. Kind of like paint-by-numbers for would-be Rembrandts who don’t yet know that method is incapable of producing genuine art.

As good as your tools?

One of the things I hate most about our industry (the web industry, the UX industry, the IxD industry, whatever), is the penchant for folks with too little imagination and too much process training, to force “development models” on us. We have “mental models” galore. We have “process blueprints” en masse. Sadly, we have a myriad of tools, but not always the proper skills.

There’s a Danish expression common to craftsman: “A worker is only as good as his tools.” Granted, good tools are critical, as is a good process. But tools represent the lowest common denominator. Even with the best tools, an idiot will make a mess of things.

Agile or ingenuity?

We’re still at the beginning of an era. The web is not yet 20 years old. We are very much making things up as we go along despite excellent pattern libraries and established best practices. Anyone who says we aren’t is either a liar or a fool. Unfortunately, in the interest of professionalism, many folks are trying to legitimise their existance by formalising their work processes.

The smart tool of choice these days for software development is agile. ‘Agile’ is basically a fancy term for making it up as we go along. Mind you, there’s nothing wrong with this. It’s a good technique used by the pioneers for whom oceans are named.

In the old, pre-computer era, we call this ‘flexibility’ and ‘having an open mind.’ ‘Talent’, ‘intuition’, and ‘ingenuity’ were also once keywords. When did we stop appreciating these abilities? We have, you know…

Now, agile development is being groomed for polite society (e.g. the clueless business executives who would have insisted that Columbus produce a map showing the exact passage to India before he had actually done his discovery work). But gosh, Mr or Ms Business Leader, agile isn’t Russian Roulette. It’s not going to cost a fortune – in fact, it will probably cost less than the idiotic “requirements specification” some overpriced consultant is going to talk you into.

Which leads us to scrum

‘Scrum’ is a term stolen from rugby (which follows a wonderfully make it up as you go along kind of gameplan). In the world of software development, scrum formalizes the informal iterative agile development process. The Scrum Master is a project coordinator who presides over meetings and shepherds the team based on a set of strictly defined rules. A formalised certification course during which potential Scrum Masters learn the basic rules and mechanisms takes several days. Why is scrum popular? Well, first, it’s not a bad process. Unfortunately, scrum can be a nasty weapon in the hands of the wrong people; business execs are often comforted by processes that are governed by strict rules. Particularly those pesky, unpredictable creative processes.

How to win the game? Stay loose!

It’s not that I have anything in particular against scrum, but I have a lot against creating gameplans that don’t allow for deviation or the unexpected voicing of a sudden brilliant idea that turns the whole project on its head. Good Scrum Masters know the value of exploring new directions. My problem is with the tyrants who blindly stick to this (or any other established process); who hide their own lack of talent and creative insight behind a veil of pedanticism and false authority.

Sorry Columbus, ignore this new world of yours. Remember, your job is to find a passage to India. What will you do between now and the next daily scrum meeting regarding this project?

How many of us slavishly follow our car’s navigation when we know it’s giving us bad advice? Very few – that would be silly. And how many times have we uncovered a blatant fault during the very first usability test? Does it make sense to test with several more respondents before fixing an obvious problem? Of course not – no matter what the test protocol may dictate.

Although I’ve singled out scrum, there are lots of other processes that can go equally awry. Many companies these days are busy trying to implement Toyota’s LEAN production system, often with disappointing results. Kaizen quality management (another Toyota development) can also go very wrong – and for the same reasons Total Quality Management, House of Quality, and Philip Crosby’s Zero Defects went wrong back in the 80s; too many managers let the process get in the way of the ultimate objective. Remember, the goal is the goal.

For every rule, there are myriad exceptions. For every battle plan, there are unexpected circumstances. For every process, there are fifty other ways to do things. So, my advice is to do what needs to be done, when you need to do it. And as to the gameplan? Don’t be afraid to make it up as you go along.

Have you ever needed a user manual to sit on a good chair? Probably not. When we see a good chair, we almost always know exactly what to do, how to use it and what not to do with it. And yet, chairs are made by the thousands, and several challenge these base assumptions to become classics in their own right. The chair is one of the most universally recognized archetypes known to us. In light of recent events in the mobile realm, I believe that the stage is set to probe notions of archetypes in the mobile space.

Archetypes

Archetype: An archetype (pronounced /ˈɑrkɪtaɪp/) is an original model of a person, ideal example, or a prototype upon which others are copied, patterned, or emulated; a symbol universally recognized by all. (wikipedia)

[Note: There is a deep philosophical definition of archetype as proposed by Carl Jung. This article is not based on that form of definition.]

The word archetype has its roots in architectural theory. It also deals with cognition at its most basic level. In a very generic way—points, lines and planes are archetypes in graphic design. Columns, walls, floors, roofs are archetypes in architecture.

When we see a flight of stairs, our cultural memory and experiences kick in. They teach us that stairs signify climbing, doors represents portals between zones and chairs are (usually) something you sit on. We seldom think much about them. Experience makes us learn, encode and remember these archetypes, making us react spontaneously to them. The degree to which archetypes are understood varies greatly between cultures. Interestingly, archetypes can always be deconstructed, challenged or probed since they merely act as starting points of reference. There are innumerable examples of archetypes that have been reintroduced to us in the most puzzling ways in order to question our own understanding of them; for example Escher’s illustration below, which turns the stair archetype on its head.

… archetypes can always be deconstructed, challenged or probed since they merely act as starting points of reference.

Escher deconstructs the chair archetype

Archetypes vs Metaphors

With all the press that metaphor gets in UX, it’s worth pointing our how it is different from the archetype. Metaphors are analogies between two objects or ideas, conveyed by the use of one word instead of another. In interaction models, metaphors are different from archetypes in the sense that they are the conceptual transference of an idea/archetype into another more tangible form that becomes more easily understood. The archetype is the original idea/model in itself.  An obvious example of metaphors in industrial design are when chairs are inspired by nature.

Tulip Chair inspired by an obvious metaphor

Further Reading on Archetypes

For more information on archetypes, the book Form, Space and Order by Francis D. Ching is a good introduction to archetypes in architecture (for lateral understanding). My graduate research thesis in architecture also dealt with archetypes, and it is this understanding that motivated me to seek and understand archetypes in interaction design.

Mobile UX Archetypes

Our ever-increasing mobile interaction with our World implies that we are creating, consuming and sharing content constantly on the go. We already have about 1 billion net-enabled cellular devices, according to the Hammersmith Group report on the Internet of Things. We’re checking mail, updating statuses, sharing personal data and browsing constantly using little computers in our pockets. Over time, one could expect a certain familiarity to set in with the different mannerisms and modes with which we find ourselves interacting. Can we look at a user interface and guess what it’s going to do for us? If the answer is a tentative yes, it probably means its interaction model is based on a common archetype.

Can we look at a user interface and guess what it’s going to do for us? If the answer is a tentative yes, it probably means its interaction model is based on a common archetype.

A few months ago, my experience of mobile archetypes at a macro-level appeared predictable. The iPhone and its subsequent ‘cousins’ seemed to be what you’d expect from a mobile operating system. Without any qualitative leanings to its effectiveness, the recent release of Microsoft’s Windows Phone 7 series and Kin phones inspired me to examine the differences in mobile archetypes that I’d encountered.

In the absence of academic definitions, one could define Mobile User Experience (MUX) Archetypes to be ‘prototypes’ that are or might rapidly become models for future everyday mobile interaction behavior. They are overarching experience patterns that we, the Mobile Generation, will have poked, prodded and swiped countless times during our lives. Over time, these interactions would most likely have formed cognitive roadmaps in our cultural memory, paving the way for more thought-free acts while using technology. We would expect interactions to occur in certain ways, and would be surprised and often annoyed when they would not meet our expectations.  When someone reinvents an archetype (like Facebook did to email), it makes us pause, think and readjust our behavior.

My criteria for selecting these archetypes were:

1. These are archetypes on the foundations of which a part or whole mobile user experience can be conceived.
2. Most exist out there on mobile devices, while others seem destined to enter this space soon.
3. They are mostly screen-based interactions (for now).

The groups and examples chosen are sub-sets as well as super sets. For example, Facebook is by itself a super-set of many smaller metaphors and archetypes. These would be subsets of the Facebook family, but might have UX archetypes of their own.

Archetypes as subsets and supersets

The MUX Archetypes I propose are:

1. Application Centric
2. Activity Centric
3. Timeline Centric
4. Context (Location) Centric
5. Process/Task Centric
6. Emotion Centric
7. People/Identity Centric

1. Application Centric

In such a MUX archetype, the applications make the interaction experience. The OS of the software are predominantly engines that can run and manage applications or ‘apps’. These ‘apps’ become the tools with which the device is made useful to us. App-centric OS’s like the Apple iPhone/iPad platform result in the interaction being likened more to a Swiss-army knife. The ‘start experience’ or the archetype that one is greeted with most while using these app-centric platforms are usually some form of smorgasbord of the apps that are on the device.

iPhone

G1 Android Phone

Samsung bada

(Examples: Google Android, Samsung bada, Microsoft Surface)

2. Activity Centric

In activity-centric MUX archetypes the focus shifts to the activities that one intends to perform with the interaction. The activities make the interaction experience. These are usually represented visually and placed in an easily accessible sequence. The most obvious example in recent times has been the Windows Phone 7 series, which advocated a direct ‘content-first’ approach. It mapped the most important activities of the user on its ‘start experience’, with a secondary emphasis on ‘apps’.

Windows Phone 7

(Examples: Windows Phone 7, Zune, the original iPod, Sony PS3)

3. Timeline Centric

Timeline centric MUX archetypes focus on time as a material. In these archetypes, the user is invariably manipulating, tweaking, dragging and experiencing data with time as a prime focus. The latest example is the release of the Microsoft KIN phones where the stripped user interface focuses on timeline centric features like the Loop and the Spot.

MIcrosoft KIN

The Whale Hunt by Jonathan Harris

Nike+ stats

(Examples: Microsoft KIN, ‘The Whale Hunt’ by Jonathan Harris, Nike+ stats, Mint, EDI monitors, MIDI-channel mixers etc.)

4. Context (Location) Centric

Contextual/location centric MUX archetypes ride the wave of GPS and its interweaving with social networking. In these archetypes, the user is invariably ‘checking in’ (or actually checking out) places based on GPS mapping and other ways of stitching locational data together. A great example of this is the Photosynth, which takes a user’s photos, mashes them together and recreates a 3D scene out of them that anyone can view and move around in. Applications like Layar use information about your location to augment the real world as seen through your mobile phone.

Gowalla

Photosynth

Layar

align=”alignleft”
(Examples: Foursquare, Gowalla, Photosynth, Layar etc.)

5. Process/Task Centric

These MUX archetypes enable a user to achieve certain tasks by describing the process in a sequential way. These archetypes invariably carry a ‘trail of breadcrumbs,’ enabling the user to journey back and forth through the process while following instructions. These archetypes would usually resort to a tying element of some sort during a process of educating the user. This thread would lead the user by the hand (or eye!) through the process.

20 minute meals

Popular Science+ iPad app

(Example: Jamie Oliver’s ’20 minute meal’ app, Tutorial section of the Popular Science+ iPad app etc.)

5. Emotion Centric

Jonathan Harris’ We Feel Fine project epitomize an emotion-centric interaction archetype. Even though this model has not (to my knowledge) been implemented on a mobile platform yet, it seems loaded with potential. Jonathan Harris describes the interface to the data collected on ‘We Feel Fine’ as “a self-organizing particle system, where each particle represents a single feeling posted by a single individual.”

We Feel Fine

(Example: ‘We Feel Fine’ by Jonathan Harris etc.)

6. People/Identity Centric

This MUX-archetype is most familiar with users of any social networking platform. Your identity and the identities of the various contacts in social networks to which you belong to are the prime focus for such an archetype. They are almost invariably centered around ‘status updates’ of some kind, leading to a stream of news about different identities.

Vodafone 360

Twitter API (as used in TweetDeck)

(Examples: Vodafone 360, Facebook, Twitter, Linkedin etc.)

Why do these archetypes matter?

It is not as important to debate the accuracy in grouping these archetypes as it is to imagine the possibilities of interchanging an expected archetype with another. Thinking in archetypes gives us a unique overview of interaction models and their intrinsic behavior patterns, making it possible to ask interesting what if questions and examine consequences. Archetypes and the overview they provide also help us critique experiential bottlenecks when they occur in designed interactions. Thinking laterally, if the form of a chair did not entice a user to sit on it, then perhaps the form or the formal archetype needed rethinking.

Thinking in archetypes gives us a unique overview of interaction models and their intrinsic behavior patterns, making it possible to ask interesting what if questions and examine consequences.

Our interaction experience of a product or service can vary drastically with the chosen archetype. For example, Twitter status updates are predominantly people/identity centric. What would happen if this archetype were to be inverted to say an ‘emotion-centric’ Linked-In? It might yield a very different experience of how our professional networks are feeling over time.

These are early days in the field of interaction design (especially in the mobile realm). Several MUX models are hugely successful, while most fail to remain relevant. The discussion regarding mobile interaction archetypes must be an ongoing, iterative process with a hope that experience models will mature and stabilize with time and refinement.

I believe that, in the near future, complexity, diversity and an almost ubiquitous presence of mobile interactions are certain. With mature, universal archetypes our designed interactions cold become more intuitive, leaving user manuals obsolete and making experiences more joyful for everyone.

——-

Images:

Escher print: Meridian ; Tulip chair: Design Heaven;  IPhone: GeekWhat; Android:  Blogoscoped; Samsung Bada: Gadgetvenue; Windows 7: All Touch Tablet; The Whale Hunt: Jonathan Harris via Andy Polaine; Nike: Electronica; Photosynth: Architecture Blog; Layar: Layar; Jamie Oliver iPhone App: CBS Interactive; Popular Science: 144Apps; We Feel Fine: We Feel Fine via Change the Thought; Vodafone 360: Geeky Gadgets; Twitter: The D’Alesio Blog

A few months ago we set up five Flickr groups around several UX topics. Every month we will try and make some sense of the uploaded material. This month we selected the UX Errors group and will look at examples of issues that arise when proper attention isn’t paid to two very important components of successful user interface design: Perceived Affordances and Designing for Task Flow.

Perceived Affordances

In The Design of Everyday Things Don Norman introduced many designers to the concept of affordances, which he would later clarify as “perceived affordances”, or the actions the user perceives as being possible based on how an object is presented. For example, if your design includes a “button” make that button look pushable.

Posted by Adam Connor

Push me. Wait… you can’t

The ATM example suffers from some misrepresentation. The labels for the physical buttons are styled with bevels, commonly used to represent buttons in GUIs. As a result, many users try to press them, only to realize after a few attempts that the buttons are actually to the right and left of each label. In this case, objects give off an inaccurate perceived affordance.

It’s not uncommon for ATMs to have physical buttons and digital label displays. In this situation, it looks like someone thought that adding a little visual “excitement” to the labels would be an improvement. If simple, plain text labels had been used, people would most likely have experienced less confusion.

Posted by Olivier Lorrain

Where’s the Button?

In the gas pump example people tended to press the octane number, as evidenced by the fingerprints around the “87″, when choosing a fuel. This happened despite the “Push to start” label on the actual button and the arrows pointing to them. In this case, there isn’t enough emphasis given to the real button in comparison to the large yellow square label. Which begs the question, why not just make the yellow square the button to begin with?

Posted by Andreas Popp

Which way is up?

In our last perceived affordances example, we have three components, all with a triangle/arrow pointing up, all beveled from the panel on which they are presented. Which one do you push to direct the elevator up?

The two arrows on the top are lights, which indicate the direction the elevator is traveling, while the lower button is the actual call button. Many users pressed the lights in order to call the elevator. Why? Most likely because the bevel caused people to perceive them as buttons. Also, the lights have a higher visual significance than the smaller triangle on the actual button. Had there simply been no bevel around the two lights, it’s likely there would be less confusion and more people would find the real button first. That’s not to say that the button itself couldn’t use a bit more visual prominence in it’s display too.

Designing for Task Flow

When I was in grade school there was an exercise we did where each student had to write instructions on how to construct a peanut butter and jelly sandwich. The teacher then attempted to construct the sandwich according to those instructions verbatim. If an instruction left something out, small details like removing a slice of bread from the bag containing the loaf, the teacher would stand there and act stumped until the student modified their instructions to be more specific.

The purpose of the exercise was to give students an appreciation of the fact that even simple tasks are comprised of a multitude of steps, and that finding the right level of detail and sequencing for those steps is critical to user’s success and satisfaction.

Posted by Eugenia Ortiz

Follow the Arrows

In the example to the right, there appears to be some attempt at sequencing in the digital display as well as from the large “2″ at the bottom of the device. In this case however, some considerate and/or frustrated individual(s) has taken it upon themselves to try to make up for the devices inadequacies by adding additional instructions and labels.

Posted by Frank Farm

Easy as 1, 2, 3

Our second example also uses numbers, in addition to a list of instructions, to provide guidance. Yet the arrangement of components and labels gives a perception of chaos that even a well written set of instructions can’t overcome.

Both of these interfaces exemplify that in user interface design, identifying a sequence of actions is not enough. Numbers and lists, while somewhat helpful, should be used in conjunction with a logical and sequential arrangement of controls and inputs.

Johnny Holland’s Flickr Groups

Observations are a critical tool in any designer’s tool set. They provide us with in-site on things we should do, shouldn’t do and could do better. Many of us photograph our observations to preserve them, to keep them as reminders, learning tools that won’t be lost in the background when our next big breakthrough comes along. We also share our observations so that we can learn from and educate others. So that we can build a stronger dialog and further conversation.

To that extent, Johnny Holland has established five Flickr groups, so that we can share, discuss and learn from eachother’s observations.

In addition to the UX Errors group, where we collect examples of design decisions that have a negative impact on individual’s interactions with a product and overall user experience, and from which this month’s examples were taken, we have:

• Daily UX: collecting pictures of everyday user experiences, good or bad.
• UX Sketches: collecting sketches of products, interfaces and ideas
• UX Patterns: collecting examples of interface and interaction patterns.
• UX Events: collecting photos from UX conferences and meet-ups around the world.

Like any collaborative effort, these groups are what we make of them. So please join, share your photos, comment and discuss. And if you have any ideas on how we can improve the groups or better utilize them, please let us know.

Style guides are a great way to ensure user experience consistency when developing an application and a way to communicate user experience standards across an organization. They can be application specific, platform specific, and may encompass enterprise-wide standards. A style guide can help make the development of user interfaces more efficient and help ensure good user interface design practices.

Types of Style Guides

Style guides for applications usually contain specific instructions on how to design and develop an application’s UI. In some instances, code snippets may also be provided to simplify development of the application.

Example of an application style guide specifying a web page template grid

Enterprise-wide style guides may include standards specific to an organization. These style guides may overlap with company branding style guides that are often defined by marketing departments. They can outline a variety of company-wide items such as standard colors, typography, logos and language.

Example of branding color definitions found in a corporate style guide

Platform specific guidelines are often tailored to a specific platform, such as desktop, web, or mobile. These style guides often give particular guidance on how to design for that platform, such as control and content guidelines.

Example of a link control definitions in a website style guide

The style guide you choose to create can be any combination of these three types. It’s up to you to figure out what makes the most sense for you.

Style Guides Are Not UI Specifications

Style guides are different from user interface specifications:

• A specification document details the functionality of a UI design for developers building an application. It is usually more descriptive and is often accompanied by wireframes that act as blueprints for the design. In contrast, a style guide is often a general outline of the elements of a UI design.
• Style guides have a longer shelf-life than specifications documents that are often tied to a project life-cycle. When an application is first created, some elements of the initial specification document might turn into the application style guide for long-term reference.
• Elements of a style guide may be referred to from a specification. For example, the functionality of a web application enhancement would be captured in a specifications document; but the operation of standard UI controls found throughout the website would be outlined in the website style guide and referred to by the specifications document.

How to be Successful

Over the years, I have had a chance to create a variety of style guides. The format and purpose of these style guides were variable and were suited to the task at hand: such as details of the grid layout, colors and typography used in a website and a general guidebook providing guidance on the use of website user interface controls and how to write web-based content. From these experiences, I’ve learned a lot about what makes a style guide a success and I’d like to share some of these tips with you.

1. Keep the audience in mind

Style guides can be written for numerous audiences (e.g. other user experience practitioners, developers, graphic designers, business analysts, etc.) and the content should be structured to match the audience. Graphic designers would benefit from knowing the colors used in a website elements and programmers may desire knowing the code used to create a control.

2. Plan for success

When planning a style guide, seriously consider what would make your style guide successful in your organization. Would it be ensuring your company understands how to better design usable applications? Or would it be ensuring the large-scale website you are creating has a consistent user experience? Or would it be something else?

3. Keep it alive

Documents produced in traditional document formats can become stale and quickly become outdated. Successful style guides are produced in a manner that supports easy maintenance and supports a living document.

4. Define a review process

Create a process that supports modification and review of the style guide to actively ensure style guide maintenance and buy-in. You may want to have a person or group of people responsible for periodically updating a style guide.

5. Think of the platform differences

Style guides can be platform specific or neutral. Design guidelines can be different depending on the platform (i.e. Windows vs. Mac, iPhone vs. Blackberry). Consider how you want to support communicating any platform differences when creating your style guide.

6. Socialize the document in your organization

The use of your style guide should be communicated throughout all levels of your organization to ensure everyone knows the existence of the guide, understands how to use the guide, and actively works to use and maintain the guide. The more people about your style guide, the more successful you and your style guide will be.

7. Clearly define mandatory and flexible standards

User interface design is part art and part science and user interface paradigms shift quickly. Ensure that your style guides support new platforms and creative ideas by specifying what standards are mandatory and what are flexible. For example, you may want to ensure certain usability rules are strictly adhered to throughout your applications (i.e. “Sans serif fonts must be used for text that will be read on a screen”), but be more flexible in other areas (i.e. “Radio buttons should be used when a user is asked to select one item from a list of items.”)

8. Make the style guide as scannable and searchable as possible

Style guides can be very dense and contain a lot of detailed information. Search and browsing capabilities will make it easier for people to find what they are looking for in your style guide. In addition, use as many visual examples as possible to support quick scanning of style guide elements.

9. Provide real world examples

Successful styles guides often show one or more examples from real applications for illustration. If you are writing a style guide for a specific application, use examples from that application to demonstrate your point. If you are writing a style guide for a large organization with many applications, ensure that your examples encompass all of the applications you are describing.

I hope you find these tips helpful when you are creating your own style guides. Do you have any additional tips you would like to share?

—–
Header image by nathanborror / /CC by 2.0

The Johnnies have asked me to write a monthly column about culture and concerns as they relate to cross-border user experience (UX), in Europe and beyond. This is an honour for someone born in Texas, USA (me) but probably seems odd to most everyone else (you). Let me share some background.

My father was Austrian. My mother’s family was German. The “Old World” wasn’t just a place in the memory of an aging grandparent and we certainly didn’t worship our ethnicity (as third- and fourth-generation Americans are apt to do). We travelled extensively every year (Rome and Florence were almost always on the itinerary). After university, I moved to Denmark to become a director at the Danish Royal Theatre and have remained in Copenhagen for 33 years. Here, I feel I’ve closed a cultural circle. Although our family tree has been pruned considerably, I’ve made sure the Reisses weren’t chased out of Europe forever. The Nazis have finally and definitively lost.

(Curiously, my father knew that he would never be returning to Vienna when the SS literally kicked him down the stairs of his gymnasium in March, 1938. Yet I have known since preschool that I was somehow destined to return.)

So what are you, Eric?

A New Yorker

Well, my work ethic is clearly Central European (I focus on getting the job done). My politics are decidedly Scandinavian (socialized and empathetic). But I also believe in the American Dream (bootstraps and the rewards of hard work). My temper is Latin (no idea where that came from). And as a Texan, I cherish cultural identity but reluctantly accept that I am part of something larger. (In comparison, New Yorkers don’t really acknowledge the rest of the world. The Steinberg cover for the March 29, 1976 edition of the New Yorker sums this up admirably:

As to language, I sometimes feel like the crazy monk, Salvatore, in Umberto Eco’s Name of the Rose. Salvatore speaks “all languages and none”. Returning from Geneva recently, I realized I’d muddled through in seven languages that day: French to pay the hotel and manage my airport check-in, Danish and Swedish to the SAS flight crew, German to my seatmate on the plane, English to an inarticulate taxi-driver of uncertain nationality, plus greetings to two of my neighbors – diplomats from Egypt (Sabaa’h el kheer) and Serbia (Dobro jutro).

So much for the long-winded introduction. I hope you’ll follow my cultural journey. And I hope I can justify the faith placed in me by the Johnny Holland editors.

Note: I tend to say “we” and “our” about Americans, Europeans, Texans, Danes, Germans, Austrians, Chicagoans, and eyeglass-wearers. Please forgive and bear with me.

What is “Europe”?

Listen to CNN and you’ll probably conclude that Americans think the European Community is a funny-accented version of the United States (and 33 years of empirical observation on my part suggests that this is exactly how they think). But we (Europeans) know this analogy only serves to make “Europe” easier to understand to folks who aren’t terribly interested in understanding us to begin with. I guess we shouldn’t really care, but hey – North Americans have their own “defining the damned thing” debate. We might as well have ours.

Let’s face it, “Europe” exists on a map, but nowhere else that I know of. Honestly, when are we actually “European”? – except when we’re forced into a convenient stereotype by another geographic group (Americans and Aussies, for example). Otherwise, we’re Danes and Poles and French and Italians and Greeks and Germans and Dutch and Belgians and Romanians and Brits (and you Brits really are a case unto yourselves – and irritatingly proud of it. The rest of us haven’t yet figured out how to tease you into submission but we’re working on it). How many nations are there in “Europe”? I can argue for about 40. (Or 400. Or even 4,000.)

Within each nation, there are incredible regional differences – a Dane from Himmerland sees the world differently than a Dane from Djursland. A Swede from Halland is different from one from Blekinge. Is Galacia part of Poland, the Ukraine, Austria – or Spain? In Zagreb, Croatia, they’ll tell you “The Balkans start on the other side of the river”. Dalmatia and Istra are Balkan; Slavonia is not. Most folks have never heard of these places. But that’s what makes Europe so exciting, right?

Granularity, European style

The most amusing case-in-point is that of the “Swiss” – you don’t really exist at all, do you? There are French, German, and Italian “Swiss” – but you stick together mostly for the sake of economic expediency, not because you like each other very much. And let’s not stop there – you further divide Switzerland into 23 states or “cantons”. And the individual cantons don’t like each other very much either. Now, these cantons also have cities – and here’s the punchline – in the city of Chur, there’s an old joke: “There are three qualifications for becoming Bishop of Chur: 1) you must be Roman Catholic, 2) your must be a consecrated priest, and 3) you must be a native of Chur (or at least from Kanton Graubünden). But in truth, the first two requirements can be dispensed with.”

The joke is, it’s not a joke!

The rest of the world wants us to act like a homogeneous group. But basically, none of us “Europeans” really and truly want to assimilate (you Swiss are just more up-front about it). Let’s face it, the more our nation-states become part of some larger global alliance, the more we cultivate our ethnic and geographical roots. In fact, this could be our common denominator. We are a group united by geography and mutual distrust – which is the surprising basis for many successful collaborations. We’ll put up with a fair amount of cultural diversity – as long as it doesn’t get in the way of our personal or national interests.

Don’t talk about the [war/food]

Our granular identity shows up in the oddest places. For example, here’s a direct transcript of a conversation between Northern Italians at an IT conference I attended a couple of years back:

Man from Piemonte: “My mother makes the world’s best Bagna Cauda.”
Man from Veneto: “Ahh. But but does she use Bianco Veneto?”
Man from Lombardia: “Well in Milan …”
Piemonte and Veneto in unison: “Shut up. You know nothing about garlic!”

Our politicians think that if they change the labelling enough, they’ll eventually describe the product correctly. Sorry, this is a tactic doomed to failure. Happily, no one cares very much. Throughout my years in Denmark, I’ve seen the political community move from (and to):

- The Common Market (CM)
- The European Economic Community (EEC)
- The European Community (EC)
- The European Union (EU)

Ahh…progress. Thank goodness for “search and replace”.

Anyway, let’s explore “Europe” (whatever that is) and examine how our user experiences play out across historical borders that represent more than just arbitrary lines on a map (hey, North Americans, look at all the razor-straight lines on your map. Then look at our map. This is why Nebraska and Bulgaria can never be equated).

Thanks for reading this far. Now tell me what your thoughts are.

Here in Drupal7 User Experience Project land we’ve been moving from ‘iteration zero’ to the actual production iterations. In iteration zero we’ve been doing a lot of our strategic thinking and documenting, but now it is time to start producing output that the developers who are working with us on this project can turn into something that will be contributed to the Drupal7 Project.

There is a real cadence to the project, and although there is no time in the schedule for us to take a breather, between you and I, it has been impossible for us not to do so (just a little), before heading back into the fray. I’ve noticed this effect a few times in agile projects and I think that I’m going to try to encourage project managers to allow for a little breather at this point in future projects I work on.

I thought I’d take a moment to share with you some of the other shifts that start to happen as we move from Iteration Zero into the Production Iterations.

Communication Framework: From Abstract to Concrete

As I’ve mentioned in the past, a big part of the time we spend on this project is spent either communicating with the community about the work we’re doing, our process and our ideas, or trying to work out a better way to communicate with the community.

One of the biggest challenges of the Iteration Zero stage in the project is that it is, by and large, a series of quite abstract and strategic discussions.

It is really easy to forget that many people find abstract and strategic discussions really difficult. I think there are particular types of brains that embrace the abstract better than others, but experience in this project phase is also very helpful.

In Iteration Zero there is often a lot of writing and talking and not much making/showing – this can create a very challenging environment for project participants. It is pretty easy for people to have vastly different interpretations of the same concept and it can be difficult to make sure that everyone is on the same page with the higher level strategy for the design and product. I’ve experienced this recently not only with the Drupal project, but with a few other projects I’m involved in.

Abstract discussions can be difficult to grok due to their predominantly conceptual nature.

It is pretty easy for people to have vastly different interpretations of the same concept and it can be difficult to make sure that everyone is on the same page with the higher level strategy for the design and product.

I can’t begin to tell you how many times I have explained and re-explained the very same concept, each time thinking that it’s been communicated clearly, only to discover that we still have at least two very different ideas about how something is going to work. There are at least two reasons for this: firstly I have to take responsibility for communicating – if the message isn’t being received I have to re-evaluate either what or how I’m communicating. We also have a second and somewhat unique problem when communicating with the Drupal community and that is that they have a tremendously strong mental model of How Things Work In Drupal. Every time an idea is presented the community almost invariably tries to map it directly to their mental model of How Things Work In Drupal – this is natural and what we *do* with mental models, but when the concept we’re suggesting actually breaks the model, we can run into trouble. It just doesn’t compute! It becomes abstract, difficult to understand, as we have to try to find ways to make concepts more concrete.

Iteration Zero can be a stressful time as a result of this abstraction – people aren’t really certain that they know what you’re talking about, but you’re also asking them to make decisions that will be really significant in shaping the product they’ll be getting at the end of the project.

I think it’s pretty common for people to be fairly fraught towards the end of Iteration Zero.

Thank goodness it is also around this time that something excellent happens – things start to become a little more concrete. There are still a bunch of abstract concepts that need to be agreed on, but as designers we’re also starting to get our heads around exactly how things will fit together and we can start to communicate that.

This is around about the time that we had a fundamental overhaul of the way we’ve been communicating with the Drupal community and interested onlookers on this project.

Towards the end of Iteration Zero we were starting to get a little down about the some of the feedback we were getting on the D7UX project – people were saying that they didn’t want to get involved because it was too intimidating for people who didn’t have UX experience and expertise, that they didn’t think it would actually happen or be a success, that they felt that the discussion was too disjointed and widespread.

It was clear to us that we needed to change the way we were engaging with the community to help them help us. Essentially, we needed to change the structure of the conversation from it’s abstract Iteration Zero format to a more concrete format appropriate to the production iterations, and, we suspected, to a format that most of our participants would find much more comfortable.

Over the course of a day, we created a ‘Project Framework’ on the D7UX site by breaking down the project into it’s main component parts and providing a wireframe, description and outline of ‘what we’re thinking’ for each part. Threaded comments allow people to give their thoughts on each component as it evolves over time.

Allowing people to participate in a place that is most comfortable to them is a key part of our communications strategy. We wanted to continue with this strategy even as we move into this new phase of the project, but also to aggregate the discussions into one place and to facilitate this we created a system of tags for the project components and put together a series of Yahoo Pipes to pull tagged content together. We added a link to these pipes on each of the component pages in the framework.

It was a pretty big overhaul and quite a time consuming process, but almost immediately we noticed a significant difference in the way that people were communicating with us on the project – the interactions became much more focussed and productive and felt a whole lot more positive, and that trend seems to have continued. It also makes it much easier for us to be more conversational with the community in the project – thanks to the simple addition of threaded comments and also the aggregation of the main part of the conversation into one place.

Overall, we’re really pleased with the effect that changing the format of the conversation from abstract to concrete has had on the project to date and the effort involved has already been rewarded.

The Challenge of System Design with User Stories

Another major challenge that we’re butting up against at the moment is to try to make a system design fit into an agile environment.

I’m a big fan of agile methodologies and have had a long term interest in finding better ways for UX practitioners to engage in agile methods. Unfortunately, there is no denying that pushing a design project like this one into agile iterations is tricky.

The way that our user stories are being developed at the moment is that the project manager from the developer agency (Acquia) is writing user stories then pushing them over to us to check that they are right and for us to adjust and re-order as required. To date, we have mostly let them sit in a large spreadsheet whilst we focus on the design strategy (iteration zero) and try to ignore the need for user stories.

We’ve done quite a bit of work on developing an Audience Matrix that allows us to take quite sophisticated ‘views’ of the design from multiple audience perspectives, but to translate this into user stories is untenably complex. The alternative to date has been overly simplistic. We are struggling to find a way to make good use of our audience modeling work to date without breaking agile.

Another issue that we’re butting up against is the nature of system design and templating in an agile environment. There are sets of design elements or template components that would ideally be designed in components then re-used throughout the project – for this project examples of these would be the admin header, the overlay window and the edit-in-place interaction model. Describing these using user stories is incredibly clumsy and inappropriate.

Once these elements are built and we start looking at user pathways that make use of them for particular tasks and outcomes then user stories will come into their own, but it seems that in the same way that developers need a piece of time to set up their development environments and databases without requiring user stories being used, designers need some time to get the ‘design environment’ set up without requiring user stories.

Again, this is something that I’ve come across on a number of agile project I’ve worked on but I’ve not seen any allowance for this way of working in Agile UX project methodologies.

If you’ve had similar challenges and some ideas or solutions then I’ve love to hear from you!

Update on Crowdsourcing Usability Testing

In my last update I was telling you about the Crowdsourcing Usability effort we had launched. Since then we’ve seen that WordPress have launched a similar campaign and they managed to get coverage in the New York Times no less, so we will be watching their progress with interest. Exciting times!

Launching Microprojects

Want to dip your toe in Open Source Design? Help out with D7UX? Well, here’s a great way to give it a try – sign up to help out with one of our microprojects! You need to commit just 12 hours over 3 weeks, but you’ll get a feel for what it’s like to design with one of the most vibrant and clever communities you could ever come across. Be warned, it’s challenging but potentially very addictive!

UX, experience designer, experience strategy … as far as words go, right now everything around UX design is still up for grabs. However, by focusing on the process ‘The Project Guide to UX Design: For User Experience Designers in the Field or in the Making’ by Russ Unger and Carolyn Chandler neatly sidesteps these sticky issues to deliver a fantastic handbook on the topic.

The (digital) experience designer

What initially struck me about this book is that, unlike other books that focus on techniques or the field, it focuses on the process and thus the role of being a UX designer (the UX of UXD, if you like). I haven’t seen a description of a UX designer before, and loved theirs:

Curiosity, passion, and empathy are traits that user experience designers share [along with] a desire to achieve balance … most notably between logic and emotion ….To create truly memorable and satisfying experiences, a UX designer needs to understand how to create a logical and viable structure for the experience and needs to understand the elements that are importance to creating an emotional connection with the product’s users.
- p6

Though UX designers can in theory do anything ranging from software interfaces to installations, the authors focus on “‘the design of digital experiences”. This specifically means websites (which they define as falling into six categories: brand presence, marketing campaign, content source, task-based applications, e-commerce, e-learning, or social networking applications), so expect chapters on SEO rather than interfaces.

A project guide, with all the realities

Ah, the realities of being a designer. Often many of the issues you have to deal with are nothing to do with design, and little things can make or break your project. This book goes a long way towards spelling out this reality. Along with the expected things you might read about (the different hats you have to wear, making up personas and wireframing), it covers less talked about topics such as writing proposals, dealing with team friction and what happens after a site is launched.

I have to admit I was surprised to find several pages dedicated to sloppy mistakes in wireframes. However, this attention to detail could well be justified, given a point made by UX designer Dante Murphy that inexperienced designers often suffer from “below par …. polish and aesthetic quality of their deliverables”. Other than that, I found all the other sections varied but relevant. I was however surprised that they didn’t touch on accessibility.

Read, browse, surf, snorkle, deep dive

‘A Project Guide’ achieves the difficult balance of being both a useful reference and easy read (even in such arcane moments as explaining the nuances of SEO). What’s more, each chapter is full of pointers to more in-depth resources (in case you miss the introductory text , they’re coded as ‘surf’, ‘snorkle’, or ‘deep dive’ depending on the length of the article) – including a paper by fellow Johnnie Steve Baty. Thankfully, they’ve put all the links up online.

The verdict

‘A Project Guide to UX Design’ is a must have for those starting out in the field of experience design as a brief but comprehensive guide to realising a web design project. For experienced practictioners, it’s a useful compendium of techniques and other resources. The only thing I’d add is a mention about accessibility standards.

Book details
A Project Guide to UX Design: For User Experience Designers in the Field or in the Making
author: Russ Unger, Carolyn Chandler
published: New Riders, 2009
details: 288 pages, softcover

Some while ago Don Norman wrote an article called ‘The Psychology of Wating Lines.’ In it he described how to make the necessary experience of waiting pleasurable. For the past eight months I’ve experienced quite some delays on the airport…. So I thought this would be a great opportunity for me to write how airports and airlines fail Don Norman’s methods to create an enjoyable experience.
For those not familiar with the work, I highly suggest you read it in full (pdf). To summarize though, Norman points out eight key factors to create a pleasant experience:

1. Emotions Dominate

2. Eliminate Confusion

3. The Wait Must Be Appropriate

4. Set Expectations, then meet or exceed them

5. Keep People Occupied

6. Be Fair

7. End Strong, Start Strong

8. Memory is More Important than the Experience

Let’s compare every one of them with my past experiences:

Emotions Dominate

No one likes having their luggage rummaged through by strangers, taking on and off their shoes, or being barked orders by a crackling intercom. On the plane, no one wants to breath stale air and have an infant with the ear infection across the aisle to them.

Add bright colors, XM Radio, and free TV and there is still no way to ease the pain of travel.

Eliminate Confusion

Norman states designers must create a clear, unambiguous model of the system in place and to notify customers of changes immediately.

Each airline attempts to do this with dozens of variations of signage: there is no consistency. Force the customer to check dated and glaring TV monitors for flight status updates and emotions quickly turn from annoyed to temperamental. Consistency is key. A lack of airline loyalty in exchange for price shopping creates hostility towards airlines at a time when people are already stressed.

The Wait Must Be Appropriate

I spend half of each day I travel waiting. Waiting in the car or bus, in line at security, at the gate, the tarmac, or the arrival gate waiting for a landing crew. Rationale reasons such as weather and security aside, the time wasted doing nothing is unreasonable. Individually accepted, the combined delays create an unacceptable experience. Why must I arrive at the airport early to avoid a long security line to sit and wait for the plane at the gate to then wait to take off? Airport: explain this to me.

Set Expectations, then Meet or Exceed Them

Why must I first give kudos to an airline that over the past few years increased estimated flight time in an attempt to account for expected delays? That being said, the arrival of the airplane means nothing as to when you will board… And the idea of being next in line to take off is relative at best.

Keep People Occupied

The need to turn of electronics fights this principle. I agree mobile phones should not be used in planes for the same reason they should not be used on buses, open train cars, or elevators. The original fear that technology will interfere with electronics has been generally debunked over the last few years (since initially drafting this article, some airlines have begun offering WiFi in-flight). With that in mind, we should be encouraged and not denied the chance to play on our PSP, Nintendo DS, or iPhone (airplane mode enabled of course). Norman discusses how filled time passes more quickly and this should be an easy fix for airlines.

Be Fair

My gripe with fairness and airlines has no obvious remedy as it is generally a matter of public safety. Still, cutting in lines to try to get a different flight back on schedule, circling in the air waiting to land, and the express security lane that is sporadically opened to the public all go against a customers mental model of what a fair action is. There is also no semblance of fairness to the customer delayed five hours, sees two flights pass him by to his destination, only to be sitting next to the two people from those flights who got paid to be bumped.

End Strong, Start Strong

This ties into the length of waiting in lines and unfilled time. The middle of the flight is the most entertaining portion of travel. We can use our electronics, get up and stretch and have some control over our bodies. Probably most helpful to the flight is the fact that customers are being given mental satisfaction they are en route to their destination. Now there is no possible way to change the order of events so much that the experience would benefit from putting all the useless waiting in the middle. We can however change the individual experiences involved with each.

Memory is More Important than the Experience

Make a list of things that describe an airline and you will come up with surcharges, delays, surly customer service and more. These notions and thoughts have developed over years of interacting with airports. There is no silver bullet to erase these memories and it is only time and small incremental movements in the right direction that will remedy this issue.

Conclusion

I can not help but feel a lot of the negative status the airlines get is a part of a self-fulfilling prophecy. Customers arrive expecting delays and poor service, and airline representatives are expecting disgruntled and irritated passengers. As the point about memory discusses, incremental steps are needed to improve the experience. While I believe Interaction Design has the chance to address the interfaces for airline employees and customers alike, I think there are easier steps to be made by simply providing more transparent communication with customers and willing to have a more open dialogue. Expectations are the key to all interactions and by creating an honest level of communication everything else will ultimately fall into place.