(a) Building the application
Your company has an idea for an exciting new product that you have bench marked, concept tested, usability tested, and even experience prototyped. All of the feedback is great, but you won’t know if your application is going to be a hit until real people are using it (and paying for it!) in the wild.

At this point you want to move very quickly by applying bare bone visual & low-level interaction design (using standard JQuery components, etc). The application won’t be as smooth & enjoyable as it could be (it hurts, I know), but neglecting these details allows your team to move fast and makes everyone more open to making dramatic changes to the application when necessary.

(b) Customers are starting to use the application
Using metrics and qualitative feedback your team will be able to assess what parts of the application are providing value to customers and what parts need to be removed or changed. Each time you add, remove, or adjust key features the application’s design will change and you will be glad you didn’t spend tons of time polishing a UI element that was later removed or modified. As parts of the application become solidified you should pay more attention to the detailed interactions and visuals, especially in cases where small changes can dramatically improve the user experience.

(c) The key features and overall design is solidified
Customers like your application, your feature set is a hit, and there is not a usability problem in sight. Now is the time to apply all of those cool low-level interaction and visual ideas you had. If customers found your application useful before, imagine how excited they will be when you improve the interactions and visuals so that every page is a joy to use.

At this point your team may consider adding more features instead of improving the ones you have. I know this is tempting, especially when customers are asking for specific features, but spending your time improving the low-level interactions and visuals is a sure bet because you are improving features that you know your customers are using. These improvements will also delight your customers, leading to lower attrition and great word-of-mouth marketing. And it could be argued that you probably don’t need those extra features anyway.

There are many interesting strategies of how to best integrate interaction design into Agile (working ahead, parallel contextual research track, etc.). However, most of these strategies focus on integrating XD processes with Agile processes, and overlook what I believe is the most important factor in successfully integrating UXD with Agile: building a great relationship between you (the designer) and the developers.

It might sound simplistic, but the times I have heard of UXD failing within an Agile environment, there was a riff or lack of communication between the XD contributor and the developers. On the other hand, the teams in which I have seen UXD flourish within Agile are ones where the team is united, just a bunch of people trying to deliver a great product. Here are a couple of tips I have found useful in cultivating a great team rapport:

• Compromise and pick your battles.
• Show you are a team player and make other people’s lives easier by doing the work no one else wants to.
• Be appreciative of the hard work the team puts in.
• Explain the rationale for design decisions in terms of user benefits.
• Create developer-centered specifications. Get to know your team and what they prefer.
• Take advice, feedback, and ideas. If a proposed idea won’t work, explain why.
• Let the team know their hard work is making people happy. Share the positive feedback from customer feedback and usability tests.

“The landscape as well as the city are both highly structured, and our existence is furnished with many different kinds of devices and technological systems. These are what instruct people in contemporary societies ‘how to live.’”-De Vries

There is a wealth of design and social science literature that suggests that the artifacts we use shape our thinking and living. That means that even benign things like computer interfaces, navigational structures, and information architecture have embedded values that inform us how to live and how to think. The problem is that, what is usable is sometimes at opposition to what we value. Here are 2 quick examples:

Example 1: Amazon Country Selection

On Amazon.com’s shipping menu, you have to have to specify what country you want your purchase shipped to. Currently the drop down menu looks like this:

The U.S. is on the top of the list, with the rest of the countries below it in alphabetical order. This arrangement has implicit values relating to world power structures, global business, and which customers Amazon values. On the other hand, if the majority of Amazon.com’s current customers are from the U.S., perhaps this arrangement was done in the name of usability. A more egalitarian arrangement would have all countries listed in alphabetical order, but this will slow down registration for Amazon.com’s U.S. customer base.

Example 2: CNN’s Top Navigation

Above is a screenshot of the top menu on CNN.com. How the information is categorized and what is in this top menu is full of values. Beyond that, just the order of the topics in the top menu has implicit values. Taking in to account research that people look at websites from left to right, and the left is more important, CNN is implicitly suggesting that Entertainment news is more valuable then Health or Living news. Using the same general content, I may re-arrange the menu to look like this.

As you can see, I rearranged the menu to put more emphasis on health and living, and less on entertainment. Although this may make the interface less usable, I made this change because I believe a society should value news on medical breakthroughs and education more than news on Britney Spears’ most recent break up. But who am I to tell people what they should value?

Usable Artifacts Are Not Value Free

So, should designers push their values on to people? The truth of the matter is, right or wrong, as designers we already do this with every artifact we create. Even if we create a product that fits exactly what the users ask for, we are still embedding a value, a value that re-affirms that status quo. Designers have to realize this, and take responsibility for the values embedded in their products. The phrase ‘I am just giving people what they want’ does not absolve responsibility.

Why Values & Usability Don’t Always Match

Ideally there would never be a conflict between giving people what they want and giving them the ‘right’ thing. But unfortunately, there often is a conflict. Here are a few reasons why:

Ideal World vs. Real World: The ideal world and the real world are often two very different places. (Amazon shipping country example) In the ideal world all people from all countries would have equal purchasing power and it would make sense for Amazon to list all countries in alphabetical order. In the real world, citizens from certain countries have much more purchasing power than those from others. Should the design reflect the world as it is or the world as we you want it to be?

Ideal Self vs. Real Self: The ideal me reads tons of interesting literature and volunteers at the homeless shelter. The real me is fascinated with Britney Spears and loves to watch The Real World.

Business Values: The values of the business don’t always align with the values of the people. (CNN Menu Example) Prominently featuring the travel section may be in CNNs best interest because they generate more revenue from ads within that section, but people who read CNN may not care about travel.

Different People: Different people have different values.

Approaches To Balancing Usability & Values

Balancing values and usability is a complex issue that I am only beginning to understand. At this point I am just throwing around ideas, but it seems as if there are a few ways to approach this balance.

Design for the User: Card sorting, user research, and testing tell the designer what to do and how to design. This seems to be the dominant view in the HCI community.

Customization: Customization takes some of the everyday values vs. usability decisions off of the designer and allows designers to believe they are creating value-free designs. Google homepage is a good example. Customization has its own set of values, like individualism, autonomy, and others.

Design for the Ideal: Design for the ideal world or the ideal self. This may lead to some serious usability/usefulness problems and your design may never be used. This is also problematic because people’s ideal worlds and selves can be drastically different from each other.

My main criticism is of these approaches is that ideas like usability, user-centered, and customization allow designers to believe they are not responsible for, and don’t need to reflect on, the values they embed in the design. By following user-centered procedures, and giving people what they want, designers believe they absolve themselves from responsibility for the values embedded in the artifacts. I see this as problematic.

In the end, I really have no idea how to approach this balance. So what do you all think?

Note: This entry was originally written for the interaction culture group blog. The original post (and comments) can be found here.

For example: Getting very lost in Old Delhi can be narrated as humorous incident befalling the clueless international traveler, a tragic incident that ruined a trip, or a challenge that the heroic world traveler overcame. Let’s say the person subconsciously decides, for various reasons, that this narrative will be a comedy. Because he knows it is a comedy, he makes the decision to buy cheap street food in an alley which will most likely lead to an awkward intercultural exchange and even more awkward bowel exchange. If it were a tragedy, he may not have eaten at the food stall, and the fact he was stranded without food would have added to his tragic story. Obviously, the actual process of defining the narrative is much more fluid and complex, but I simplified it for explanations sake.

So, what does this all have to do with Live Journal?

This funny cartoon, which inspired this post, illustrates the connection between experience narrative and Live Journal pretty clearly. Information communication technology allows our experience narratives to be recorded and shared in new and different ways. And this change in narrative communication then changes the experience itself.

I have not done any real research on this topic, but I find it fascinating. So, as HCI designers interested in experience, what does all of this mean to us? Any thoughts?

Note: This entry was originally written for the interaction culture group blog. The original post (and comments) can be found here.

In Gillian Smith’s intro to Designing Interactions she talks briefly about David Liddle’s view on technology adoption. I looked at this model, and Everett Roger’s diffusion of innovation model, to analyze how these models fit current technology adoption practices of consumer products.

David Liddle’s Technology Adoption Model:

1. Enthusiast – excited for technology and use technology for technologies sake
2. Professional – people who use technology are not the ones who buy it
3. Consumer – less interested in technology itself, and more interested in what it can do for them

Everett Roger’s Diffusion of Innovation Model:

1. Innovators – venturesome, educated, multiple info sources, greater propensity to take risk
2. Early adopters – social leaders, popular, educated
3. Early majority – deliberate, many informal social contacts
4. Late majority – skeptical, traditional, lower socio-economic status
5. Laggards – neighbors and friends are main info sources, fear of debt

One thing that both models have in common is early adopters. The two models define them differently, but in both cases these are the first people to buy your product (often at a high price point).

Technology products are traditionally nerdy, esoteric, and unstylish. They were rarely used to express the unique style and tastes of the consumer. An early adaptor would have to be an enthusiast (or interested in this type of new technology) and they probably would also have to be educated, venturesome, and informed. This means the person would essentially have to be a very early adopter by both Liddle’s & Roger’s standards.

As technology products become more integrated in to our everyday lives and they become forms of self expression and style, this adoption begins to change. Early adopters no longer have to be an early adopter by both Liddle’s & Roger’s standards. Sure, they still probably have to be educated, venturesome, and informed, but the interest in technology for technologies sake is no longer necessary.

This means that the demographics of early adaptors is changing and new technologies that double as status symbols, fashion accessories, or other forms of self-expression have much larger number of early adopters.

Note: This entry was originally written on 9/1/07 for the interaction culture group blog. The original post (and comments) can be found here.

Should products be designed to be ready-to-hand, or to be present-at-hand?
I believe that most software tools should be ready-at-hand so that the person using them concentrates on the content or task and not on the tool. Ready-at-hand is the state of most tools, until they break down, and I think that most of us don’t want to be designing tools that are constantly breaking down. I also see some relation between Heidegger’s concept of ready-at-hand and Csikszentmihalyi’s concept of flow. I think a tool being ready-at-hand is a prerequisite for someone to get in to a flow state, although just because a tool is ready-to-hand, does not guarantee a flow state.

On the other hand (ha ha), when something is present-at-hand, and breaks down, it allows the person to look at something as it is. This break down encourages critical reflection on the relationship with the tool. Example: “When my television broke I realized how much time I spent watching it and how much more productive I could be.” Another reason a tool might want to be present-at-hand is so that a person becomes attached to the product and thus less likely to replace it. Friedel argues that when a tool is always ready-at-hand the person cannot become attached to it because they only think of the function the tool allows them to do, and not the tool itself. Because of this, products that are present-at-hand are more valued and less replaceable.

So, this brings me back to my original questions: Should products be designed to be ready-to-hand, or to be present-at-hand? My answer is: it depends. But I don’t think that this ambiguity is a bad thing. Interaction designers can use the opposition between present-at-hand and ready-at-hand as a way to understand experience and as an aid for design.

The Breakdown Balance
If these concepts are going to be used by practitioners, I think one important issue that must be examined is the balance in creating breakdowns. Breakdowns are important to encourage reflection and attachment, but they hinder usability, flow, and enjoyment (at least temporarily). I think for interaction designers to successfully use these concepts in practice the key is to understand how to balance a breakdown so that the user can reflect or become attached without losing patience or getting annoyed.

Note: This entry was originally written for the interaction culture group blog. The original post (and comments) can be found here. Jeff Bardzell (my professor) clarifies the correct usage of breakdown in this post.