When working with clients we are often asked to “make it work like Google”, or “we want to do it like Amazon does”. These requests are understandable, because both Google and Amazon are really good at what they do. Google allows us to find information we are searching for quickly and easily, and Amazon makes buying stuff so easy that instead of going out to the store and buying something, we will wait the couple of days it takes to receive an item in the mail. It makes sense that a client would like to copy the success of either Google or Amazon, but just copying the features and interfaces of other sites is not necessarily a recipe for success. 

Amazon.com sells a lot of stuff. They sell a lot of stuff because they provide an amazing user experience; they have designed a system that facilitates users buying stuff quickly and easily. I buy a good number of items from Amazon.com every year because they have great prices, I can find what I want easily, and I am given a lot of information to make a decision on whether or not to buy a certain item. If fact, there are people who go to Amazon.com first just for the reviews even if they think they might buy the item somewhere else. There is no doubt that Amazon has created an incredibly useful recommendation system. 

Yet, just because this system is effective for Amazon, doesn’t mean you should copy it for your site. In fact this might be an incredibly bad idea. For example, Target.com uses leases Amazon’s platform for their own e-commerce site. Target’s recommendation system works in nearly the exact same fashion as Amazon.com. Yet, if you search for an alarm clock on Target.com, you will get a ton of alarm clocks that are rated very low (or not rated at all). If I were in the market for an alarm clock, I would be wondering why Target sells so many crappy ones. 

In his presentation, Spool examines why this system works so effectively for Amazon but tends to fail for Target. Amazon and Target.com both sold a few million copies of the popular book “Harry Potter and the Deathly Hallows”. Yet, if you look at this book’s Amazon page, there are over 3,000 reviews for the book, where the Target.com book page only has 9 reviews. It is obvious that Amazon users are much more likely to post review than the typical Target user. In fact, if you look at the quality of Amazon reviews vs. Target reviews, the Amazon reviews are also much more useful. Amazon reviews are often well written, detailed, and provide a lot of useful pro and con information about the product. Target reviews are typically shorter and contain less useful information than their Amazon counterparts. The fact that Target gets less review for each item also makes the reviews less useful. People are more likely to write a poor review of a product if they have a bad experience than write good reviews when they have a good experience. Thus, Target.com has a lot of alarm clock that are rated very low as not a lot of people are revved up to write a review of that new alarm clock they just bought. Amazon, on the other hand, typically gets a very large amount of reviews for its products. Since products on Amazon tend to get a large number of reviews, there is more likely to be high quality reviews of the a product on Amazon. A product with only 9 reviews on Target is not going to have the same reliability of information for a user to decide to buy or not buy a product.

So, the next time a client asks “Lets do what Amazon is doing”, remember that successful designs are always successful in a specific context. Copying another company’s successful design will not always bring the same success to your company. As user experience designers, it is our job to design the right system for the correct context. It is likely that your context is very different from Google’s or Amazon’s, so copying what they do is not likely to be successful for your situation. As always, informed design that takes into consideration the unique situation of the company’s business, users and technology will always win out over copying successful designs of others.

Last week, Jesse James Garrett gave the closing plenary speech at the Information Architecture Summit. At one point in the speech, he refers to the ongoing struggle in the UX community about definitions, boundaries and in-fighting between the many groups that form the UX community (mainly IAI and IxDA). This struggle has been evident on the message boards of these communities. One consistent point of contention in these discussions seems to be the disagreement on what our job titles should be.

Some say “you cannot design an experience”, therefore the title “User Experience Designer” is invalid and should not be used. Job titles such as “Information Architect” and “Interaction Designer” define two different yet related sets of activities, all under a single umbrella typically known as “User Experience”. Garrett contends that “There are no information architects. There are no interaction designers. There are only, and only ever have been, user experience designers,” and hints that the community should quit fighting about what we call ourselves and move on with designing and creating great products.

I, for one, am less concerned with the accurate semantics of what we call ourselves. “Industrial Design” isn’t concerned with designing “industries”, yet you don’t hear the industrial design community complaining about the semantic meaning of their title. Yet, the craft of industrial design has been around for around 100 years and is a well established discipline in the design of products. The title “User Experience Design” has been around less than 15 years, and her young age is showing in the contentious dialog we maintain among ourselves. Continuing the discussion, despite its often heated tone, is a good thing as it helps the community to define what we do.

Still, the marketing of our profession to businesses is suffering because of our lack of unified terms to label what we do. Because of the nature of our work, we DO get caught up in semantics and meaning of words. Yet, this can be detrimental in the long runs as it clouds the message we send to other about what exactly we do in the process creating products and services.

I am more concerned with how our profession is perceived by others. I believe we should decide upon a unified title for our profession and stick with it. “User Experience Designer” seems to be the term that most people outside of our profession recognize. Even if we cannot “design an experience”, we certainly are in the “user experience” business, and our designs do have an influence on what that experience will be.

I think it is more important that we have a recognizable title that represents the broad set of skills and specialties that encompass our profession. While we may do interaction design, information architecture, usability assessment, etc., “User Experience Designer” should be our branding. It is the name in which others recognize what we do. We should probably embrace it. The activities we perform under that title will obviously grow and change over time, and we should focus our efforts on continually creating and refining our craft. Yet, we should probably cease continually creating and refining our title.

Please read the transcript of Jesse’s plenary:   http://jjg.net/ia/memphis/

There are a lot of activities we engage in as user experience professionals. Usability testing and contextual inquiry are inputs we use to inform the design process: inputs because these are not design activities themselves. These activities certainly inform and guide design direction, but they do not create an actual product. So what do we mean by the term “design”, and what does “designing” look like in the context of “user centered design”?

Should we even be limiting ourselves to “user centered design”? There are other equally valid design paradigms, such as activity centered design (Don Norman, “Human-Centered Design Considered Harmful “) and “genius” design (Dan Saffer, “Designing for Interaction“ ) that are used to make successful products everyday. Activity centered design is a process where the activity (i.e., wash the clothes, watch a dvd) drives the design process as opposed to a user task driving the process. Genius design is a process where the skill and knowledge of the designer drives the design process. We often tout the Apple iPod as a case for user centered design, yet there was never any user centered activities involved in creating it. Apple is notorious for maintaining secrecy around unreleased products, so they don’t do user testing, user surveys, or any of the other activities normally associated with user centered design. Instead, they likely use a combination of activity centered design and “genius” design. So if user research is not the silver bullet for creating successful products, what is?

The common element to the three mentioned product creation paradigms is the word “design”–the key activity that creates successful products. You can interview one hundred users and still design a poor product. How can this be? Because the craft of design is a skill in and of itself. Someone skilled in researching and understanding users is not necessarily a good designer. Also, interviewing users isn’t an activity that actually creates a product. John Kolko, interaction designer at Frog Design, stated on a panel at the Interaction 09 conference, “You aren’t designing if you aren’t making anything.” Although this statement seems to minimize the skills and relevance of people who refer to themselves as “user experience” professionals or “usability” experts, there is an air of truth to it. I can design with no user input and I still end up with a product, sometimes a great product, if the designer is “genius” enough. If I skip the step of design and only perform user research, I have no product to show for my effort.

I contend that the craft of design is the common element that is required to create great products. User experience professionals should be emphasizing design and creating more time for design activities. Often we get caught up in the inputs to design, and then leave little time for activity of design itself. I believe that a focus on design and the activities associated with the design process is an important issue and is essential to the success of a product.

Design is What We Should Be Doing

The word design can be used in either noun or verb form. The noun form of design refers to the end product that is created, whereas the verb form of design refers to the path the person or persons take to get to the end product. It is this path that separates those who are designers and those who are merely re-arranging the furniture. Design isn’t invention, innovation or creativity. It is really a way of thinking, working and being. Design is working within restraints and compromising with other outside factors.

Design is about making choices. Every product we make has a history of choices that were made to move the product to reality. The way in which we make these choices is very important to the success of our final product. We don’t explore enough of the options that ultimately make up these choices, and this is where we primarily limit ourselves in the process of design.

If we agree that design involves a series of choices, then there must be options for us to choose from within the constraints of our projects. But, how many of these options do we explore before making design choices? I believe that we explore far too few options when going through the process of design. I have seen many projects where, after user research is complete, the team comes up with a singe design direction to explore and iterate. This is inadequate and typically leads to mediocre product. A better approach is to come up with five good ideas and, through the design evaluation process, discover a sixth (or seventh or tenth!) idea that is even better. Design should be about multiples, and not about going down a single path. There are potentially hundreds, if not thousands, of different ways to design something. If we only explore one idea, we are constraining ourselves too much and likely missing out on exploring and discovering other ideas that will lead to even better products.  Once we narrow down the five or six (or 10, or whatever the number may be) good ideas, we can then make choices as to what is the best solution. From here we can go through our normal process of testing and iteration to transform this optimal solution into the best design that it can be.

Sketching vs. Prototyping

There are two things we need in order to make design decisions. First, we need something to evaluate. We need to create something that represents an idea or some part of our product so that we may be able to evaluate its effectiveness in solving our design problem. Some people may refer to these representations as prototypes. Yet, prototypes are typically higher-fidelity product representations that behave in a way that is similar to the final product. Prototypes can be resource intensive and take a long time to build, so it is usually impractical to create 5-10 prototypes for evaluation purposes. This is where sketching becomes a valuable tool in the designer’s arsenal.

When we talk about sketching, we are not just referring to pencil and paper representations. The word “sketch” can also refer to a short play or comedy skit. Both of these definitions differ in medium, but are similar in message: both are used to tell a story. If we think about sketches in this way and apply them to other mediums, we can then expand the role that sketching plays when evaluating user experiences. We can tell a story about an experience with a pencil drawing, but we can also tell it by creating and arranging physical objects, or video taping actors performing a scenario. Whatever medium we use to produce such sketches, they should always tell a story and be quick to produce.

Bill Buxton’s book addresses the differences between prototyping and sketching. Buxton explains that the differences between the two activities using a continuum. Sketches are quick mock-ups that illustrate the experience of interacting with a product or service. Sketches are used to explore possibilities, provoke thought, and suggest behavior or functionality. Sketches are best when they are ambiguous, as the ambiguity tends to generate questions and criticism from the observers of the sketch. Ultimately, the value a sketch provides is not in the sketch itself, but in the conversation, criticism and evaluation of the ideas that occur when engaging with the sketch. Creating and evaluating sketches early in the design process gives designers the ability to evaluate many design ideas in a short period of time. Ideas are cheap– a small group of people can generate a lot of ideas in a short amount of time. Sketching allows designers to use a visual language to explore these ideas and quickly eliminate ones that are not viable for the final product.

Prototypes differ from sketches, as they are created to demonstrate the finalized idea for the product. Prototypes answer questions and demonstrate the behavior of the product. They are not a good tool for exploring ideas because they take a lot of time and resources to create. They instead are created to show a detailed rendering of what the final product will be. Prototypes are typically not made in multiples, but they are iterated to flesh out the details of the product before it is built.

A good example of a sketch from Buxton’s book is the idea of two people in different locations collaborating on a

whiteboard. What would the experience of two people in different cities or countries collaborating on a whiteboard be like? Creating a prototype of a system like this would likely be very expensive, requiring networked whiteboards and some type of audiovisual connection. But, an easier way to represent the experience would be to have two participants writing with dry erase markers and standing on either side of a large pane of glass. The two participants can see each other, see what each person is writing, and can communicate and collaborate together. By definition, this is a sketch. It is quickly and easily created (most Accenture offices have some sort of glass pane that goes from floor to ceiling), it tells the story of the experience, and the idea can be either adopted or disposed of readily. Prototyping this experience would be very expensive, risking time and resources on an idea that might be an awkward experience for users. The sketch allows us to evaluate the experience of collaborating at a distance without the cost of prototyping it.

Once we create sketches as described above, how do we know which ideas to keep and which to throw away? We must have some criteria for evaluating sketches to determine if the ideas will ultimately solve our design problems. Creating a set of heuristics based on business goals, user research, technical constraints, etc., is essential to the sketching/evaluation process. Without this set of guidelines, we have no way of deciding which ideas are getting us closer to the end product. This is where prior design research such as requirements gathering, contextual inquiry, personas, etc. come in. From all of the information gathered from this research, we come up with a set of criteria, or heuristics, by which we can judge our sketches. Then, during the evaluation of the sketch, we can refer to the heuristics and make design choices for the product.

Making Great Products by Designing Them

Prototypes are valuable tools for testing and iterating the final product, but they are a poor tool for generating and evaluating ideas. Sketching allows us to quickly generate a large number of ideas, and heuristics give us a benchmark for evaluation of those ideas. And, sketching allows us evaluate ideas early and often with low cost and effort. The combination of sketching and evaluating sketches against a set of heuristics is a powerful combination. User experience designers should be focusing on design activities such as sketching just as much as they focus on inputs to design like user research. Design is the activity that gets us to the actual product. Focusing on the techniques and methods of design is essential to creating great products for users.

I highly recommend reading “Sketching User Experiences” by Bill Buxton. He provides some great examples of sketching and he also makes the business case for why design is so important. Companies like Apple , Zipcar and Netflix are differentiating themselves in the market by focusing on design. In the future, companies will need to focus more on design to compete in the new design focused market place. Buxton’s book is a good place to begin exploring how a focus on design can improve the products you create, and sketching is a great technique for transforming the products you design from good to great.

I have a list of books that I have been recommending to people who are interested in becoming a user experience practitioner. The list below is a good starting place for a UE newbie who needs a place to begin exploring the vast amount of information that exists about user experience design.

This book was first published in 1988, and its contents are still very relevant today. After reading this book, I knew that user experience design was what I wanted to do. Don’s books are easy reads, insightful, forward thinking, and entertaining. Read all of his books, but read this one first.

Great overview of what interaction design is, and how it is practiced.

You’ll like Mike Kuniavsky’s broad selection of practical user research methods–presented clearly and usably. It demonstrates how to discover what is in users’ heads, and suggests how we might balance those considerations with business objectives.

Why software design is broken. Alan Cooper (former software engineer) explains why and what to do about it.

While “The Inmates are Running the Asylum” book tells you what is wrong with software development, this book tells you what to do about it in detail.

This is the only book I know of that focuses completely on UE deliverables.

A complete overview of what information architecture is and how it should be practiced.

Currently I am reading “Sketching User Experiences” by Bill Buxton. I am half way through it, and I am thinking I should add this one to my UE newbie list.

Sketching

Here is a common scenario: you are finishing up your user research and have plowed through all of the qualitative and quantitative data. You have a pretty good idea of the direction your design should go, so you sit down and begin wireframing. Yet, wireframing at this point of the design process is probably a mistake, as wireframes are not a good tool for exploring a large number of design concepts. Wireframes are good at outlining the details of a single design approach, and creating them tends to make you focus on the details instead of exploring multiple concepts. Instead of wireframes, we need a tool that avoids this unnecessary detail, allows for quick review of many different design concepts, reveals the best of multiple solutions, and gets everyone’s input and buy-in.

Quick sketches are really the best tool to use at the conceptual stage. They allow you to go through many ideas quickly and evaluate the good and the bad. Sketching also forces you to avoid unnecessary details, which only get in the way of creating a lot of ideas really quickly.

There are two types of sketching: exploratory sketching and refining sketching. In exploratory sketching, we are trying to produce as many ideas as possible. A tool the presenters provided for doing this was a 6-up template. The 6-up template is basically a blank piece of paper that contains six sections. For each concept you are trying to illustrate, you force yourself to come up with 6 completely different ideas. Often it is difficult to get more than a few ideas out, so tools such as word lists, inspiration libraries, and conceptual models can be used to spur ideas. Word lists are a list of interaction paradigms such as ‘according menu’, ‘rating system’, or ‘drag and drop’ that helps a designer to spur ideas that might not have normally been associated with the problem at hand. Inspiration libraries are a collection of images depicting different interface designs (see Peter Morville’s search screen Flickr page). You use these images, much like the word list, to spur ideas that you might not have normally associated with the design problem you are exploring. Finally, concept models allow you to define a problem as a range of characteristics. These ranges can be a linear spectrum, a 2 x 2 Cartesian chart, or a multi-celled grid. Defining design problems as range of characteristics allows you to frame the problem in a way that can help you visualize a design approach.

Once you have come up with six different solutions to a problem, you then begin to refine your approach by a process called refining sketching. With refining sketching, you take the best ideas contained inside of your six sketches and condense them into a single sketch. Here, instead of exploring as many ideas as possible, you want to focus on fewer, better ideas. A 1-up template (which is basically a single section version of the 6-up template) is used to refine these sketches into a small number of high quality ideas. On this template it is important to use line weight and shaded areas to create a visual hierarchy that emphasizes the ideas that you are trying to convey. Also, create interesting labels names to give your page and features context.

Sketchboards

A major theme that emerged throughout the conference was that ideas are not scarce or fragile, but they are actually really cheap. Generating of ideas is really easy. The challenge is going through these ideas and finding the best ones. Sketching allows you to do this, and sketchboards allows you to present these ideas in a way that is both visible and easily iterated. Sketchboards are basically a large piece of paper where you attach all of the 1-up sketches you create for your product/service. Sticky notes can be added to the sketch board to categorize ideas. Also, inputs to design such as your design tenants, personas, etc. can be added to create context around your concepts.

The purpose of these sketchboards is to facilitate conversation. Sketchboards should hang on the wall of your workspace, which will encourage people to discuss their contents. Wireframes tend to reside in files confined to our hard drives making them invisible to the rest of the team. Sketchboards are out in the open where they are easily seen and scrutinized. The visibility of your design concepts allows you, your team, and other stakeholders to visualize and discuss all of the ideas for the product/service. In addition to casual encounters with the concepts, formal design review sessions should be scheduled to evaluate the design direction with both the team and the client/stakeholders. During this session, the sketchboard is presented by the design team, outlining all of the concepts for the design, how they fit together and how the design inputs influenced the concepts. At this time, everyone is allowed to discuss, vet, approve, shoot down, question or modify any of the concepts presented on the sketchboard. The key here is to document this discussion on the sketchboard itself. When you are finished, your sketchboard should be filled with annotations outlining the resulting conversation around the design concepts. Writing directly on the sketchboard itself helps participants remember where and how concepts where presented and how the conversation affected the various designs presented. When finished, the design team has a clear picture of the discussion around each of the concepts, how they were successful or unsuccessful, and how to approach the next step in the design process.

The next step in the design process could be wireframing, or it could be more conceptual sketching. After the sketchboard review, you should have a clear idea if you are ready to commence with the detailed design or not. If there are still questions that need to be answered, iteration on the sketching and sketchboard exercise may be necessary. If you now have a pretty clear idea of the direction the design needs to go, then you are ready to begin the detailed design of wireframing.

Design Sprints

The great thing about the above techniques is that you can crank out ideas very quickly. In fact, it suggested that combining these techniques with an agile development process is a way to get to the ‘Good Design Faster’ goal. This quick design can be achieved by using a design schedule organized into five-day ‘sprints’. A five-day sprint might look like this:

These design sprints can start over the following week with the next round of design problems to solve. However, sprints also should only be held consecutively for three weeks. The intensity of these sprints tend to lead to burn out, so designers will need a week off to help them refresh for the next round of sprints. The fourth week could be spent tweaking and presenting the wireframes to the client, and also planning for the next series of sprints.

Conclusion

The goal of this process is focusing on having the right ideas at the right time, generating lots of ideas, and creating design activities that everybody can get involved in. Wireframing too early can pull a designer into details that are not necessary at the design concept stage. Sketching allows you to explore many ideas quickly, and allows you to involve stakeholders at the conceptual stage. By the time you get to presenting wireframes, your stakeholders/client is already familiar and has signed off on the design concepts contained in the wireframes. This helps to ensure client buy-in of the designs, and eliminates unnecessary work on wireframing the details of concepts that will not work or will not be accepted by the client.

So, get out your pens, your paper (both large and small), and begin sketching ideas for your next design project.

Thanks a lot, stoopid error message.

“I’m sorry, but we completely screwed up, lost all of your data, and have no idea why this happened. Have a nice day!”