Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

July 24 2012


Working on a Team as a UX Designer

User-centered designers aren’t just professional learners; they’re teachers, too. Our job is to reflect what we know while adopting the language of our end-users. This changes our team’s perspective which, in turn, affects its ability to solve design problems. Four ways that I’ve found effective to that end include: learning, brainstorming, (shifts in) perspective, and momentum.

When I was 11, my mother petitioned the local school board to advance my twin brother and me two numbered grades – sixth to eighth – in the middle of the school year. After months of discussion and debate, the board eventually acquiesced. One week we studied with our usual cohort and the next we were thrust into an environment wholly unfamiliar to us.

Kids in a classroom

History and English were the easiest to “get:” they were essentially classes in rote memorization. Science proved more difficult. Our eighth grade teachers introduced us to biology, geology, and chemistry. Hard sciences, indeed.

Mathematics was most the formidable, though. In my sixth-grade Arithmetics class, we reduced fractions and solved elementary functions. In Algebra, we sought answers.


I joined my eighth grade classmates at the precise moment when our Algebra teacher introduced Linear Equations. With it, we met a number of different concepts:

  • Cause and effect. In Algebra, X and Y were “variables” that could be related by something called a “function.” Any change in X resulted in a change in Y.
  • Change over time. The mathematical unit for change was called “slope” or “rise over run.”
  • Line graphs. Graphs facilitated spatial reasoning and reminded me of the old adage about a picture’s worth.

I’ll be honest: Algebra was really difficult for me. Not only because it was part of the “advanced” math program at my school (adding insult to injury) – it was an entirely new way of looking at the world. Variables? Functions? Change? I lost a lot of sleep.

As a class project, students were asked to prepare a “book of linear equations.” The idea was that, in creating and presenting their various books to the class, students would become better acquainted with the material it contained. It was a concept I was quite familiar with after several years of public schooling. The strange thing is this time it actually worked. After interpreting the material in my own words, I better understood what Linear Equations – what Algebra – was all about.

Learning is, almost by definition, a humbling experience. When we learn, we admit to ourselves that we aren’t “right” and that we don’t comprehend something as well as we could. Learning can apply to social systems (a.k.a “groups of people united with a purpose,” a.k.a your team), too. However, unlike conferences or classrooms – where people come together in order to learn – learning in the context of a social system can have unexpected consequences. Political scientist and thinker Donald Schon explains these in his book Beyond the Stable State:

The power of social systems over individuals becomes understandable, I think, only if we see that social systems provide for their members not only sources of livelihood, protection against outside threat and the promise of economic security, but a framework of theory, values, and related technology which enables individuals to make sense of their lives. Threats to the social system threaten this framework.

Donald Schon, Beyond the Stable State

Anything that challenges the values of a social system – teaching, for example – can incite what Schon calls dynamic conservatism. In other words, it’s difficult to get groups of people to change their mind.

If my entire undergraduate career in Mathematics taught me one thing, it was that although change is easy to model, it’s incredibly difficult to affect. Numbers are a great tool for modelling things, for measurement, but they tell us nothing about the ways in which (groups of) people think or act, nothing about how we might change their frame of mind.


But things are always in flux, right? Time inevitably passes so that the only constant we have is change. Design is simply the actions we take in preparation for change.

Brainstorming is a creative exercise that encourages people to suspend their judgement in order to conjure up solutions to a particular problem. It’s a technique often employed throughout a design project that bears much in common with improvisational theatre.

Say you’re Wufoo; you’ve got over 11 links in your header. During a brainstorming session, someone on your team suggests removing the Blog link. This person explains that users of Wufoo click the footer’s Blog link five-times-more often than the header’s. While it’s easy to see the fruits of this kind of labor – if you remove a link, it’ll make things cleaner – it’s what you don’t see, the assumptions guiding the exercise, that are arguably more important.

It’s quite possible, for example, that your team ignores a fundamentally better design. This happens because of what an ex-colleague of mine calls “being pickled in the brine.” After months and months of working together, team members form shared value systems. They see the world through the eyes of their peers so often that the suggestions they make today are not only informed by the suggestions their team made yesterday; they’re valued against them. If someone’s unspoken proposal seems superfluous when valued against the shared value system in which they reside, they’ll often (subconsciously) stifle it.

It’s an oft-misunderstood dynamic. While brainstorming provides a perceived “freedom of choice” to its participants, it’s likely not the same breadth of choice visible to someone outside of the system. This simple fact makes consulting possible.

In order to yield a better design, user-centered designers must facilitate new, shared experiences that form the basis of new value systems.


Artifacts of design carry with them an amazing capacity to impact the way we think and reason. Inventions such as Facebook, Twitter and Google – and, before them, Television, Radio, and Print – provided new ways for us to communicate with one another and, as a consequence, new ways to see the world. This might seem obvious, but that’s only because value systems are difficult to unlearn. For those of us who’ve grown up accustomed to modern communication technology, it’s difficult to imagine a time before these technologies existed.

Despite this, author James Gleick attempts to do so. In his latest book, The Information, Gleick tells the story of the human race as it’s adopted and adapted new communication technologies. Regarding the invention of writing Gleick says:

In our world of ingrained literacy, thinking and writing seem scarcely related activities. We can imagine the latter depending on the former, but surely not the other way around: everyone thinks, whether or not they write. But Havelock was right. The written word – the persistent word – was a prerequisite for conscious thought as we understand it.

James Gleick, The Information

This is an important point: before writing, thoughts could only be verbalized if they were to be shared. The invention of writing afforded us a prodigious capacity to capture and document; to share and scrutinize not only own own ideas, but the ideas of others as well. Things that aren’t documented – say a hallway meeting or a Skype chat – lack weight if they aren’t written down. It’s the same reason why my Algebra teacher asked us to create a book of Linear Equations: to facilitate conscious thought.

I began work with a startup early last year on a particularly thorny design problem. Before hiring nGen Works, their team had collaboratively designed and developed two different approaches to their application over the course of nearly 18 months. None of them worked. Carl Smith discussed the project at length with the stakeholders and, having decided that they had the capacity to learn, we agreed to work together.

In the usual user-centered design way, I began the project by listening. What expectations did everyone on the team have? What’s considered valuable? or not-so-valuable? Every time I had a conversation with a member of the team, I added it to an ongoing project journal:

For the first month of the project, I took 45 minutes each Friday to review what was said, what was implied, and where the team thought the project was going. What I learned was this:

  • Everyone had different assumptions.
  • Everyone had different priorities.
  • Everyone had a different idea of what we were building.

The first two issues were easily remedied: more communication (more of the same) would shed light on people’s assumptions and motivations. But the third? How could everyone have a different idea of the system being built, especially after 18 months? I began work on a concept map (something different) that pieced everything together:

It evolved over time into this:

I claim no talent as an illustrator and, thankfully, aesthetic appeal is not the point. Concept maps facilitate visual thinking. After presenting this diagram to the team, we began a new kind of conversation about the models behind the system, how things fit together, and what individual screens of the application really meant in concert with one another. This wasn’t the first time a diagram has helped me clarify things: a line graph was infinitely more intuitive to me than a pair of variables for learning linear equations, for example.

As user-centered designers, it’s our responsibility to constantly learn, assess, and represent (literally re-present) the context in which we’re designing.

At their core, designers are learners as well as teachers. The design process, for example, is something that’s been intensely scrutinized by designers in our field. We learn from ourselves. We’ve given a ton of thought to the various ways in which we collect and present data, and call them by a whole host of names:

  • Stakeholder Interview
  • Experiential Themes
  • User Story
  • Usability Testing
  • Analytics
  • Remote Research
  • Persona
  • Content Survey
  • Sitemap
  • Page Description Diagram
  • Card Sort
  • Design Dictionary
  • Mental Model
  • User Flow
  • Quick-hit List
  • Design Lab
  • Wireframes
  • User Flows
  • Storyboards
  • Prototypes
  • Photoshop comps

The goal of any of these activities or documents is to facilitate shared understanding: to clarify the solution to a design problem. But many people – especially clients who are new to the world of design – don’t understand how everything fits together. What good is our process if we can’t explain it in a way our clients will understand? To that end, I worked with my friend David Leggett to prototype an online documentation system:

The best part is there’s no boilerplate material here when it comes to “deliverables;” each bucket of deliverables is uniquely tailored to a client’s project. Further, each deliverable is linked to others in a way that helps clients see their relationships with one another. This is much more intuitive than, say, a 36-page PDF that presents deliverables in a linear fashion.

If a user is looking at a mental model:

and clicks one of the user personas at the top:

They’re taken to a screen that helps them better understand that user’s context. To practitioners, this web-based version of deliverables may seem redundant. To clients, it can be much more self-evident. Regardless of how you communicate with your team it’s essential that you do so – with both regularity and variety.


All projects have momentum, the rate at which they progress an idea. In classical mechanics, linear momentum is defined as:

p = m × v

Where p is momentum, m is mass, and v is velocity. I’d like to suggest that this definition can also apply to a creative endeavor. In the world of bits, mass is meaning. As the saying goes, “ideas carry weight.” Because developers call the-rate-of-speed-with-which-they-develop code their code velocity, a project’s momentum could be thought of as the product of its core idea(s) and the team’s code velocity.

Technical definitions aside, if a project “has” momentum, its team works well. A shared set of values pervade every decision. Conversely, if a project lacks momentum, either it’s being coded slowly or the idea(s) behind that project are in flux (or worse, both). Because clients pay for forward momentum, it’s critical that designers help determine the weight of ideas. To that end I recommend a combination of techniques I’ve discussed throughout this article: discovery, documentation, naming things, and availability. Let’s look at each.


Not everyone appreciates healthy discussion. Call it dynamic conservatism or just plain ego, some people have a fixed perspective. This is the bane of consulting. Therefore, an integral part of any design process is a discovery phase, which essentially centers around the following questions:

  • Am I / Are we capable of learning the client’s language? Their business? Their value system(s)?
  • Am I / Are we capable of explaining (teaching) my / our design process?
  • Am I / Are we willing and able to forego certain aspects of the project? my /our process?
  • Is the client willing to explain their value systems in a way that makes sense?
  • Is the client willing to learn more about their design’s context? In other words: are they willing to admit they don’t know everything about their problem?

Answers to these questions are never binary. Instead, they manifest themselves over a period of time. Before committing to any sizeable design project, set aside a small period of time to feel the client out. Ask the client what they’re looking for, make some progress towards that goal, but also explain to the client that you’ll approach their project in an exploratory way. After a month or so, re-assess these questions and see if this project feels like the right fit. For more information on this subject, I also highly recommend Andy Rutledge’s cost of services calculator.


As mentioned earlier, writing affords reflection. Although it’s tempting – and easy to forget – always ensure that conversation comes first. A great rule of thumb is this: don’t speak for people, speak with people. Because writing provides a sense of permanence, people often (incorrectly) believe that just because something is written or published it’s somehow more correct. Baloney. Whenever possible, ensure that documentation reflects the latest conversations you’ve had with your team. Documentation is never specification, just a point of reference.

Naming things

Similar to the concepts discussed in the Brainstorming and Perspective sections, naming gives us the power of distilling something’s essence. One example of this comes from the same startup I mentioned earlier. There, the client had a number of different visions for the mobile component of their application. Carl had the great idea to just call it “snap and send.” Effectively, the mobile app would take a picture and upload it to the website. Easy. After giving it a name, the mobile component of this application carried much more weight. The initiative gained momentum.

Another example of this comes from the movie Fight Club:

It was right in everyone’s face, Tyler and I just made it visible. It was on the tip of everyone’s tongue, Tyler and I just gave it a name.

Chuck Palahniuk, Fight Club

Those of you who’ve seen the movie might recall that, at this point, Fight Club is in full swing (no pun intended). Everyone wants to join. The movement had been around the whole movie, portrayed in counterculture snapshots and Palahniuk’s penchant for violence. After giving it the name Fight Club, though, Tyler Durden’s idea crystallizes and takes on a life of its own.

Make it available

Availability is empowering. Because Google, for example, provides a gateway to a vast amount of information in a fast, intuitive interface, people are empowered to learn new things. In a perfect world, our team’s design environment allows for that same feeling. To that end, consider:

  • Basecamp – If all conversations, deliverables, etc. are documented in one location, it allows your team to access the team’s collective knowledge, instantly.
  • Google Docs – Collaborative editing and commenting, in addition to notification settings, ensures that teams can come together around a particular idea.
  • Office hours – If possible, set aside an hour or two a week to just answer emails and be available for questions. Holding office hours empowers your team to answer design questions.
  • Roll your own – David Leggett and I prototyped a documentation system to explain our perspective on our client’s design problem. This makes a large body of knowledge accessible to a team and facilitates self learning.
  • Sketchboarding – This is essentially the physical analog of the digital documentation that David and I created. Being a tangible artifact gives it permanence and prominence within your office.

Be a good study buddy

Learning is an essential skill for any knowledge worker and, increasingly, we’re all knowledge workers. Designers have a unique skillset that allows them to work within their teams to facilitate both a self-learning and a shared-learning environment. This ensures that the projects they work on move towards the “weightiest” ideas in the fastest manner possible.

The post Working on a Team as a UX Designer appeared first on UX Booth.

July 17 2012


Five Tips to help Designers Find the Perfect UX Agency

Most UX designers I know aren’t masochists, but boy do they love chaos! Why else would they choose a field where, depending on where you work, a “matrix” could be a reference to content or Keanu Reeves? The fact is: unless they are the Che Guevara type, designers are often as good as the ecosystem and culture of their employer.

Consider the following scenario: your recent start up fails but you learn a lot about Lean UX along the way. Soon thereafter, you get a job offer to build the UX department at a major agency. However, at that agency, the project managers aren’t even sure what a task analysis is!

Introducing Lean UX there will probably take you a very long time (as will the cancerous growth on your UX soul).

Fear not, fellow UX designer! If you’re considering joining an agency, here are a couple of tips to make your search a little easier.

Don’t find a job, find a culture

A bacterial culture

Everything has a culture. What’s theirs like?

You can’t do it alone. Even if you’re Donald Norman. Does this agency simply want a voice in the room that can pull usability principles out of their hat during design reviews? Don’t work there.

UX designers need a culture that appreciates the vast, overlapping universe of experience design. Of course: unless you work at an Adaptive Path, IDEO or EffectiveUI, you’re most likely not going to find a place that are deeply knowledgeable about user experience. That’s okay. Perform your own gap analysis and understand to what degree the culture has a passion for learning user experience. That way, the majority of work you do will be focused on the client, not your team’s culture.

Look for receptive leadership

This is a big one. Get a sense of whether or not the leadership truly cares about the people doing the work. If you’ve ever seen Paths of Glory with Kirk Douglas then you’ll know what I mean. Disconnected leaders see their team mates as pawns used to advance their goals.

When staffing a project, does management take into account people’s personalities in addition to their skillsets? …or are they just checking items off a list? While managers should always care about profit, the best also care about their team’s experience. This kind of receptive leadership implies two-way communication. It means that there’s an emotional maturity in place so that an organization can course-correct by listening to (and acting in the best interest of) its members.

Next comes the leadership part. Will they say no to a client? This is key. If an account manager is told to “compromise for client happiness at all costs” then it’s unlikely that their agency can lead the client and help their team produce its best work.

Finally, does the leadership express core principles the agency must abide by? I’d settle for something like “we’ll never deliver bad work, no matter the timeline.” Regardless, ask them what they stand for. Next, see if they walk the walk: talk to their junior designers.

Ensure tolerance to uncertainty

My favorite quote from the Effective UI book is “intolerance to uncertainty is intolerable.” If only every agency I worked for had this chiseled in marble! A tolerant organization recognizes an essential and undeniable reality about good design: no solution is obvious.

A sword

Look for good values. The best agency will be steadfast on some issues and lax on others.

Do projects at this agency often begin without a signed Statement of Work (SOW)? This can happen when clients have an urgent deadline and/or when both sides “act on good faith.” In this case, the agency must communicate that work without an SOW is an investigation into what’s possible.

Next, note whether or not this agency explains working assumptions to their clients. If not, they’re vulnerable to scope creep and/or client bullying.

On the flip side, always avoid agencies that spell out every feature exhaustively. How can you find the best solution if the SOW already has? Without doing research there’s no way you can know what the best solution for a user should be.

Identify their process

Clients will always want work produced faster, for less money, and with more certainty. And while I feel for them (many have jobs riding on a project), agencies must do their part to both educate clients and earn their trust. A large part of that comes from managing expectations.

Scope is simply a measure of how much of their design problem a client wants to solve at any given time. Grill the agency as to what their scoping process is. Don’t look at the “cool” infographic they have on their website; talk to people on the ground and understand how plans come together.

Regardless of their actual methodology, an agency’s process should always protect the integrity of its design endeavors. Nothing wastes client money more than the internal kickoff in which someone says “what deliverables should we do?” The rest of the kickoff is then spent discussing how the design will be communicated rather than how design itself should communicate!

Look for checks and balances

An agency’s team dynamic should encourage cross-disciplinary collaboration and debate. Design is a human endeavor, making camaraderie critical. One person who’s only out to make themselves look good can take the whole thing down.

How does this agency handle conflict resolution? What if, say, an Account Manager and a Project Manager don’t get along? Does the agency prefers to “let people work it out?” That’s not leadership.

Alternately, if they run witch hunts in their post-mortems then they’re running on a culture of fear. No one department should be favored over another. All departments – including UX – should be treated with respect to ensure a democratic system of checks and balances.

In sum

No agency is perfect. No company. No client. No person. It comes down to intention, really: does this group of people want to transform human experiences for the better?

Any agency can become a great place to practice experience design. But you can save yourself a lot of heartache by interviewing your future employers with the same rigor and diligence which which they’ll undoubtedly interview you. In the process you’ll really learn why you do what you do.

The post Five Tips to help Designers Find the Perfect UX Agency appeared first on UX Booth.

Sponsored post

June 19 2012


Designing the Team Experience

A few years ago, the company I was working for ran recruitment for an entry-level position in which they asked applicants to email over samples of their work as attachments. Aside from the work itself, I was fascinated to see the different filenames applicants had chosen for their attachments. Most of them were named according to the project they had come from or were just called something like sample_for_companyname. Some, though, used names like theirname_jobrole_application. I had a good feeling about those ones.

Whether you’re sending a file to a friend, colleague, or potential employer, context is important. The project title might have been a useful file name to applicants on their own computers, but to us – stored in a folder full of resumes and samples – it was meaningless. The people who’d told us who they were and what the sample was for in their filename had given consideration to the recipient of their application.

“That’s the spirit,” I’d say to myself. They were thinking like UX designers.

The point of this story is that we spend a lot of time thinking about people in the experiences we create professionally, but not enough time applying these insights personally. Doing so can help us create with less friction as we function within our teams.

A powerful mental model

When we’re designing, we often consider our audience’s mental model – how do they perceive the world? Mental models are created from a mixture of past experiences and assumptions. Computer filing systems offer a classic example. Files can be grouped together and stored in folders. People get that concept pretty easily because – just like real life filing – it fits their mental model.

Icons help interaction designers communicate abstract concepts; how can we do the same?

Consider mental models when talking to your colleagues and clients, too. If we talk about ideas in a way that draws on what they already know, it’ll be easier for them to slot new information in alongside it. We can use analogies to show how what we’re doing relates to something they’re already familiar with. I was once working with a client who wasn’t following the difference between client-side and server-side code, so we started using a shop window/shop storeroom analogy, with reloads being like a trip to store room. It made the conversation easier for both of us.

It works it the other way around too. Elements of our clients’ business that we’re not familiar with can be baffling, so we can try to make sense of abstract or complex concepts by suggesting comparisons. We might get the comparison wrong at first, but that doesn’t matter – it’ll still get them thinking about alternative analogies that do work.

Plain language

Clarity is essential to good design. There’s not much point in something if people don’t understand what it’s for or what it’s trying to say. This applies to any communication with our clients and colleagues, written or verbal.

Keep conversations, emails and documents straightforward. Professionally, we’d never fill a website with long text, written in the passive voice and packed with jargon, so we can’t let that kind of language creep into our emails either.

Other people might do it sometimes – people often get a bit strange and formal when they’re writing – but their job probably isn’t focused on how the person on the other end will react, so they’ve got an excuse. We haven’t.

Add helpful headings

Another simple way we can make ourselves clearer is by making good use of subject lines in emails, section headings in documents and slide headings in presentations. In her book, 100 Things Every Designer Needs to Know About People, Susan Weinschenk provides the following paragraph without a header:

First you sort the items into like categories. Using color for sorting is common, but you can also use other characteristics, such as texture or type of handling needed. Once you have sorted the items, you are ready to use the equipment. You want to process each category from the sorting separately. Place one category in the machine at a time.

It seems almost meaningless – abstract sentences about sorting things into categories. Then she shows it again with the header “Using your new washing machine,” and it makes perfect sense. As Dr Weinschenk says, “Provide a meaningful title or headline. It’s one of the most important things you can do.”

Keep everyone interested

We often think about how we can grab users’ attention, so we know it’s not easily done. Keeping it is even harder.

One of the best ways to stir emotion and grab attention is to employ a story. Think about how often we see case studies on websites explaining how something worked. Think about how charities don’t just give us statistics about the number of people in need of our help, they tell us the story of one person’s individual struggle. Stories, especially with characters we can relate to, make things more real, more memorable. The need for a story is the whole reason we use personas to help the team focus on who we’re designing for.

We need to keep stories in mind when we’re making a case for a particular design option. We can use a character – usually one of the project personas or a research participant – and tell the story of how the character would use the product and how they would react to it. Using a story like this to make a case will be interesting and memorable, which means it’ll be a far more persuasive than relying on statistical findings alone.

Cater to wandering minds

No matter how driven and committed the team is, people’s minds are going to wander. Research by Jonathan Schooler has shown people’s mind wander even when they don’t notice it happening, so almost no one is going to have caught one hundred per cent of what went on a meeting or a phone call.

We need to make sure that we allow for wandering attention by always doing thorough recaps at the end of any conversation. We can send summary emails around the whole team and ask everyone else to chip in and add a note if anything’s missing. This takes the pressure off any one person, and stops vital pieces of information slipping through the net.

Recaps are useful for both informal chats as well as organised meetings. If you came up with a great way to deal with that navigation problem with your developers while you were waiting for the kettle to boil, send a quick round-up email afterwards outlining what you agreed upon.

Give people control

The self-determination theory says that people find autonomy and competence most motivating. We all like to feel that we are in control of our own lives, and that we’re developing our skills and capabilities. These things motivate us far more than any external influences like earning more money or fear of the rules. We also like to feel like we’re getting somewhere so we’re constantly on the look-out for signs of progress.

Increasingly popular websites such as Treehouse make great use of this theory. Not only are they giving users an opportunity to take charge and develop on their own, but they’ve grouped tutorials into badges, giving people something tangible to collect in order to track their progress. It’s not the badges themselves that people are interested in; it’s the sense of achievement.

Applying this theory to our team has obvious implications for anyone who manages or mentors others – give them plenty of opportunities to develop their skills and give them freedom and independence in their work – but we can apply it to our clients too. They might have come to us for a service but that doesn’t mean they want to lose control of their project, and anyway, it’s likely that they know their business better than we do. We can’t confuse providing a service with taking over. We need to find ways to work collaboratively and help our clients feel as much ownership of the project as us.

Be careful to keep them in the loop, with frequent, informal catch-up calls. You don’t have to wait for scheduled deliveries to get their feedback. Even if they don’t want to actively contribute at every stage (or if you can find reasons why their suggestion isn’t the best) they’ll feel like they’re valued if you’ve take the time to ask their opinions. Sometimes it can be tempting to save things up for a big reveal, but this rarely has the effect we were hoping for. Clients will automatically feel more strongly towards an idea that they feel they had a hand in, even if none of their ideas made it into the final design.

Put yourself in their shoes

This one’s last for a reason – it’s what all the others boil down to.
UX design is all about empathy. We spend all day trying to imagine what’s it like to be the user – what they would want to read here, which button would they press there – so it shouldn’t be too much of stretch get into the habit of imaging what it’s like to be in our colleagues’ and clients’ positions, and thinking about what will make the design process easier for them.

We know that good design isn’t about us – the designers – at all. It’s not about showcasing our skills, or trying to impress anyone. It’s about giving users what they need and want. This mindset can be applied to whoever you’re dealing with. Don’t focus on making yourself look good, focus on making the team feel good.

Turning design principles inwards

This article considers just a handful of the psychological principles that we use every day. There are plenty more that I could’ve included – just think of all the lists of heuristics and design guidelines you’ve ever read!

Those design principles aren’t based on what computers can do or how code works – they’re about people. Our colleagues and clients are people too, so we need to keep the principles in mind all the time – not just when we’re thinking about our end product.

Each time you make a design decision, think about the principles that guided that decision. Then think about how that same principle can be applied to your team to consciously create great team experiences. The better we can make the process of designing user experiences, the more people are going to want get involved and embark on their own UX design projects. And that means better user experiences for everyone.

The post Designing the Team Experience appeared first on UX Booth.

June 05 2012


5 Useful Lies to Tell User Research Participants

If you’ve ever run a research or usability test, you’ll know they can be tricky to facilitate. After all, you’re dealing with people; and people come with a whole host of existing preconceptions, personalities, emotions, and experiences. One thing that can help you to gain more honest and thereby useful feedback from research participants is, in fact, to lie to them.

Data is a sorted sort. Not only must it be properly contextualized and analyzed in order to bear useful information, it must also be collected and collated in a prudent fashion to begin with. Researchers go through this high level of detail to ensure the validity of their results. Dr. Marion Joppe of Ryerson University provides a more exacting definition:

Validity determines whether the research truly measures that which it was intended to measure or how truthful the research results are.

User researchers can increase the validity of their results in a variety of ways. Sometimes they conduct research “on-the-road” – known as
ethnographic research
– to interact with participants in their context of use. Other researchers go as far as recreating the environmental setting in which the product will be used. For example, if testing a television or video game, they might rearrange their lab to feel like a living room (comfy sofa, pictures on the wall, etc). If the product being tested is something that’s mostly used in the evenings, they might change the lighting in the room. If participants would often be interrupted while doing a particular task, the researchers might frequently interrupt their participants during the test. You get the idea.

In his 1994 paper
: Practical Methods for Testing and Improvement, Miles Macleod posited the following questions to aid the validity of research:

  • Are you looking at the right things to be representative of real-world use?
  • Are you collecting the right data and the right amounts of it?
  • Are you analyzing the raw data reliably?

The general consensus across these approaches – and Macleod’s questions – is that to increase the validity of a test requires scrutiny and planning. Though we’re all aware that planning is a good thing, what if you have planned accordingly, but you just want to ensure more worthwhile results? That’s where ly – err, deception – comes in. Two types of deception are commonly used by researchers to gather results with a greater degree of validity: active deception – in which participants are misinformed about certain aspects of a study, such as its true purpose – and passive deception when they are not made aware of certain aspects of a study.

It is often necessary to deceive users during research because giving participants complete information will likely change how they view what they’re doing, how they think, what they do and what they say. In turn the results are less valid. Robert Kerr provided a good example of this
back in March
known as “the Good Subject”; a respondent who – upon knowing the true purpose of the study – will be eager to say and do the things they think the experimenter wants, rather than what they would do naturally.

Anything we can do to uncover more valid results is a step in the right direction. To that end, here are a number of lies that you can use to obtain more valid results.

Tell them you had nothing to do with the project

“I’ve not worked on this at all so please feel you can be honest in your opinions”

Telling the participant you designed the thing they’re testing will very likely ruin the validity of the research. Non-confronters, people-pleasers, and aforementioned Good Subjects tend to go out of their way to avoid conflict and will therefore refrain from making negative remarks. Instead, they’ll be full of overwhelming praise even if they noticeably struggle on many of the tasks.

Even if you are the person who designed the product being tested, just omit that information. If they ask, lie. Say you’re not part of the design team at all; you’re just “a researcher.” In fact, even if they don’t ask, you’re better off denying any affiliation with the software whatsoever – they’re probably thinking it.

Play dumb

“I’m actually not familiar with this software so I’m afraid I can’t help you. Would you mind spending another minute on this task whilst talking me through your thoughts and expectations?”

Even if you deny having designed the product that they’re about to use, respondents will likely assume you know the product they’re made to use. If you’re asked to help, use your judgement and assess the length of time the participant has already spent on the task. If they haven’t tried long enough – and they’re not overly stressed – play dumb. This can often instantly refocus them. Another option is to state that you would be “unable to help them as in real life;” however, this implies that you do know how to complete it which can add to their frustration and performance pressure.

Still not sure what “playing dumb” is? The user may ask you “What should I press here?” To which you might say “What would you expect to press?” This is a good start, but you might increase the power of your response (in addition to switching the responsibility of the task back to the user) by adding, “I’m actually not familiar with this software so I’m afraid I can’t help you. Would you mind spending another minute on this task whilst talking me through your thoughts and expectations?”

Lie about the purpose of the study

“We’re just making sure that everything works as you’d expect it to”

By telling the user the true purpose of the study you risk contaminating the results. Research respondents will likely pay more attention and put more focus on any task they know you’re analyzing. This isn’t how they would normally interact with what you’re testing, of course. To keep their reaction as realistic as possible, it’s useful to lie about the purpose of your study.

Lying about a study’s purpose is one of the oldest tricks in the book, according to
Allan Kimmel
. His 2001 research paper found it to be one of the most common practices amongst seasoned researchers. Though it’s easy – even natural – to do, be sure you tell the truth after the the test has concluded. More on this later.

Lie about the number of people observing the test

“One or two people might pop into the room next door to watch for a bit, is that ok?”

User research sometimes takes place in a room with a two-way mirror so that the researcher’s client(s) can observe the test in an adjoining room. If there are lots of people behind the two-way mirror observing, don’t let the user know this or it will put them under immense pressure. When respondents know they’re being watched, they often feel pressure to say positive things and perform well.

Lie about how well they’re doing

“Oh, fantastic; that’s really useful!”

Speaking of performing well, some users – especially first timers or shy respondents – may need the occasional bit of reassurance and/or encouragement. A good example would be “Oh, fantastic; that’s really useful!” (even if it isn’t) whilst keeping your body language fairly neutral. This phrase can also be used to gain more comments from the user and can be very effective at helping users to feel more comfortable expressing what they dislike.

Lavishing praise might not seem like a lie per se, but it’s just as powerful. Give it sparingly. Overly positive reinforcement can actually encourage a very specific response from the user, leading to confirmation bias.

One important caveat

Okay, you understand the notion of research validity and you’ve got a bevy of lies you just can’t wait to tell. What’s the catch? Although lying can help you get more valid results, it’s very important that you don’t impinge on the ethical guidelines set by the APA (American Psychological Association):

  • Any deception must be justified in terms of significant scientific, educational or applied value that outweigh any risks to participants.
  • It must not cause physical pain or emotional distress.
  • The researcher must debrief the participant at the end of the session.

These ethical guidelines particularly apply to Lie #3. Always explain the true purpose of a study at the end of the research session. This should be done carefully to ensure the user is clear of the importance of the lie(s) and how telling the truth would have likely changed their response. It’s a good chance for them to further reflect and you may find that at this point, when the participant is relaxed because in their mind the research is over, some of the most useful insights can be gleaned.


Remember these are white lies that aren’t intended to harm the participant in any way. Using them can help participants feel at ease which encourages more honest responses and therefore higher research validity. You don’t need to use them all the time.

Before you put them through their paces, carefully consider the aim of your research and the impact of each lie. You may wish to just test out 1 or 2 lies until you feel comfortable. It may feel odd at first, but remember it’s for the benefit of both the user (to put them at ease) and the research (to gain better results) as a whole. When you notice the user’s posture or facial expression visibly relax, you’ll know the lie has worked well.

Are you ready to start lying to get more from your research? It’ll be our little secret!

The post 5 Useful Lies to Tell User Research Participants appeared first on UX Booth.

May 01 2012


How to Win the UX War Within Your Organization

When companies don’t care about user experience, it is clearly reflected in the products they create. Although everyone can agree that software should be intuitive, user-friendly, and aesthetically pleasing, many managers aren’t willing to invest the time and resources it takes to build something compelling. A large part of our job as UX advocates, then, is explaining design’s impact on the company as a whole. Determining which battles to win and which battles to lose – even intentionally – can help you win the UX war.

A scene from the movie 300

The war within your organization is probably not this obvious.

The nature of the battlefield depends, in part, on your company’s business model. I work in a business-to-business (B2B) organization which means that the products that my employer sells are primarily targeted toward other businesses. Business-to-consumer organizations, on the other hand, sell their products directly to consumers. They can obtain actual feedback from actual users.

In general, B2B organizations don’t receive as much feedback from consumers as business-to-consumer (B2C) organizations. For example, consider point-of-sale (POS) software systems used in restaurants. When selecting POS software, procurement departments for these organizations likely have very different sets of purchasing criteria such as cost, maintenance fees, existing vendor relationships, etc. Usability may not be an important priority when selecting the software outright.

And olde-time cash register

Cash registers are often sold to businesses, not consumers.

The problem here is that cashier feedback is at least two degrees of separation away from those who need it most. Without strong and consistent feedback from end users, it is unlikely the organization designing the POS software will recognize their own problems.

Another challenge that B2B software faces is that new software typically draws inspiration from existing software in the given industry. It is incorrectly assumed that because the current products are “getting the job done,” that they are models to be followed.

Every organization is different. The challenges you face in your company may not be the ones I face in mine. But hopefully my experiences in dealing with some of these complex issues might help you be better prepared for similar situations.

Battles you can (and must) win

In order to make an impact in your organization, there are certain key principles upon which you can’t compromise. Be confident and assertive when dealing with the following issues, but be sensitive to people’s perspectives as well. Remember that you need to build strong relationships with stakeholders now to support your cause in the future. As Howard W.Newton once said: Tact is the art of making a point without making an enemy.

Convince stakeholders that the problem exists

Sometimes business stakeholders are completely unaware of the issues that exist with their application’s user experience. Maybe nobody explained the application’s problems to them in detail. Or maybe someone did but it wasn’t very convincing or the consequences were not well understood.

One surefire way to prove a problem exists is to record users while they use the application. This technique allows candid feedback from the users, as you can see how they use the application first hand. Sometimes the results may surprise you.

If the user takes a different route – to go to a given page or to complete a certain action – instead of following the designed workflow, analyze why the user chose to take this path. Was the existing workflow not obvious? Was it cumbersome? Was it just easier to do it this way? The answers to these questions will help you gain insight into your users’ behavior & expectations. Some popular tools that can help capture this kind of feedback are Jing, Screenpresso, CamStudio, and Silverback.

Next, get the project team – including all stakeholders – in the same room and play the recorded user sessions. As a group, take note of various usability issues. What do they struggle with? Where do they make the most errors? Do they find the workflow confusing? Documenting even the most mundane problems in an application can get your stakeholders to pay attention to the application’s user experience.

Coming up with an agreeable solution

So you have demonstrated the problem exists; now prove a solution exists. Again, you cannot compromise here. Pick a specific part of the application that needs a makeover and build a high–fidelity prototype to demonstrate how it could be better. Be sure to communicate the difference between the complexity of the existing design and the simplicity of your new design. Some of the popular tools that can help in this area include: Balsamiq, Mockingbird, MS Sketchflow, MS Visio, and Hotgloo.

A wireframe

Help stakeholders visualize your solution by wireframing it.

Next, see if your end users like your redesign. The last thing you want is to get approval on a design that your end users don’t really care for! If possible, talk to a user or two to see what they think of your design and refine it as necessary.

Finally, present it to the team. This is a much better way to show the stakeholders how things can be improved from the current design and thus, get their buy-in easily.

Garnering support from the sales & support teams

In many B2B companies, the most knowledgeable people to talk to about real user feedback is the support team or help desk. These teams deal with angry and frustrated users every day, and can probably list the top five customer complaints off the top of their head! Be sure to incorporate the feedback from these groups in your design when possible.

Alec Baldwin says 'Always. Be. Closing.'

Sales people frequently have a unique perspective on your business.

The sales and marketing teams typically have a large influence on product design and development. Talk to them about the findings from the user sessions and the feedback from the support team. If you can convince them how your application’s poor UX is affecting customer adoption and is creating negative experiences with the product, they will join your cause. It’s hard for management to ignore a sales team that says Our product’s design is keeping us from meeting our goals!

Winning the numbers game

The higher up you go in the chain of command at an organization, the less they care about esoteric product details. Managers usually want to know how much will this effort cost them, how much will it save them, and how long will it take before they see results. These are not unreasonable questions to ask, so you’ll want to phrase the benefits of good UX in terms they’ll understand: dollars and cents.

Poor design inevitably impacts a product’s development and support costs but often this can be difficult to quantify. As a consequence, design is often seen as “subjective,” when you and I both know its manifestations are anything but. Luckily, there are several articles out there that can help you quantify the effects of user experience on the bottom line: Usability cost benefits evidence, Constructing a User Experience: The Cost-Benefits Compass, and Calculating ROI on UX & Usability Projects. Take a look, spend the time, and make the case for improving your application’s design in a language your stakeholders will understand.

Battles that are okay to lose (even on purpose)

So far we’ve discussed battles you have to win – but everyone knows you can’t win them all! Any strategist will tell you that knowing which battles to lose is imperative to winning the war. Let’s look at a few.

Finding someone to blame

Some people in the team will always point the finger at someone else – nothing is ever their fault. If the design sucks, it’s somehow the Project Manager’s fault or the Business Analyst’s responsibility. Or they weren’t given enough time to come up with a better design due to tight project deadlines.

An angry, finger-pointing monkey

Pointing out who’s to blame for the product’s poor UX will get you nowhere. In fact, doing so is counterproductive and can only lead to distrust. Instead, focus on persuading the team to join you in a fight for a redesign. Let them know that their opinion matters.

Looking for progress

Change is hard for most people to accept – especially when they’re skeptical about its effects. Yes, you’ve been fighting the good fight in the name of UX, but don’t expect everybody to get on board so quickly. It may take awhile for your colleagues to see the value in building applications with better UX.

Be patient. Gently ease your team into the process of taking the user-centric approach. Make sure the team doesn’t lose momentum. If they do, act quickly and step in. Help your team see the goal (separate the forest from the trees).

A tortoise, slow and steady.

Slow and steady wins the UX race.

Remember, you need everyone’s buy-in for this to work. Even if they are slow, as long as they’re steady and making measurable progress, you’ll win the war.

Becoming “that” guy

A badge that reads: Hello, my name is 'That guy'

Although I received overwhelmingly positive feedback on the UX initiative I started at my company, I also received some snarky remarks from a few folks. The truth is, I made a conscious effort to avoid highlighting any specific product or team because I wanted this initiative to be a positive experience for everyone.

Not everyone sees it this way, of course. Tell your colleagues that you appreciate the fact that they take pride in their work and acknowledge that you’d be upset too if somebody implied you did a poor job. Help them understand that you are just there to help.

Defining yourself

Hopefully your effort will be an eye-opening experience in your organization. Even so, that doesn’t mean that management will champion a UX team right away. They still may want to see how this will pan out in the long run. So in the short term, you may need to do some of the work “for free” on projects just to show them how things are done.

Get out of your comfort level a bit to take on a new role that you had not signed up for. It’s okay to lose the battle of defining yourself.

Don’t be afraid to wear a different hat if you have to. If you’re an IA being asked to do Visual Design, do it. If you’re a designer being asked to do some requirements gathering or user interviews, do it. If you’re a developer being asked to do interaction design, do it. Never forget that your ultimate goal is to win the war!

Win the war

In the end, it’s all about perspective. When you find yourself fighting any of the aforementioned battles, take a step back and try to figure out whether it’s worth the fight. Consider what’s at stake. What matters the most is that you don’t lose hope or momentum. Once people see the benefits of your effort they’ll start asking for more, and then quickly realize that they’re going to need a bigger team to handle all requests moving forward. And that is a good problem to have.

April 24 2012


Breaking Out of the UX Status Quo

As a UX Designer you’ve committed your career to helping people. You challenge the status quo everyday…but are you challenging it enough? How about with your deliverables? Your customers are people, too! Are your common deliverables – personas, sitemaps, user-flows and wireframes – really usable or are they just getting in the way?

It’s no secret to us: user experience designers speak their own language. From personas to user journeys, card sorts to wireframes, there’s a certain vernacular to our profession. It’s something that we learn over the years but that our clientele must overcome immediately.

Frustrated with the conventional deliverables used to communicate our work, I began to reconsider their presentation. What resulted is certainly not “conventional,” but – taken together – they are arguably more usable.

Personas are like resumés

Personas come in all shapes and sizes. Contrary to what they’re designed to do, however, rarely do they convey a good sense of the user. Most look like resumés: sterile and lacking in personality.

When was the last time you hired someone based on their resumé alone? Even with a resumé you still need to conduct an interview in order effectively gauge a prospect. Seeing someone and listening to their words reveals their personality – the key element missing from most personas.

So I started a searching for a better way. The first thing I did was move my deliverables online. This allowed me to link them together so that clients could click between them. For desktop projects I use Axure and for mobile and tablet I use Both of them are great tools as they create clickable, HTML-based output.

Next, I searched high and low for inspiration. This persona, created by User Insight, is definitely different. Therein, the user (Tina) does not consist of mere bullet points; she comes off as a real person. Jason Travis’s personas are infinitely more visual. Being picture-based, though, they lack any descriptive text whatsoever.

Inspired by these (plus adding my ideas and style) I tried to put together a new version of the traditional persona.

Barnabas's persona

You can view a demo here.

This approach paints a much more holistic picture of a person. Not only does it include their goals, it includes important, ancillary information such as their worldview, what they are looking for and their motivation. Further, the overheard conversation adds just the right amount of insight into his/her life. The “questions” section helps identify the areas the target user is unsure of and the “life pieces” section makes the persona human-like with feelings and desires.

Sitemaps are like spiderwebs

Sitemaps are (as most of you know) used to “map” the major components of a website to a rather sparse-looking diagram. Because they’re so sparse, they also tend leave a lot to the imagination. This gives rise to common retort: “What’s this page do, again?” “Can you change this page to that?” “How about we scrap that page”

You know the routine. Because clients come to us for the visual thinking they often can’t turn these sparse diagrams into anything “useful” on their own.

This got me thinking: why not just put the thinking alongside the map?

Barnabas's persona

You can view a demo here.

Even though it’s just a small difference, this approach pays off. It helps our clients understand the internal monologue that drives the narrative. Knowing the reasoning behind your decisions helps others understand (and agree) with your perspective.

User journeys are like electric panel diagrams

User journeys map the steps of a user, correlating goals (explained in Personas) with a site map to better illustrate how users will get things done. As a result, designers can make informed suggestions to the site’s information architecture.

The problem is that most user-flows are very dry. It is difficult to feel empathy with a user and their journey if all you see are boxes and arrows (similar to electric panel diagrams).

After scouring the internet looking for something better I found a couple of good approaches.

Jakub Linowski's user flow

Jakub Linowski’s Grand Narratives & Play Points diagram offers a compelling yet easy-to–understand presentation based on wireframes.

A user journey from the Bluepoint+ deliverable framework

Blueprint+ (Service Design Visual) is great because it includes the persona and a timeline.

Carlos Abler's user journey

Carlos Abler’s Multiuser WireFlows combines the two former ideas.

All of these are good but they all seemed to be missing something.

I’ve been always fan of recycling, so I thought there has to be a way to re-use the sitemap and display the user-flow on it. I also wanted to re-use my personas in order to create empathy for the user’s journey. This led me to the following presentation:

Barnabas Nagy's user flow

You can also view a demo here.

As you can see, I simply re-used my sitemap and added one of my persona with speech bubbles. In the speech bubbles I added the thoughts of the persona at every stage of their journey. This adds a human touch. The thoughts of the persona can explain to clients the reasons for the journey taken and the scenario puts these thoughts into context. It is simple but visually understandable way to show your user-flow.

Clients that already understand your sitemaps and personas will have no trouble seeing the two work together.

Prototypes/wireframes are like abandoned houses

Wireframes created in the absence of personas are broken. Yet we do this all the time. Why do we create personas if we don’t use them?

Looking for a better way, I saw a picture in the essay of Rósa Gudjónsdóttir:

A man working next to two cardboard cutouts of personas.

I was fascinated by the idea of having my personas around me. I started to print my personas and stick them to the wall in front of me. It helped, however, the screen and the wall are two different worlds, analog and digital. No good.

I eventually placed my personas in the margin of my prototype to serve as a constant reminder of who my users are:

A wireframe juxtaposed with persona avatars.

You can also view a demo here.

Not only does this help us to not design for ourselves, our clients and stakeholders are now constantly reminded who will use our design. The time and effort we put into establishing our personas is never lost.

Never stop learning

As I mentioned earlier, these ideas have helped me better convey my work to my clientele. They are not perfect, of course, nor were they intended to be. I am certain that it is possible to tweak them or in fact come up with even better presentations that work for you.

Are you also frustrated with common UX processes or deliverables? Don’t let the status quo get you. Always try to make things better, iterate and optimize. Surprise your users – err, clients – with something new and innovative as this is the way forward. If you’ve tried your hand at something different, be sure to share your result in the comments below!

March 27 2012


Better Experimental Design for Better User Testing

A horse

An ordinary Orlov Trotter horse, but is it capable of mental arithmetic?

User testing is a key part of validating design decisions, but what if the design of the test itself is invalid? As a researcher, being aware of the pitfalls that affect experimental design ensures your test will lead to elegant end user experiences.

In the late 19th century a horse known as Clever Hans astonished audiences with his ability to stamp responses to arithmetic questions. He did this with startling accuracy. His infamy grew until an investigation determined that Hans was, in fact, only able to respond to subtle cues in the body language of his trainer.

This phenomenon became known as the “Clever Hans effect” and highlights the potential for flawed experimental design to produce misleading research findings.

Never work with children or animals.

W.C Fields

The Clever Hans effect reminds us that the charming vulnerabilities and character flaws inherent in people make research design as much an art as it is a science. The following behaviors reveal more challenges that have faced researchers over the years plus some techniques for overcoming them.

Experimenter bias

In his 1979 paper, Bias in Analytic Research, David Sackett identifies a long list of bias forms that can impact the validity of research into people. Specifically, knowledge and expectations of the person conducting the test can influence the findings.

This shouldn’t surprise us. User testing is particularly susceptible as it tends to involve people that have an emotional investment in the project at hand. These project members take qualitative notes while observing a participant, after all.

To counter this bias, a user test should be conducted by at least two people: one person who maintains a dialogue with the participant; and an additional person who takes notes. In order to ensure a fair account of the test, the second person should be someone that’s not directly involved in the project but rather someone briefed to capture feedback as they receive it.

The Hawthorne Effect

Alt Desc

Under test conditions a tardy workforce can become a hive of activity.

It’s not just the person running/recording the experiment who’s likely to exhibit bias, though. Researcher Henry A. Landsberger found that, while workers don’t become more productive in different light conditions (as was hypothesized), they do work harder when being observed by a team of scientists.

This relates to a strange habit a lot of researchers seem to adopt. We send out invitations to a “User Testing Session” and the first thing we explain to our participants is that we’re testing the application not the user. Why not just call the session something else? This is probably the smallest change that can have the greatest impact on validity.

Better alternatives might be:

  • Application test
  • Application review
  • User research
  • Research study

Benchmark first

The Hawthorne Effect tells us that people feel self-conscious when being watched. Lucky for us, it’s relatively easy to observe people from afar by performing remote research and/or web analytics. If conducting an in-person study is the only way to go, though, the Hawthorne Effect can be better neutralized by first benchmarking the task.

For example, let’s imagine we’re testing our new website selling shoes. We want to examine the findability of products but we don’t have any definitive analytics. We do, however, have stats for how long it takes to complete registration. Although we’re not particularly interested in registration in this test, we could begin our tests by asking users to register. Then we could compare the time it takes users to register in-person with the time measured via analytics. The comparison lets us calculate a variance which can be applied to the rest of the research findings.

Demand characteristics

The Hawthorne Effect is just one of a variety of “demand characteristics.” This term refers to the tendency for participants to form an interpretation of the desired outcome and try to conform to or rebel against that vision.

Weber and Cook (1972) identified 4 personas to capture the tendencies of test subjects:

  1. The Good Subject – keen to give the experimenter the data they’re after
  2. The Faithful Subject – honest despite anticipating the expected result
  3. The Negativistic Subject – determined to give contrary data
  4. The Apprehensive Subject – awkward and keen to give the socially desired response

Let’s briefly discuss how these personas can affect your research.

Screw you!

An angry looking goose

“Screw you buddy!” Some participants will intentionally sabotage test results.

Persona #3, exhibits the “Screw you effect” that can be observed when inviting members of a team to participate in the test of a competing product. The solution to this problem lies in figuring out how many people you need to include in order to push these side-effects into insignificance.

Jeff Sauro provides a Sample Size Calculator for calculating the number of subjects required to produce data that is not just significant but can be extrapolated with confidence. Although this tool is not designed specifically for overcoming demand characteristics, considering the recommendations should give you a better idea of a suitable test sample.

A “Double blind” approach (intentionally misleading proctors and participants as to the purpose of the test) can also dissuade subjects from guessing the desired outcome. In the example of the online footwear store it could be claimed to unsuspecting users that the site is being assessed for load performance. This would suggest that the tasks were truly designed to test the site, not the users themselves.

Mike B Fisher’s article ”Meet the Respondents: Understanding User Personalities (Part 1)” offers more insight into the range of personality types you may encounter, and Part 2 of the article suggests further ways to neutralise the threat.

Attitude polarization

A herd of sheep

Given the opportunity, test subjects tend to adopt herd mentality.

Solomon Asch’s conformity experiments of the 1950s reveal just how powerful the responses of other group members are during a test. Asch used a double-blind approach by placing a test subject within a group of actors playing the parts of other subjects and asking the group to respond to simple visual perception tasks. The stooges would unanimously give the incorrect answer, often perplexing the genuine subject and encouraging them to conform.

The tendency to conformity in our society is so strong that reasonably intelligent and well-meaning young people are willing to call white black.

Solomon Asch

The herd mentality is a strong human trait. Conducting user testing sessions with large groups in a shared room makes it very tempting for subjects to mimic the feedback of those around them. The HiPPO effect (Highest Paid Person’s Opinion) can further entice people to agree with their seniors’ comments.

Ideally, test sessions should be run back to back, assuming this is consistent with end user environmental factors. In cases where it is unavoidable to test a large group simultaneously, randomising task order can help alleviate this problem as it limits the extent to which people will overhear responses to the task they’re working on.

Order effect

A parrot

Participants will perform better at a specific task with practice.

The order in which tasks are performed can effect the results, as users will often perform better as their familiarity increases. This is called “order effect”.

Our user test of the online shoe store is susceptible to this effect. Take a series of three tasks:

  1. Browse shoes
  2. Browse special offers
  3. Search for accessories

We may observe users having difficulty with local navigation on task 1 but no issues with similar navigation in tasks 2 and 3. In this simple example, it would be naive to think there was an issue with local navigation only when browsing shoes. In some cases this is less obvious.

The solution is to randomize the order in which selected tasks are presented. In preparation for a face-to-face user test this can be easily done by printing each task on a separate piece of paper and manually shuffling. Of course, tasks are often contextual so careful consideration needs to be given to which tasks can be shuffled.

Some tools have this feature built in. For example, Survey Monkey, used for unmoderated testing includes an option to randomize questions automatically.

Funding Bias

Behind every research experiment lurks a project sponsor, and their allegiance may lie closer to financial considerations than to objective interpretation of findings.

Turner & Spilich (2006) reported that research studies funded by the tobacco industry were more likely to conclude that smoking improved cognitive performance than those undertaken by independent researchers.

No matter how a user test is conducted the findings are open for interpretation by people who are rarely objective.

UX consultants may be inclined to find more major issues in order to justify their day rate and to secure further work. Product managers may determine issues to be minor if they’re standing in the way of a much awaited deployment. It is for the recipients of user research to challenge conclusions and make researchers earn their keep.


While a great deal of research has gone into identifying these issues and more, you don’t need a degree in psychology to understand how they can apply to user research.

Here’s a checklist to keep you on track:

Before you start

  • Benchmark. Take advantage of any data you already have access to. If you can benchmark a task you can assess how much influence the various forms of bias have on your results.
  • Choose wisely. If you’re testing with people you know try to select a range of personalities. Remember, the insights provided by “Screw your&dlquo; types are just as valuable as those given by the “Good” subjects.
  • Calculate. If you don’t know what you’re letting yourself in for, give some thought to what sample size will be sufficient to push the confounding variable of personality type into insignificance.
  • Shuffle the deck. Order effect is easy to provision for so learn to recognize it in advance.
  • Test the app. Invite your participants to anything but a “user test.” It’s a misleading term so avoid it.

During the session

  • Know yourself. What would you like the outcome to be? Designers hate finding out how ugly their babies are but the warm fuzzy feeling of concluding you were right when the results suggest otherwise only lasts a moment. Bad design lasts a lot longer.
  • Know your users. Even if you don’t actually know them, expect them to be awkward, too eager to please, confused, ecstatic, nervous and so on. Prepare a few rehearsed phrases to keep things moving and be ready to improvise.

When you’re done

  • Share. It’s important for the entire team to understand how users experience their product.
  • Learn. Highlight the findings that validate your design decisions but make sure to acknowledge areas for improvement.
  • Reiterate. You’re ready to improve your design. Remember, the data is just a tool. You don’t have to follow users’ suggestions blindly. You’re still the designer.

By taking the time to implement sound experimental design we can improve the quality of data returned by research, show the wider community that UX is a science as much as an art, and keep designing killer experiences. Here’s to better user tests…or whatever you choose to call them!

February 21 2012


Create better content by working in pairs

Have you ever had to come up with copy all on your own? It’s a nearly impossible task, often leading to content that is unfocused and lifeless. Yet everyday, copywriters, clients – and, yes, editors too – publish content without much input from their stakeholders. In many ways, this is a wasteful process. Sites like Wikipedia prove that using the web for collaboration enables people to create better content, faster. It’s up to us as professionals to reconsider our process.

We all know that content is an essential part of a website’s user experience. Without it, there’s nothing for users to consume! Kristina Halvorson, Erin Kissane, Karen McGrane and others have explained the details of content strategy, content ownership and caring for your content but, despite providing a good editorial strategy, none of these tools help authors actually write the content they seek to maintain.

That’s where this article comes in – a way to develop content by working in pairs.

“Why pairs,” you might ask? Simple. It’s proven. Agile software development introduced the concept of “pair programming” and our work environments have never been the same. In pair programming, one of the programmers (the driver) writes the code while the other (the observer) reviews each line of code in real-time as it’s written (like a real-time debugger). Aside from the obvious benefits such as sharing knowledge across a team, there is even evidence that pair programming has positive effects on code quality and overall delivery time.

So, at my agency, we took a gamble and used an agile approach to develop content. It turns out that a pair-oriented, exploratory, collaborative approach is extremely valuable for crafting content, too. Several benefits soon emerged:

  • The team thinks before publishing.
  • It forces authors to stay focused.
  • It helps colleagues form a mutual understanding of their content.
  • It results in a more uniform tone.
  • It allows authors to share best practices in regards to writing for the web.

All of these sound good, no? Here’s how you get started.

Step 1: Decide what content you want to work on

Make sure you know what content you’ll want to work on – for example a product page, a news article, or customer service content. Focus your efforts on content that is visited often and that you want to improve. Don’t know where to start? Look at the most visited pages in your analytics tool (such as Google Analytics) or conduct a survey to find out what content most people are interested in. For example, look at Gerry McGovern’s task identification approach.

Have a list of content outlined before you proceed to the next step.

Step 2: Arrange a workshop

The next step to creating good content is to gather the right people. Have your client identify important content contributors such as product owners, marketers, and people from customer service. Invite them to a meeting and let them know that no one has to be a trained copywriter; that the point of the workshop is to document a discussion. Make sure half of the attendees bring a laptop.

At the beginning of the workshop, clarify what the purpose of the workshop is (to practice pair writing) and why you want them to work in pairs (you get instant feedback). Explain that they are there to work with copy, but not everyone has to write their own articles. Remind them that this is a collaborative process, and that nothing major is expected of any individual.

Step 3: Make it pair-oriented

This is where the magic happens.

A photos from a pair-writing workshop

After the introduction, get the attendees in the workshop to pair up. Either ask them to find a partner or simply assign them. Next, have each pair grab a computer and fire up a word processing program. I suggest Google Docs, as it has great features such as comments, chat and sharing. This can come in handy both during and after the workshop.

Per pair, one person should be the main writer (the driver) while the other plays the role of the “antagonist” (the observer). As the writer writes, the antagonist should ask critical questions like:

  • What is the text meant to solve for the end-user?
  • Is this the best angle?
  • Is the most important content at the top?
  • Who is the target audience?
  • What do you mean by this?

Step 4: Switch it up!

After about 45 minutes, ask your pairs to switch their partners. The point of switching is to get varied feedback from as many people as possible. Different attendees – be they product owners, marketers or customer service employees – will look at the same page differently and have a wide variety of input. This makes switching roles both fun and instructive!

Step 5: Present in plenary

After you’ve successfully switched pairs and allowed attendees to write for another 20 minutes or so, spend an hour doing a group discussion of the content created. Ask questions and help people understand the value of what they’re doing. Not only will attendees get a break from writing, they’ll also get even more useful feedback from their colleagues.

Step 6: Repeat if necessary

Pair writing is not limited to one workshop only. If necessary, arrange several workshops, full days or half days. Ask the same attendees each time or invite new people to join.

The purpose is to get everyone involved to understand the value of content and to write copy that actually works. You teach them how to review and critically assess their own and each other’s work. Sure, a text can be brilliant without any assistance from others. But most of the time, an article needs a second pair of eyes.

When will you pair?

Ideally, you should arrange several successive pair-writing workshops alongside the interaction design, prototyping and graphic design processes. This helps the client stay focused on crafting great content for their new website.

That said, you can arrange pair-writing workshops at any time you want after the launch of a website. Content can always be improved. Think of each workshop as an iteration toward an increasingly better user experience.

The workshops also help you identify content owners, or at least important contributors and people with domain knowledge, who will be able to support you in the future.

January 24 2012


On site insight: advice from a UX apprentice

Everyone’s journey to UX design is unique. For me, it all began in an academic environment that promoted marketing-oriented thinking. Eventually, though, I found myself in an environment that promoted a more analytical approach. The transition between the two wasn’t easy, so I’ve compiled the following pieces of advice for those in a similar position.

You see, I was brought up in a country where no one spoke about – let alone taught – user research at university. I studied Communication and Public Relations in Bucharest, and although I remember one class that taught market research methods, no one ever explicitly mentioned “user research” – or that a “user researcher” could actually be a full time profession. Instead, we learned that the most important part of the process was what came after a product was created: advertising, copywriting, etc. In other words, our future wasn’t in listening to users. Our future was in sales.

Imagine my surprise, then, when I decided to move to Berlin and came across a UX job ad …for which I was qualified! Soon thereafter, I was talking to three interviewers who asked me all sorts of strange questions: “Are you comfortable with talking to new people once on a while?” “How do you feel about sitting and observing?”, “Here’s some problems that our users have identified, what do you make of them?” That’s when I landed my first job as a student worker – an apprentice – on an actual user research team.

That’s when the fun began.

Seeing is believing

Being in an office where nearly half of what your colleagues talk about are unknown words and technical abbreviations can make you feel like quite a dummy. Aside from the fact that the products we were working with were completely new to me, there was this other gap I needed to bridge: NPS, API, SR, PT, ODML, PO, BO, PM, etc. So I created my own, secret text file. There I gathered and translated the mysterious concepts I heard day to day.

Greek writing on a blackboard

Learning UX design, like any language, takes time.

Like any apprentice, a large part of my job was comprised of passively observing the more experienced and knowledge people at the company. Soon, though, observation became an innate part of everything that I did. It was undoubtedly the part that helped me grow the most. Remember that text file I mentioned? The one with definitions? Add to that a scrapbook. There, I wrote down everything that I found meaningful.

It’s not enough just to look. You have to train yourself how to see. Seeing comes not from your eyes, but from your mind. Seeing means more than noticing; it means understanding. Understanding comes from introspection. The only way to remember everything you’ve noticed is to write it all down.

Whitney Hess

Build something bigger

Sometimes my work would consist of analyzing the transcripts of usability tests. Other times I would simply watch and edit test videos or keep track of the emotional behaviour of test participants. In the beginning I saw these as disjoint “things to be done.” After a while, though, I came to understand their value in the wider context of research methodology. As a researcher, each small, apparently insignificant task that we conducted was always part of something bigger. Our work was always part of an ongoing process, whether it is a process of improving a product or the process of improving ourselves as professionals.

Along with a bit of experience in the team came more important responsibilities, such as creating posters that would be seen by the whole company, moderating usability tests or presenting research findings to the designers. Eventually I was responsible for a full testing project: everything from taking care of organizational matters to planning the sessions to moderating and delivering the results. It was then that I grasped the meaning of each small task.

Serious. Fun.

So how did I pull of a full-scale testing project, you might ask? I planned. If there’s one thing UXers must be good at it’s planning. In my case, I had a web tool for organizing and prioritizing my tasks, set deadlines for most of the tasks and stuck to them. I encourage you to do the same and to pay close attention to detail. Choose the tone of voice, style, fonts and formats of your deliverables carefully as they are your calling card as a professional. (If there’s one thing I got out of school it’s that there’s a bit of PR in everything!)

This is far from expert advice, of course. There are plenty of people who’ve written books on project management and I’m not one of them. The best way I’ve learned is simply by trial and error. Although it wasn’t something I was comfortable with at the start, it eventually made the most sense. I can’t recall how many times my supervisor has said to me: “Don’t be scared to do this on your own. If you make any errors, you will learn. That’s what it is all about.”

Go with the flow

The basic idea behind user research is that if we look to our users we will create something better than if we had not. By its nature, user research implies constant learning revision. Be willing to do the same with your own person. Be ready to go through many changes quickly. Be ready to learn something every day.

I was often annoyed by the fact that I barely got used to a certain report template or mind mapping tool, that we had to adapt to new ones. Adapting and learning is not only a cognitive process, it’s also an emotional one. During my year and a quarter in this job, I’ve changed offices three times. I’ve also seen some of my most cherished features removed in order to give room to new ones. That’s the nature of our industry. Getting attached to places and products only holds you back! Learn to go with the flow and remember that it is all about improvement and building better things.

…But don’t stop there!

Finally, I would be remiss if I didn’t mention tools I used outside of my apprenticeship.

Books helped me get accustomed to analytical thinking and armed me with more practical skills. In this respect, Jeffrey Rubin and Dana Chisnell offer a good collection of advice for user researchers in their Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. From skills that a good researcher should have to step-by-step planning of a project, the book prepares you for part of the nice ride ahead and gives professional tips for improving your skills.

Writing helped me to collect my thoughts. Not only in my definitions lists, but in compiling this very article.

Have you gone through similar experiences while getting into UX? Or on the contrary, was it very different for you? It would be really exciting to hear some of your stories!

Advertise here with BSA

January 17 2012


Using Axure RP to Combat Low Fidelity Impotence

Alt Desc

Building chart prototypes is often tedious

Have you ever had to create a performance dashboard for a group of stakeholders? This was precisely my task this last fall. Using Axure RP and Google Charts API, I was able to create an interactive prototype that helped our team iterate towards a more informed solution.

Low Fidelity Impotence

Most designers might sketch a static mockup and call it quits but I – like many stakeholders – suffer from a condition known as Low Fidelity Impotence (don’t worry, it’s not as bad as it sounds). People with Low fidelity impotence have difficulty understanding designs without an interactive prototype. In other words, they need to know what’s behind every link or button and they get hung up on the lack of ‘sexiness’ in the prototype.

In my case I needed to build a prototype of a performance dashboard portal for our flagship application. Stakeholders needed this dashboard to:

  • Display pie, line, column (clustered and stacked) charts.
  • Display mouse-over hints on chart elements.
  • Provide a method to change chart metrics.
  • Provide a method to change the chart type where practical.

We also work at breakneck speeds, which meant that I needed to get to realistic ‘sexy charts and graphs’ as fast as possible.


I could accomplish this in a number of ways, however, first I always find it important to consider how this prototype will get used. I knew we’d use it in design meetings and to communicate functional requirements to developers as is usually the case. As well, because this is a charting tool, we desparately need to test the viability of the design on real life data. Beyond that we’ll also use it to further refine the sales pitch, value prop and leverage it in marketing teasers to get the customer base excited.

To build something like this in a condensed timeframe is a tall order. I’m lucky enough to be in a position where I have a keen sense of what the market needs, what works for our typical customer data, as well as the limitations of our development budget and skill set. I thought it prudent to take this opportunity to evaluate a charting/graphing technology that we might use when we get to the development stage. Our application currently uses SSRS (SQL Server Reporting Services) for on demand reporting, so I knew enough about SSRS to rule it out as not being sexy or responsive enough for a dashboard like this. I really wanted the visuals of Highcharts JS but I wasn’t really sure where to start as a non-coder. I’d been reading recently about improvements to Google Charting and Visualization API so I decided to take a look. 

Why I Chose the Google Charting API

  • It’s free. You can’t beat that.
  • Publically accessible.
  • Well documented.
  • Can easily connect to google docs data sources (important for building data-bound prototypes).
  • Versatile charting options.
  • ChartWrapper class was helpful for a non-coder (hack) like me.
  • If chosen for development of production application, leveraging the ever evolving and improving google ecosystem is probably a good move.

Putting the Pieces Together

After reading up on the API and spending some time browsing though their playground, I formulated a rough stategy on how I would use this, along with Axure RP to do my bidding.

A Quick Note About Axure RP

For those unfamiliar with Axure RP, it is a robust software prototyping tool capable of web, desktop and mobile prototyping of any level of sophistication and fidelity. I consider Axure RP a tool for non-coders. If you are skilled with html, javascript, and css, I wouldn’t bother learning Axure unless it is a job requirement. Often, after struggling to force Axure to emulate a common web interaction I often think ‘Why don’t I just learn to f#$%ing code!?!?” Basic application functionality is a snap in Axure, but it becomes increasingly difficult the more dynamic the requirements or your app, such as drag and drop, self healing lists, expandable and collapsible panels etc. All of the modern ‘ajaxy’ web interface stuff is possible with a large upfront time investment, and subsequent prototypes will benefit from the reusable widgets you can create. Any graphic resources that you’ve built in Photoshop or Illustrator are easily imported into Axure, however, from what I can tell, Axure RP creates no reusable code. I gravitate to Axure whenever static wireframes will not do justice to the concept, when the actual interaction with the application is the most important part of the design.

Now lets move on to the rest of the steps in creating this prototype.

Alt Desc

Publish Google Docs spreadsheets

Creating Google Spreadsheet Data

Being able to create live data in a standard google docs spreadsheet was critical for testing the google charts applicablity within the context of our software prototype. While browsing the google charts api, I knew a chart could use a spreadsheet, sub-sheets and cell ranges as a data source so long as it was published. I created the spreadsheet, with smartly named sub-sheets with each sub-sheet representing a variation on the chart widget data. Some sheets were to analyse costs, some were for labor time, some contained monthly trend data etc.

Chartwrapper with Remote Data

Now that I had my data, I could use the tools available in the google code playground to generate html code to render these charts. My assumption was that each sub-sheet in my google spreasheet would require a separate HTML file to render the chart in an Axure Dynamic Panel State. I got to creating my html files with names matching my google docs sheet names.

Alt Desc

Configure your html files to connect to the published spreadsheet data

Creating Axure Dynamic Panel States and Inline Frames

Axure uses something called Dynamic Panels to which you can add items, states and assign properties. In web development terms, a dynamic panel would typically be a div. I built each of my dashboard widgets as a separate dynamic panel, with a panel state representing each chart variation I wished to emulate. For ease of maintenance, I ensured these state names matched my HTML file names mentioned above, as well as the sub-sheet names in my google spreadsheet.

Now, each panel state needed to contain an Inline Frame (iframe) referencing my external html files. I was able to use some of the On-Click Case logic in Axure to define pick list values that would immediately trigger the chart to change as though it were a working application.

Alt Desc

Axure panel states contain iframes referencing the chart embedded html

The Build Out and The Pay Off

I’m a religious time tracker, using a tool called Grindstone 2 to help me understand where my time goes during each day.  I broke this prototype into the logical sections inside Grindstone, and here’s the breakdown:

  • Research: 4 hrs – this included researching charting apis, learning about the capabilities of googles api and learning how to hook this up to spreadsheet data.
  • Building Chart Data: 1.5 hrs
  • Creating Basic Prototype: 6 hrs
  • Creating Dynamic Events to Update Charts: 4.5 hrs
  • Fine Tuning/Revising Prototype: 4 hrs

At about 20 hours to research and build, the end result, turned into a reasonably high fidelity, scalable, data bound prototype which serves countless purposes for our team of stakeholders. Using this prototype we were able to refine the design by identifying ways to streamline much of the interaction. We’ve since moved the date range picker to a 3 part toggle type button containing the most common date ranges – 1 month, 3 months and 6 months – rather than having the user pop-up a modal window to modify that.

Because of the realism provided by this prototype, we’ve been able work with clients to elicit their perspective on our value proposition for sales and marketing, and most importantly we could easily express the required behavior to our development team.

The biggest problem with this prototype is the need to constantly remind our internal team that “This is still fake software, remember?

Axure RP Prototype Using Google Charts & Visualization API

Lead photo by MikeLove

Advertise here with BSA

November 22 2011


Quantifiable Design: How to Remove Subjectivity from the Process

In my 12+ years as a designer, I’ve been in all types of situations with clients and worked in all types of situations. Some clients really have a handle on strategy and a tight focus, and others have tons of great ideas but it is more difficult to get to commit to singular points of focus. In either case great design starts with a set of clearly defined parameters, and adhering to them throughout the design process. The trouble is, how does one go from a ton of ideas to the perfect product?

Over the course of any design project, there are literally thousands of decisions being made, each of which can steer the project off course, or tighten the focus and keep it on target. The decision making process can often be 1) subjective based on the perspective of the team, and 2) tiring because of the variety of answers possible, all of which seem to make perfect sense, and have perfectly good arguments pro and con. The decision to add a browse capability to a geo-location map based application can be justified as either one too many features or a feature that can help the user do more with the app. The decision to add an option to create your own custom badge on a badge game may further complicate the game or make it more flexible to the user’s need.

If you take each of these choices and multiply it by 1,000, that equates to the decision load of the average project. This is where the real design is at: making accurate decisions based on our experience and understanding of human beings to help them accomplish a task, be it to read articles on a blog, to understand a company’s products and services, or to find out which car is right for me. We all have tasks we want to accomplish online, so how can designers make the correct decisions to “get it right”?

How do we make better design decisions to “get it right?”

In my experience, how all types of designers, marketers, and developers work is often intuitively based on their own experiences. How this works is a designer empathizes with the position of the person he is designing for and says, “If I were a [blank], what would I want to do here? What would I expect to see?” or maybe even “What would one shopping for [blank] need to make a purchase decision?” Most good designers operate from this perspective.

Other designers fly completely by the seat of their pants and just start designing, opening photoshop and “feeling it” intuitively based on things they’ve seen online, their connection with the client, or simply their internal comprehension of what is right for the job without putting any words to label it. The words or labels seem to erase the magic of what just makes it work for these designers. They just know it’s right…Or do they?

I’ve had the pleasure of working with some amazing people who operate from both perspectives. The problem arises in the presentation with the client who says, “I don’t like it” or “I don’t agree with your logic on how you arrived at [blank].” What do you do then? Some designers ask more questions like “So how do you see this working differently” or “Give me your feedback on [blank]” in order to refine the solution often reading between the lines of what is actually said, and translating it to the changes for the next comp. Some resort to straight up “salesmanship” and convince the client/team of their brilliance. Others just get straight out hostile because they feel like the client has not thought through the process, and does not “understand” the plight of the user.

As a person who designs websites, I have always and continue to believe that our reason for being is to be the voice of the user. Our job is to simplify things for those who use our products to give them value to make their life easier. I also believe that part of our social responsibility is for us to remove the clutter from their lives in order to get information they need as easily as possible. Much like a politician, our responsibility therefore requires we make accurate decisions on behalf of our constituents. We need to understand them on an intimate level, and make the choices they themselves would make, so when they work with the product, it does what they expected, and they are pleased.

The question now arises: As designers, how can we make accurate decisions—taking the subjective biases of our teams out of the equation—to create design that objectively meets the goals of the user?

While we will never fully remove subjectivity from the design process, there are ways that you can make better team decisions by doing exercises that create data and numbers by which the decisions become apparent, so there is no discussion about whose opinion is right. This removes the tension and debate that happens when 2 or more people on a team have perfectly valid arguments for a direction, but the project gets stalled because consensus must be reached prior to moving on. It can be tedious and tiring and can cause a project to lose momentum…fast.

However, when you start to quantify design with numbers, the truth appears before you in black and white, and helps you make the correct decision to move on. The more you can do this, the more fun you have on a project, and the more momentum you keep on a project (let’s face it, after 4 months on a project it starts to lose some of the initial excitement and luster it once had, becoming more work than labor of love).

The process

I recently attended a master class workshop with UX leaders Adaptive Path, and realized after 4 days of workshops the trick to their process was to create quick exercises that yielded quantifiable results as part of the exercise. Later on in the article, I will mention a few of these, but for now, what I noticed was that the decision making process was much easier, and we were quickly able to see results. From there, I incorporated their methodology into my own.

The resulting steps are:

  1. Create a unified focus
  2. Define the problem visually, in context
  3. Collect user data
  4. Create potential solution(s)
  5. Test and measure for accuracy

Creating a unified focus

When designing any product, the key is focus on the business problem. The challenge is that getting a group to focus is a lot harder than it sounds. Because of the many varying opinions, the clarity of the product often gets obstructed when working with groups. “Feature creep” happens in order to appease all the stakeholders involved. As a result, the product can lack a singular point of focus, is difficult to explain to consumers and even more difficult to use.

How to solve the problem

  1. Get all ideas of opportunities on the table, rate them according to importance and viability. Gather all stakeholders from all disciplines in a room for one hour. Have everybody brainstorm business objectives of the site. You can write down the business objectives on a white board, and write 2 columns to the right of it each with the headers “Importance” and “Viability.” Rate each business opportunity on a scale of 1 to 5 for each attribute, however you cannot total more than an average of 3 point times the amount of items you have.

    For example, let’s say you have 6 objectives, you would have 18 points for Importance and 18 points for Viability to distribute. Those with a viability and importance greater than 4 each must be part of the current initiative, 2.5 to 4 should be considered. Anything with a viability or importance less than 2.5 should be removed from the project. Document those principles and refer to them at every step as the gospel.

  2. Agree on the design principles that will drive the project. These must be clear and understandable, and must be as specific as possible. For example, “Helpful at every point of the purchase decision,” or “As few features as possible,” or “Light-weight and fast loading.” If you can brainstorm and agree on those, it will make measuring design much easier once visuals are introduced into the project. Ideally 4-to-6 core design principles should be applied to any project.

Defining the problem in context visually

Another challenge with design is that people design in a vacuum. They design a product without any context of where and how it will be used. I have seen situations where we discuss a process of user flow that seems logical but once we made the steps concrete, we realized we were missing logic, or opportunities to improve the experience. The way to do this is by storyboarding and judging the accuracy of the storyboards to the initial focus.

How to solve the problem

  1. Take all the key user tasks and storyboard them out in their entirety. What you want to do here is illustrate 4-to-6 frames that show a complete transaction from a particular user perspective. For instance, if you have an e-commerce shop, you want to storyboard a purchase, a “browse,” a compare, and a return or support process. These are the key things your shopper needs. Think about what they need at each point. Also you will want to illustrate what happens on the business side. Does the order get printed out in the warehouse for a master pickup? How does accounting get the invoice? This helps create a real story and give life to diagrams and workflows that might not be realistic. Measure your diagrams against the storyboards for accuracy. If it is not accurate, revise until it is.

  2. Create fictitious collateral for the product. What this involves is creating a marketing piece, a press release or a user manual to show what this product will do in context. The trick here is to create a document that is a creative tight presentation of the product, and it explains what the product does, how it does it and the customer value. Measure against the focus goals for accuracy.

Collecting user data

Much more than just analytics, true user data comes in 3 forms: interviews, surveys and clickstream. The grand triumvirate of those three tools give you a complete view of your user. User interviews are for seeing how people are doing things currently and observing patterns. Surveys are used for verifying hypotheses, and clickstream (your typical “analytics”) are for viewing current behavior. When you put the three together they comprise the angles you need for accurate data. Looking at clickstream data alone doesn’t give you the “why” behind the numbers. Interviews are limited by sample size, and surveys don’t give you much information on the “who.” The combination is powerful. While there is an art to doing all three of these things, as designers, it is not unreasonable to learn a basic set of chops on each of these to help inform your design and keep it on track.

How to solve the problem

  1. Talk to users. Most designers are used to some sort of segmentation and/or persona development on a project. This is the act of creating a story and lifestyle around a user group or market segment to make it easier to visualize. The goal of this is to get a picture of your users. In short words, find some of these people and get them on the phone and ask them a lot of questions. There are varying degrees of research ranging from full in-home visits to casual chats. It’s not the degree so much that you do it. Do it to gain understanding, do it to get better empathy, do it to gather data, but just do it. It is beyond the scope of this article to get into the particulars of it, but my words of wisdom are:

    • See if you can get your clients involved in recruitment.
    • See if you have any friends who are in the target market.
    • Try to create non biased questions that do not lead the participant in one direction or the other.
    • Be prepared for some participants to be flakey, difficult or reticent.
    • Take notes during the interview (if off site only!), and post all the “insights” from each interview on a post it note. Group all the post it notes in like groups, and see what comes out. Often the answers will be right there on the wall.
  2. Look at the analytics You should not be afraid to look at analytics.They will tell you about your users: what they are looking for, what pages they find interesting, where they left the site, how long they are on the site, and most importantly, places to benchmark things like bounce rate, time on site and conversion rate. If you are unfamiliar to analytics reports, start with the basics then drill down. The following are basic benchmark info and their “averages”: Bounce rate (30-50 per cent), conversion rate (2 per cent), time on site (2-3 mins), search terms, browser/platform/bandwidth stats and possibly location data. If these are worse than these averages, try and find out why, and what you think can be done to fix it. If you can point to the numbers for where you got your postulate, you’re on the right track.

  3. Review survey data. Ideally this will occur after you have had the opportunity to get both the first 2 items done, but some surveys on their own can yield some insight as well if done correctly. You can view questions like “rate the service from 1 to 10″ as a good way to benchmark service. There often brand related questions like “What word comes to your mind when you think of [blank]?” and these are good for judging how creative is going. In general, I like to contribute to the questions and let the marketing team know what we want to get verification on. Our interviews are often too small of a sample size to verify the opinions of everybody, so ideally this is a great place to ask people to verify your theories using “yes or no” questions, as well as ratings from 1 to 10.

Creating potential solutions

After collecting data, defining and focusing on the business problem, now it’s time to come up with some ideas and compare them to a standard. With focus, you defined a goal. By creating storyboards, you visualized the goal, and with the data, you have some reality to base your ideas. Now it’s time to create! Yay! When creating solutions, it is important to remember that you are not only measuring this against your own professional standards, but on a scale of 1 to 10, how well does this fit the defined criteria.

How to solve the problem

  1. Review against the focus. This is the singular place to be ruthless in your judgement. Does this address the business need? Your solution should incorporate some research to back up the “how” you arrived, but number one is that it has to be judged against the focus that everyone agreed on. If there are any subjective “aesthetic” questions that arise out of this conversation, address those separately, but you should be able to go page by page and rate on a scale from 1 to 10 on how close you adhered to the design principles and the focus. Anything less than an 8 must be revised.
  2. Review against the storyboards. Based on the research of what is acceptable to users, does this match up with the vision of the storyboard. Are there additional steps that need to be visualized?

Testing and measurement for accuracy

So you’ve completed a design that the whole team can get behind. You’ve evaluated against business goals, and the solution lines up with design principles and research. Congratulations, you’ve made it! First at this point, go grab a beer, because you have probably done an amazing job and should celebrate with your team…then you send it out for testing. Testing can come in different forms. Mainly we’re going to discuss usability and concept verification. These are used to make minor refinements and verify that you have indeed done your job right. The good news is that if you have been adhering to a data focused approach to design, you should be most of the way there. There should be very few big surprises. You’ve made smart decisions along the way. Now, you fine tune.

How to solve the problem

  1. Concept testing. If you can get your concept in front of some people in your target demographic in a tight wireframe format, do it. If not, you can concept test after you have full visuals for both emotional connection and concept preference. You can use a service like usabilla for this, which asks users to click on flat artwork to show what they like, or where they would initially click. You can also use Skype and do an interview (which is best, but you may have a limited amount of participants so this may not be possible) and show the participant the concept through screen share.
  2. Usability testing. This may range from full-on usability lab work to a screen share through GoToMeeting. The big challenge with this is the participants. You may have used up your participant cards in the previous exercises, so you may be stuck with a remote video testing company like User What you will want to do is take those tasks defined in the storyboards and see how well the end product performs against that. Is it as easy? Easier? What is the feedback? Do you see people using the back button? If people are doing what you wanted them to do, great, you’re successful! If not, see where the hangups are and propose solutions to refine.

A few closing words

The closer you can get to quantifiable design, the easier and better design becomes. The trick is to compare something with something else. You really should steer design discussions from “I don’t like it” to “Does this match our goal.” If it does, then does the goal and values of the team need re-evaluation and discussion. That is where the beauty of a meeting can occur: the brainstorming and agreement of principles and ideas. Once you have all agreed then it will be a group effort, and you can get support from all team members. Plus, there is no greater feeling than to work on a project with full confidence that the solution you are creating will meet the needs of your user. Not because of your own opinion, but because it matches up with a quantifiable result.

One last word of advice…document and prepare visuals to support at every turn. In our firm we learned early on that the way to win the subjectivity war, was to document all of our thoughts and prepare visuals that create insight for the whole team. We realized that often in the game participants are not even in the room, and are judging the work on the subjective game. Clear documentation takes extra time, but helps you clarify your thoughts, and helps everybody understand how the decisions were made, and if someone new jumps onto the project mid stream, you can hand them the documentation, and get them easily up to speed.

Advertise here with BSA

November 17 2011


A Look Inside Mobile Design Patterns

Mobile Design Pattern Gallery

Patterns for mobile application design

Design patterns for mobile are emerging as the platform matures. Theresa Neil’s new book Mobile Design Pattern Gallery provides solutions to common design challenges. Read a sample chapter on Invitations and learn how to immediately engage your customers with your application.

We recently had a new mobile project starting and all of our experienced mobile designers were booked. Since we primarily design enterprise apps and productivity tools, not everyone in our group was well versed in mobile application design. So I made a quick tutorial with lots and lots of screenshots. Gradually a set of patterns, at a higher level than OS specific design guidelines, emerged.

These 70 patterns, illustrated with hundreds of examples from iOS, BlackBerry, Android, Symbian, Windows and webOS applications, will be released this month from O’Reilly Media as the “Mobile Design Pattern Gallery”. Here is one of my favorite chapters, Invitations. Constructive feedback and additional mobile app examples are most welcome.

*Although these patterns are based on best practices in mobile application design, they may also be inspiring for mobile web design.


Do you remember the first time you used Photoshop? I remember opening the application and seeing a blank canvas and a vast array of powerful tools.

Alt Desc

Phototshop 5.5

Well, I assumed the tools were powerful, but didn’t know for sure. In fact, I didn’t know how to get started at all. But I had quite a bit of money invested in the software and needed to learn it for work. So I bought a “Teach Yourself Photoshop in 24 Hours” book and started learning.

Fast forward a decade or so. There are hundreds of thousands of mobile applications, readily available in the marketplace. In any one category there are dozens of apps for the same purpose. Many of them are free, making it just as practical to download and try another app as it is to struggle for 5 minutes with an unintuitive interface.

Consider the initial experience with Layar Reality Browser, augmented reality software.

Layar Reality Browser

Layar Reality Browser (early version)

What would help me get from this gray screen to augmented reality? An invitation. Invitations are helpful tips that are displayed the first time a user opens an application or arrives at a new place. They suggest actions and guide the user to the intended functionality. A simple invitation can turn an otherwise discouraging first time experience into a satisfying one.

Mobile invitation patterns include:

Dialog Tip
Tip Tour
Tour Video Demo
Demo Transparency
Transparency Embedded
Embedded Persistent
Persistent Discoverable


A simple dialog with instructions is the most common type of invitation in mobile apps, probably because it is the easiest to program. It is also most likely to be dismissed and ignored.

Keep dialog content short, and make sure there is an alternate way to access instructions from within the application.


Dialogs on TargetWeight and ActionMethod


A tip can be implemented anywhere in the application, making it more contextually relevant than a dialog. And tips can be used on any screen, not just the home screen. In the eBay app, a tip is used to draw attention to the “save a search” feature, which could otherwise be overlooked since it is where the page title is normally displayed. The Android OS displays a tip reminiscent of Window’s Clippy, the helpful paperclip, to explain how to customize the home screen.


Tips on eBay and Andoid OS

ShoppingList progressively reveals more tips throughout the application.

Place tips in proximity to the feature they refer to, keep the content short, and remove the tip once interaction begins (ie. when the screen is touched).


Tips on Shopping List


A tour provides the ultimate invitation by offering a screen-by-screen, feature-by-feature exploration of the application. The Nike GPS tour is an excellent example of this pattern. The tour is optimized for mobile with concise copy, vivid graphics, simple navigation and a clearly marked exit. The Tour is offered on the home screen, and once launched you can tap through each of the seven tips. Nike and WeightBot use “page indicators” and a count (2 of 7) to clearly mark the current step in the tour.

A tour should highlight key features of the application, preferably from a (user) goal perspective. Keep it short and visually engaging.


Nike’s Tour Invitation


WeightBot’s Tour Invitation

Video Demo

A video demo may be the best form of invitation for applications that rely on specific actions/interactions since it demonstrates the application in action. Roambi uses a custom demo to showcase its wide selection of data visualizations and the use of certain gestures for optimal navigation and exploration. Google Goggles has a demo in their tour that can be opened and viewed in YouTube.

Demos should showcase key features or show how to use the application from a standard workflow perspective. Common video features (stop, pause, volume controls…) should be provided.


Roambi’s Demo


Google Goggles’ Demo


While the rest of these patterns exist on the web, the transparency is unique to touchscreen devices (so far). Typically seen on home screens, a transparency is a see-through layer with a usage diagram positioned over the actual screen content. Pulse and Phoster both use this invitation pattern to quickly and visually explain how to navigate content in the apps.

Transparencies should be used judiciously, and are not meant to compensate for poor screen designs. Remove the transparency once interaction begins (ie. when the screen is touched).


Transparencies on Pulse and Phoster


Unlike the other invitations, embedded invitations don’t precede the screen they refer to. Embedded invitations are built into the screen design. They remain in the interface until they are overwritten with content. Many note taking apps, like Mini Diary and PageOnce, use embedded invitations to immediately engage the user to add content.

Multiple embedded invitations can exist in a single screen. Clearly differentiate the invitation from other content with images or other visual cues (ie. don’t use the same color and size text for the invitation as is used for regular content).


Embedded Invitations in Android’s Mini Diary and PageOnce


Persistent invitations are built into the screen and remain visible. This example from Jamie Oliver Recipes suggest switching to landscape mode to uncover an additional feature. Wether this is your first time on this screen, or 10th time, the prompt is still displayed. Spring Pad uses an embedded, persistent invitation to show that more notes can be added by tapping on the ‘+’.

Keep it short. Clearly differentiate the invitation from other content with images or other visual cues (ie. don’t use the same color and size text for the invitation as is used for regular content).


Persistent prompts in Jamie Oliver’s Recipes and Springpad


A discoverable invitation may seem like an oxymoron, but it is an effective way to encourage specific interactions without cluttering the screen. These invitations are meant to be discovered when performing a common gesture, like flicking or swiping.

Use discoverable invitations sparingly. The most common instance of this pattern is used for prompting refresh and loading more results.


Discoverable Invitations in eBay and TweetBot

Mobile Design Pattern Gallery Book and Site

Invitations are just one of the types of patterns in the Mobile Design Pattern Gallery. Get the upcoming O’Reilly book, “Mobile Design Pattern Gallery”, to learn more about mobile patterns for:

  • Navigation
  • Forms
  • Tables
  • Search, Sort & Filter
  • Tools
  • Charts
  • Feedback & Affordance
  • Help

and a bonus chapter on Anti-Patterns.

Also check out the Mobile Design Pattern Gallery:

More Pattern Resources

Patterns for Android:

Patterns for iOS:
Mobile Patterns,

General Mobile UI Patterns:

Advertise here with BSA

October 25 2011


How to Design a Mobile Responsive Website

To build a mobile site or not to build a mobile site; this is a question at the forefront of many a discussion. There is, however, another option: responsive web design. When, why, and how should you go about designing a responsive website?

With mobile internet users set to surpass desktop internet users in the US by 2015, with tablets becoming more popular, and even with TV internet usage increasing, it’s important for companies to provide a great user experience for all their visitors no matter what device they’re on. How does responsive design help us do this? Well, by allowing us to create one website solution that is flexible for different screen widths. It uses flexible grids and clever styles to present the same content to a user, but displays that content in a format that suits the width of the device. Check out this beginner’s guide to responsive web design for a more detailed introduction.

Why should you design a responsive site?

There are many options to consider when a client asks for a mobile solution for their website, and the suitability of these options depend on the business requirements and budget; it’s also important to consider any existing solutions or sites they already have. Creating a responsive website isn’t a complete mobile strategy, and won’t answer every brief, but, especially if you are starting a website from scratch, you should consider it as a very serious option.

So why would you decide to create a website this way?

You’re starting from scratch

Developing a whole new website or web application is a challenging process. You won’t know if the site will be successful until it’s live and in the world, so creating a separate mobile site or a mobile app in tandem with a website project could be a big waste time and money. It’s more efficient to get your new site performing well before you create an additional mobile site or application.

You want to keep costs low

Solid responsive solutions require additional design and front-end development time, but doesn’t too heavily impact application development. It could take around 20-30 per cent longer to develop a responsive site, but it’s still faster than creating an additional mobile site or app. Developing a site this way also means that you only need to develop, manage, and maintain the one site, so it can reduce these costs too.

You want it to work even when new devices are released

A mobile site needs to be able to recognize the user’s device; when new devices are released, the site needs to be updated. As the responsive solution only recognizes the browser’s width, no new updates would need to be made. This means it’s much more future-proof and scalable.

The process

Let’s talk through the process of creating a responsive website using a hotel website example. This last September, Equator released the new Macdonald Hotels website. Macdonald Hotels are a UK hotel chain with 47 hotels and resorts across the UK and Spain. We created the new site for them that included a new site structure, extensive hotel content, and a new booking engine. Here are the steps we went through and also some considerations you should think about when designing a responsive website.

These are the key steps:

  • Research/scoping: Understanding the additional requirements for a responsive site
  • Wireframing: Grid structures and layouts for the site considering different screen widths
  • Look and feel: Style considerations
  • Building the site: HTML & CSS issues

Research and scoping

Research is always a very important stage in the design process so it’s worth putting a little extra consideration into the people who will be using different devices. Understanding how these different users may want to use the website on a variety of devices will help you to decide what the priorities are on the project.

  • What different goals will a user have on different devices?

    Questions like this are starting to become more redundant. In the past we’ve assumed that mobile users have been task-driven, e.g. I want to get the hotel’s address; I want to book something quickly. But now people on any device are just as likely to leisurely browse the Internet as they are to need to complete a task quickly. It is worth considering though, as thinking about users’ goals in this way could help you prioritize content for the site, irrelevant of what device the visitor is using.

  • What technical considerations do we need to make for functionality and content?

    Think about how any complicated functionality may work on different devices. Although a responsive site will only change the CSS depending on the width if there are complicated elements that rely heavily on JavaScript, they may not translate well on a smaller device and it could be worth hiding these.


The logic behind how the styles should change can be a bit hard to define and the magic of it will really come out in the build of the site, but we need a way to start defining the different width stages of the layout. We choose to look at 3 screen widths, a desktop, iPad and iPhone. We felt these covered what our requirements were, but for your project you should consider what widths are important for you to think about—you may even need to look at bigger screen widths for TV internet usage.

At this point of the project you should already the key templates that you’ll need to wireframe, but you shouldn’t need wireframes for all these templates in the different widths. The main goal here is to help define the logic behind how the CSS will change the look of the page, so focus on pages that have very different layouts. For us we looked at the home page, all the booking process pages, the hotel pages, offer pages as well as some generic layouts. Each of these covered our different column layouts, content types and key functionality.

  • Getting started

    First, define the grid structure for each key width. We created 3 pages for the screen widths 1024px (Desktop), 768px (iPad portrait), 320px (iPhone portrait), then we needed to define a grid structure for each of these widths.

    A very simple grid structure with equal column widths on each layout made it easier for us to plan for components wrapping as the width changed.

  • Creating the master template

    As you create each wireframe you’ll need to think about the columns and how the components within these will adapt as the page width shrinks&mdashe.g. what happens When you have less space? If you have four columns of content? When you change to a three-column width? There should always be ongoing communication between the designer and the front end developer to answer any issues about what you can do with components visually and in the CSS.

  • Starting on the home page

    You may feel like there is another page that has a higher importance than the home page, but this was where we started. Here is our finished original wireframe. You can see the mobile page length is quite a bit larger due to the content wrapping over one column.

  • Main navigation

    We created a simple horizontal top navigation that would have a fluid width to change with the screen size. As the screen reduced the menu items would get closer together, then wrap on to the next line when necessary. This works for desktop, laptop and tablet widths, but going further down we wanted to create a menu that would suit the devices better. This gave us the menu spilt over two columns for the mobile device.

    Other header components are aligned right and would just shift along as the page width reduced.

    Remember when you are styling the navigation to think how it will work as the screen sizes changes. Certain styles, such as using tabs, may be difficult to get to work and look good as the screen width reduces.

  • Footer

    Our footer is pretty simple, just think about what content you want and how it will change as the width changes and the columns reduce—this could be as simple as components wrapping underneath each other.

  • Other components

    Our simple grid structure made it easier to plan out our components. On the home page we used a horizontal scroller that had four components that would scroll across on a click. Our tablet layout let us keep this component but just amend it to only show three items, then on our phone width we removed the scrolling functionality completely and instead displayed each item vertically. Each component you design may require different behaviours, so think about how the visitor will want to use the component on different screen sizes. Phone users are more comfortable scrolling down a page than using small buttons to interact with the page.

  • Test it straight away

    As soon as you have created your first wireframe test it on the relevant device straight away. It’s easy to get the image on a simple web page and take a look at how it looks and feels to scroll down. This will let you know early on if your wireframe is working. Testing in this way gave us clues really early on what was and wasn’t working. If you look at this wireframe you should quickly see our first issue.

    As the user navigated through the site they would only see these first two page elements&mdashthe navigation and the search panel. This means that the user may be unsure if the page has changed, as well as where they actually are on the site. This was solved simply by putting these items in show/hide panels—letting the user get into the content much faster.

    Adding the tablet and mobile versions to your user testing process will give you a lot of useful feedback too. Now that your wireframes are created, tested, amended and approved it’s time to make them look good for all your screen widths.

Look and feel visuals

It isn’t necessary to create visuals for every wireframe. The main objective is to cover all the styles that will be required to create the HTML and CSS. There will be a little bit of a crossover for wireframes and visuals, some styles that will be required for the mobile where there wasn’t a need for an initial wireframe.

  • Styling the page: Think about keeping your styles simpler for your mobile version—what’s great about CSS3 is that you don’t need lots of images to get great styled effects, but these still take a bit of time to load.

  • Thinking about font: Make sure your font sizes are going to be readable on each device. They’ll have to be much larger on the mobile device to ensure readability.

Also, be prepared for your visuals to change when it gets translated into the build of the site. There always should still be balance between what looks good on a flat visual and what will work when the site is being developed. The final site isn’t too far away from our look and feel visuals, take a look here and you can compare with the live site.

Building the site

Building the HTML and CSS is a challenge all of its own, so I won’t discuss this is much detail, but here are a few things to think about.

  • The impact of image sizes: The site will need to load in the full size images even if the CSS scales them down, so try to keep image sizes as low as possible. There can be some nifty JavaScript tricks though to make the site run smoother. On this site we initially loaded in the smallest image size, and then used JavaScript to decide if a larger image was then needed.

  • Use advanced CSS:
    It’s important to get the client behind the idea of using advanced CSS styles, allowing the site styles to degrade as the browser capability does. This lets you keep site loading times low.

  • Constant communication is required: The project will always go smoother if the team speak to each other, so from both designer and developer it’s good to discuss problems and solutions as soon as they turn up.

It’s worth taking a look at our front end developer Jamie Boyd’s take on the front end development of the Macdonald Hotels website for responsive design.

So what does all this mean?

If you are thinking about convincing your client to have their new site designed and developed in a responsive way, firstly you should consider if it really is the right solution for them, then you’ll need to be able to persuade them of the benefits and communicate that it will add more time to the project. But, I do believe that this is how more sites will be developed in the future.

We’ve all learned so much on this project about developing a responsive website. We were lucky to have a client who was as keen as us to create something new and innovative and from that we’ve created a site we’re all proud of.

Image on UX Booth homepage from needoptic on Flickr.

Advertise here with BSA

October 11 2011


Leveraging User Research for More Effective Feature Prioritization

The project’s scope is firmly rooted in well-considered facts. The approach has been validated with consumers and business owners to ensure that it will deliver value. The project budget is based on accurately crafted estimates created by well-informed technologists. Last but not least, the timeline has been determined by the number of resources available to do the estimated work.

I have never been on this project. From conversations I’ve had with others, it seems that projects such as these are as common as spotting a unicorn flying over a double rainbow. It’s far more likely that a few people were handed a project charter, brainstormed a list of features that got passed around and mysteriously became the project scope. Estimates are based on whatever details can be found. And the deadline was set before the project funding was even approved.

Gail Swanson

No matter the methodology used, members of the project team do the best they can with what they are given. Whether challenged by the release date, resource availability, a lack of information, or a low budget, it’s usually up to the team to establish priorities for the features in order to determine the project scope, plan releases, or plan a sprint. The team will ultimately be more successful if it considers what will make the product successful rather than narrowly focusing on a tactical plan for knocking out the to do list set before them.

I used to think that as a user experience designer my only concern should be representing the users’ interests and fighting for the features that benefit them. This approach will put you at odds with those who represent business interests and technical resources. ‘UX versus The World’ is not a recipe for success and harmony. The different skills brought together on a project all have to compromise to create the best product given the current conditions.

UX professionals are well suited to be the facilitators of this compromise. Our role requires us to communicate with many constituencies and develop empathy. We can direct the team toward the solution that delivers the most business value through the best user experience possible. Some of the best guidance to identify high priority features comes from the research you have about your users.

The more firmly you root your priorities and scope in real data and information, the better decisions you will make. You will also minimize the number of times you revisit and debate those decisions. Product decisions based on gut feelings or personal opinions are more vulnerable to fire drills and occupy hours with circular debate.

What information do you need about your users to determine feature priority? The most important details for this exercise are the ones that define the user’s goals and needs that are most closely related to the project’s goals.

Confirm that the feature will be used at all

According to the CHAOS Summary 2009 Report, “50 percent of software features are not used or wasted, while other features are sorely missed.” That adds up to a lot of unnecessarily complex software. How can you predict what people will use? Try a round of Contextual Inquiries where you watch people perform the tasks in their normal environments, their offices or homes. Do they use similar features on other websites or ignore them altogether? Do they already have a tool for that microtask that they’re happy with, one that integrates well into their workflow?

You can also test the feature with paper prototypes and gather feedback on whether the feature is desirable. Ask the participants for examples of how they might use the feature. If you are redesigning an existing application, benchmark analytics can reveal current functionality that is not being used and should be cut from the new version.

Frequency of Use

Features used frequently should be given high priority. It’s a pretty straightforward idea, but one not frequently mentioned in scope discussions. Des Traynor created a grid to evaluate features according to how often they are used and by how many people.

Image copyright @contrast. Used with permission.

“The amber sections represent danger. If you’re building features that only a small sliver of your customer base heavily depend on, your product is doing more than it should. These customers won’t be happy if you remove these features, but they’re worth very little to you.”

Holding up the functionality against your personas should give you a pretty clear picture of how often someone would be using the feature, and knowing how your personas map to your actual user population will reveal the number of users that would be exhibiting that behavior. This is a useful perspective when you need to trim scope from your project. Odds are that there is a small set of features in your product that people will use frequently. From both the user and business perspective, these features deserve the greater proportion of your attention and project budget.

Value — Forget the long tail

“5% of your website produces 25% its value.” According to Gerry McGovern, a very small portion of your website is delivering a large portion of its value.

Shift your focus from a diverse offering of content and features and hone in on the limited areas that are getting the job done. These areas tend to be the ones most frequently used by the greatest volume of users. They might also be features that are the most essential for completing the user’s goal or delivering the business value. The shopping cart may only be used by 15 percent of your site visitors, but they are the users that are putting money in your pocket.

Not every problem needs a solution

Traditionally, designers have tried to ferret out every possible scenario that could play out with their design and ensure that every pathway is accounted for. This requires a lot of effort. Plus there’s always that looming risk of finding the edge case that screws up the whole design. You add complicated features and options to your website just to make sure that something that a user is unlikely to do won’t trip them up. Before you add features that will make things more difficult for your most frequent use cases, consider the results if you did nothing.

If this is truly an unlikely scenario, is it important that the error is prevented? Will it prevent the user from purchasing your product, or will it merely require that user to undergo a few extra clicks to finish the task? What will the user experience if they go through the scenario? It may cost you more to prevent a handful of users from hurting themselves than the benefit your business will gain from satisfying them. Graceful failure may be the most appropriate route.


User research often uncovers the costs of a bad user experience. The most obvious costs are incurred directly supporting users through call centers, robust training and documentation. Costs also increase from low productivity, inaccurate data, bad sales leads, high user abandonment, and low morale when the product design does not meet the user needs. Features and design solutions that reduce these costs may warrant a high priority.

Task Priority

How important it this task to the user? Take a look at how someone currently gets this job done. Examine the current process that would be replaced by the feature.

  • Is it a pivotal part of their role and the primary way that they add value?
  • How painful is the current process for completing the task?
  • Can the user accomplish their goal be without the feature?

Additional consideration should be given if the current process takes up a lot of the user’s time and leaves them feeling that their effort didn’t accomplish anything of value. Does the user currently have to undergo a lengthy process that includes redundant data entry in multiple applications?

Problem Severity

How bad is the problem that the feature solves? You can actually calculate the severity according to the number of users that encounter the problem, how often then encounter it, how disruptive it is, and whether a user will repeatedly experience the issue or be able to learn and adapt to it after a few encounters.

Do the user goals align with the project goal?

This can be a tough one for UX designers to accept. The feature may be important. It may be a great idea. But does it belong in this project? It’s easy to get stuck in the mindset that now is your only chance to deliver to your users. You’ve got to make sure you get all the features in with the first release. Relax…breathe. Software changes over time. We learn a lot when what we build gets in the hands of users. You may change your mind about adding that feature or find that something else will work better. Stubbornly fighting for features that don’t move you toward the goal at hand is not a good way to win friends and influence people. Place priority on making the features that align with the current business goal the best that they can be. If your users still need that other feature, campaign for a project to address it directly.

Product Adoption and Customer Retention

There are some features that users just won’t do without. Sometimes the little things are the ones send someone on a quest for similar app that does what they want a little easier. Mobile apps and shopping websites are especially vulnerable to this. If leaving out a feature, like integrating to a map application, will cause your users to walk away, it deserves a high priority.

Gail Swanson

Many designers like to begin their process with a blue-sky view rather than constraining themselves by technological constraints. Unfortunately, these designers set themselves up for arguments and frustration because the context of the project was not considered. Blue-sky designs get picked apart and implemented piecemeal. On top of that, developers have to save time by implementing less costly versions of the carefully crafted interaction design. What ships falls somewhere between a Frankenstein monster and Swiss cheese, neither of which provides much business value. It doesn’t matter that your design carefully considered your users’ needs. What matters to your users is the quality of the product that shipped.

Waterfall projects are often derailed by frequent shifts in scope. Agile teams fall prey to similar issues when user stories are prioritized according to stakeholder opinion or worse yet, political motivations. What feels like the most important feature to deliver today, is heavily influenced by the most recent fire drill and the CEO’s shifting focus. Add on what you learn during the project and it can start to feel like your target will never stop moving.

A project prioritized according to user research has solid footing. When the winds of change blow, you will have criteria established to justify staying the course or make the right adjustments.

Advertise here with BSA

October 04 2011


Getting Experience with User Experience

So you know you want to shape the digital user experience of…something. Welcome to life after college. Now what? I often get asked by recent graduates “Where do I even start looking for experience and work?”

If you’re asking that question, then you’re already on the right track. Many UX veterans have changed careers to UX and eased their way into the field. There isn’t much of a clear path for those who are just starting out and have a formal UX related education. The challenge becomes getting a foot in the door and putting those book smarts to work with a career.

The experience you get and the amount you learn is most certainly dependent on your motivation, resourcefulness, and ability to work with others. One of the variables that can help cultivate your skills as a UX Professional is where you choose to incubate your skills.

I have found that the size and type of organization can play a role in the learning experience and growth. Let’s take a close look at how work environments can differ from each other for those looking to start careers in UX.


All that money the big boys like Twitter and Facebook made didn’t come without blood, sweat, and caffeine. Get ready for lots of iterating, collaborating, and hat wearing. The workday may not be very structured and there may not be much in the way of a fancy UX lab or conferencing equipment. For someone new to UX, though, this can be a blessing. Startup UX is very grass roots. Gabi Moore sums it up eloquently:

For startups, you really can’t be perfect, you can’t afford all of the specialists that are needed to make a really awesome product. But something is always better than nothing. It’s just a matter of what that something can be.

You improvise user tests in loud cafes, you sketch on napkins, and you make presentations over Skype. Learning the basics and how to use the tools and resources available to you will help you appreciate and understand the fundamentals of user experience.

If you’re working at a start-up, you’ll notice that jobs have a tendency to grow or disappear very quickly, so it’s a good idea to keep in touch with your local user experience and start-up communities. They’ll serve as your mentors and provide a safety net as you grow into your user experience role.

Not only will you work very closely with people of a wide variety of skills, but you will get experience doing lots of things that aren’t strictly UX or even UX related. You’re likely to wear many hats within the company due to the pure lack of bodies to go around. Knowing how the gears of digital projects turn (outside of your own little UX corner) will make you a valuable asset to anyone lucky enough to hire you in the future.


In an agency, you’ll get good and you’ll get good fast. Agency experience is experience in dog years; although the work has a tendency to come in waves, those waves crash hard and loud. Be ready for long hours and high stress. Thanks to the way you’ll be billing your hours to the clients, you’ll likely be keeping one eye on the clock and the other on the quality of what you’re churning out. And you’ll have to speak to that quality and defend it to clients who don’t know you or your skills very well. You may work on 4 projects at a time, and once they are gone and out the door, that may be the last time you see or think about them.

It’s a little tricky to find an agency with a mentor who has the time to devote to formal training. Instead, you’re more likely to find someone with experience whom you can bounce questions and ideas off of. In most cases, it would benefit you to do as much reading and studying up as you can during the down times.

Though this may sound pretty rough, there are upsides: variety, efficiency, and interpersonal skills that will never become obsolete or out of date. Within a very short period of time, you may find yourself getting very comfortable interfacing with stakeholders, presenting to scary folks in big leather chairs, defending your work, and learning how to compromise (at least with less teeth-gritting than you may otherwise endure).

And speaking of getting comfortable in otherwise difficult situations, you might just find yourself picking up expertise in strange places—get ready to tap into your inner anthropologist. Within a 6-month period I learned the ins and outs of the designer fashion consignment industry all while learning how custom wedding invitations are glued. And it was complicated.

Small company

At a small company, you’ll spend your time with only a few projects, rather than the crashing project waves of an agency. You will get to know them inside and out. The benefit of working on fewer projects for longer periods of time is that you can build on your own research during the product lifecycle. You’ll get the chance to design something, then go back to test and refine. There is no better way to learn than from your own mistakes.

Where user experience has yet to make it into the lifeblood of the company, you’ll get to evangelize the importance of user experience to any outsiders and nonbelievers. You’ll learn how UX fits into the processes of managers, developers, visual designers, and marketers. Within a year you should be pretty good at wireframing, sketching, creating user flows, writing functional specs, and running and applying findings from all types of user testing.

You’re likely to work on a team of people in the same field as you, but with different philosophies and experience to bring to the table and learn from. Collaborating and working alongside like minds is a great way to get your feet wet while keeping a safety net in place for those times you mess up.

With fewer projects comes the risk of getting bored and the feeling that you may be falling behind with trends and new buzzwords. Make sure you love what you’re working on and push yourself to learn new skills.

Medium / large company

A larger company certainly has its advantages over the little guys. Part of the job here is evangelizing good user experience practices while learning how to win small battles. Asserting yourself as an expert (or what I call “UX street cred”) can make your job a joy, and it’s a powerful skill to have in your back pocket. You may get the chance to impact methodology, improve corporate outlook and strategy for user experience, and affect huge projects. Making a difference at a large company is an incredible feeling.

There is usually room for steady growth and more responsibility (as opposed to most “flatter,” smaller companies). The trade off is you may find yourself having to navigate a maze of high school-like politics and drama. One of the common responsibilities of a UX professional at a medium or large sized company is maintaining and being the guardian of human interface guidelines, functional specifications and personas. A lot of best practices should already be in place when you get there, so this is a great place to learn the basics.

Academia / corporate research

Some UXers really enjoy being at the front lines of technological innovation and industry standards with human computer interaction. The research that UX professionals cite to colleagues and clients, the stuff that’s supporting their recommendations, has to come from somewhere… and that somewhere is you. Be ready to get very good at running and facilitating structured and rigorous user tests.

By doing funded research, you’ll probably get access to testing labs and the ability to play with cool new technology years before the neighbor’s kid gets to. Researchers were designing and refining gestural recognition and touch interfaces decades before they made it into the Kinect and iPhone.

If you get a chance to work with students, you may find you learn just as much from them as they learn from you. And the best part? You’ll probably work very close with a professor; who could ask for a better mentor?

Keep in mind, that if you plan to leave this kind of position in the future, you’ll be leaving without gaining valuable experience with client/stakeholder management, presenting, and budgeting time. With the (potentially) flexible hours, this kind of job may pair well with occasional freelance work to make you a well-rounded UX machine (but shhh, don’t tell the brass).

Go forth and make us proud

The scale of and variability between companies and organizations obviously varies, as do the types of experience and work. Naturally, there are exceptions to all of these observations and they really depend on you. No matter how you chose to step into a UX career, there is no replacement for creating your own learning opportunities. That means not stopping when your workday ends, reading anything and everything UX related, and being active in your local and/or online UX community.

Question from the Editor: What kinds of places do you think best help prepare new UXers for a bold and bright career? Let us know in the comments!

Advertise here with BSA

August 30 2011


Personas: Putting the Focus Back on the User

Personas should represent your user base (hopefully not pictured above).

In the art that user experience has become, we talk a lot about not letting our client’s personal preferences get in the way of what would be best for the user. Yet no matter how often we remind our clients and teams of this throughout the design process, we still find that users are unpredictable, and some changes need to be made post-launch to reflect how they actually use the product.

There’s no fool-proof way to avoid this problem, but I do think that we can improve our processes to be more user- and goal-based. No, I’m not talking about doing more studies with users, eye-tracking studies, or heat maps; what we need to do is bring the user into decisions we make from the beginning.

This is easier than it sounds, and a simple way to accomplish this is to incorporate personas into our work. In design circles, a persona is an archetypal representation of a user. The idea is as old as marketing, but Alan Cooper solidified the idea into a design philosophy in 1995, and designers have been using it to improve their user experience ever since.

If you’ve paid any attention to the UX community, especially in the last few years, you’ve likely heard the word “persona” tossed around a lot. From what I’ve seen, however, the number of people specializing in user-centric design who actually implement personas is pretty slim, and the number of designers who make them a pivotal part of the process is even slimmer.

So, what’s a persona?

Put simply, a persona is a representation of a client’s customer. They are fictional characters that we create, and they serve as a reminder of who our users are. Like any good fiction, a well-made persona has its own story to tell. The more believable the story, the better representation the persona is of users; the more accurate the representation, the more likely our decisions will reflect the user’s needs.

Our persona’s “story” consists of a name and photo, title, byline, and, most importantly, his goals and frustrations (or “pain points”). Our job is to meet his goals and solve his frustrations with what we’re building. Ultimately, personas help us make the user’s needs more memorable throughout the process.

Some teams may include stories and more in-depth biographical information to assist in understanding how the user might respond to certain decisions. This may make the personas more realistic, but be careful: people are not necessarily stereotypes, and we don’t want to use personas inappropriately by trying to oversimplify our target demographic users.

Case study: 3Degrees

As I write this article, the team at The Phuse is working on a cool project called 3Degrees. The purpose of the application is to allow users to tap into their existing social networks to find new people through mutual friends.

Based on our client’s research, when we began developing the application there were two basic types of people that would be using it. We worked with the client to create personas of those two users in order to help keep our development on track.

Meet Steve

This is Steve, one of our two personas.

This is one of the personas we created for the 3Degrees project; we put a face and name to our user to make the process more memorable and human.

Our next effort was to write out the goals and frustrations of our new friend. This is the real meat of the persona. By writing them out, we know what goals we have to meet and what frustrations we’re trying to solve.

We know a whole lot about The Goings-On of Steve.

For the 3Degrees project, we also decided to include narratives to make each persona a little more memorable; Keep in mind, though, that this can be tricky. Background information may lend an air of credibility to our persona, but we must be careful not to stereotype.

When do you need a persona?

Any time you’re working with user experience, you should be using personas. In most cases, though, personas are used when there is more than one type of user to keep track of. For example, when working on 3Degrees, we decided that there were two different types of users accessing the site.

Originally, the goal of the 3Degrees project was to connect people moving to different cities. Our client’s research told him that people new to an area (and looking to network online) are generally interested in one of two things: friendships or romantic relationships. Therefore, we decided on two different types of users to satisfy each of those roles: one looking for a date (Steve, above), and another who is looking friend to play tennis with (Ramona, not pictured).

We’ve seen projects with up to five personas. Some projects may have even more. Trying to remember those five user types would be pretty difficult without something to remind us constantly about them. Instead, the personas allow us to refer back to the user(s) at each step of the design process and make sure all their needs are being met.

Think of all the times you get in debates with clients or colleagues about where to place an element, how something should be styled, or whether a feature is needed. These debates can end up getting heated based on people’s egos and their personal opinions on what looks better and how something should be. Personas give us the opportunity to avoid that sort of conflict within design teams and with clients. They help mediate discussions based on the goals of the users.

Instead of saying, “I think the photos should be bigger,” we might say, “Well, Steve will likely be more interested in photos and basic information of other potential matches than how they answered specific questions.” In this way, we’ve given the decision to the user, and explained his reason for making it. Our personal opinions and egos are no longer relevant; only the user’s opinions matter.

Personas have a life too, y’know

In 2010, John Pruitt and Tamara Adlin wrote a book called The Persona Life Cycle, where the author related the creation and use of a persona to the stages in a person’s life. This is a handy way of looking at the life of a persona throughout the project and beyond. For example, there is essential research and planning that goes into their conception to ensure they are being brought into an environment that can nurture their growth. Then, throughout their adulthood, they help us make decisions and grow with the maturity of the project.

Sad zombie persona is sad.

Much like some adolescents, I think personas can feel left out as well. We may not look at them enough, or we might ignore them completely. In fact, we have to be careful, because as Tom Allison says in his UX Cafe presentation, it’s also possible to have these “zombie personas” that lie neglected around our processes. If we don’t use them, they’re no better than the ones that go wholly unrealized.

It takes a village

Now, you might be thinking “well, if I were a person in charge of designing the personas, I’d just make it agree with everything I say.” This is a problem teams suffer from. The importance of a persona is not to represent you, it’s to represent the user, whose goals and frustrations are his or her own.

User experience only works when the people that are developing the product work as a team. It’s not only the designer’s role to come up with a design that is user-focused, but the responsibility must also be taken on by the client and developers.

To paraphrase an ancient African proverb, it takes a village to raise a child. In a similar vein, it takes a team to create a persona. They can’t be created by one person, otherwise they’d be too subjective. We need to have the whole team involved in the process to ensure that personal biases are kept to a minimum. It’s useful to base these personas on real users and not just ones we think might be users, therefore some field study and customer development is always important prior to the persona’s conception.

A great way to embed personas throughout the process is to have different members of the team be responsible for different personas’ goals. That way, when decisions are being made, one team member isn’t trying to figure out if the goals for five personas are being met; five people are weighing in with their thoughts about their specific personas.

Convincing people to use personas

In 2009, Frank Long conducted a study with 9 groups of students from the National College of Art and Design in Dublin that got the groups to use personas and find out how effective they were in their process of creating designs that served the users, with Neilsen’s Usability Heuristics as a base for the scores that were given.

In the study, Long found that the Beta and Gamma teams using personas scored higher on Neilsen’s list than the Alpha team that acted as a control group. In the focus group that concluded the study, group members noted that personas did help guide design decisions, and they were able to clearly recall their persona and its key bits of information.

Goals: Foster world’s sweetest mullet; develop hot lady repellent. Frustrations: Bikes with gears; rules.

While this study isn’t as detailed as some would hope it to be, it does reflect the usefulness of personas as a tool. They don’t take long to build or maintain, so there’s really no harm in taking a bit of time to put them together.

Just ask any team that has used personas in their design process; there is an important role for personas in our workflows, whether they’re 100 percent quantifiable or not.

How important is the user in your design?

We know it’s not fool-proof, but personas give us a way to manage user goals and frustrations before the application launches.

There’s a lot of debate over the need for personas in user experience, and there’s a lot of truth in statements against their use. Ultimately, however, personas are a physical representation to remind us who we’re building for, much like one would have a list to remind oneself of what to buy at the grocery store. When used appropriately, personas can be an invaluable tool in the design of important user experiences.

Once again, personas should always go hand-in-hand with real user interviews and studies, and all the other tricks of the trade that we have come to value so highly like heat maps, eye-tracking studies, and, of course, sets of proven user patterns.

It’s vital to the success of our applications to keep the design process focused on the user experience. How are you keeping the user in mind throughout your process?

Advertise here with BSA

August 23 2011


Hotel Booking, from Start to Finish

Everyone has unique expectations when it comes to booking a vacation – some want to be swept away while others seek complete control. It can be a truly exhilarating experience, as long as the system facilitating it isn’t too frustrating.

In the past, a travel agent was the person who directed the booking process, taking the research stage out of the customer’s hands, but this has evolved over time. Travel reservations were made by computers since around 1963, when Trans-Canada Airlines helped develop ReserVec—a simple but fast booking program. This system had many limitations on how it stored data, but it paved the way for more complex multi-tasking booking systems that are used today.This ongoing development of computer reservation systems made the move online a natural leap, and today, every part of the booking process is closer to the user. They are finally in control of their travel plans, and online booking is now one of biggest revenue streams for the hotel and travel industry.

Turning user expectations into a cohesive interaction is a huge undertaking, and one I’ve enthusiastically approached while developing UK hotel chain websites. I’ve discovered that one of the more indispensible processes is what Alan Cooper describes as goal-oriented design. User goals are the primary focus in Cooper’s approach, but it also mandates that the user, the business, and the technology be considered together.

Business and technological concerns should also be taken into consideration at the beginning of a project.

This approach is ideal for a hotel booking site as it gives the designer a means of understanding how the underlying business structure (for example, how the central business organization interacts with the hotels, how rates are set up, child policies, the services offered, etc.) needs to gel with the existing reservation system to help create a smooth booking process that satisfies users and supports business objectives.

Yes, this stuff tends to get complicated. But by understanding user expectations and behaviors, we can then create a story for them. Then, when we know what the user wants we can break down all the elements—user requirements, business structure, services and objectives, and technical considerations—and start creating really specific requirements for what the site needs to do (and how we can go about doing it). I’ll go through these step by step, and then talk about the design process that I’ve found works best.

Of course, consider the user

All hotel site design begins by addressing their users’ needs and goals. It’s essential to identify the specific types of customers unique to each brand. For example, Four Seasons is a luxury brand aimed at leisure travelers—think spa retreats and weddings—whereas the hotel chain Ibis is geared towards business-savvy travelers. In other words, different users want different types of information to help them make their decision.

To be clear, that decision is booking a room, and our goal is to make that as easy as possible. Fortunately, regardless of user types, most people take very similar steps to get there. My own research indicates that users follow these thoughts and actions:

The user’s goals will lead to questions that the booking process should answer. Each of these questions and answers become part of the user story. So, let’s take a look at each stage…

The arrival

There are many different ways that a user will arrive at a hotel site. Most people I’ve spoken to will use a search engine to find hotels and destinations that suit them or an aggregator site (such as to find a good deal. is just one of many travel aggregators that have become almost ubiquitous with the booking process.

I’ve also seen site visitor statistics showing that direct visits to a hotel site are much lower than other entry points and the chains I’ve worked with often confirm that they have a low percentage of return bookers. It’s unclear as to whether this is due to user’s not returning directly to the hotel website, or due to no loyalty for hotel chains; however, every start-point of the user journey should be considered when developing the site architecture and content, and it should be clear at each point of entry how users can achieve their goals.

Checking in with easy-to-find info

According to a Toluna survey of over 2,000 UK consumers, 53% of respondents found and booked their holiday online, while 30% conducted online research first, then booked their reservations offline. This means that over 80% of users research their hotel and travel options online, making this a very important step in convincing the user to book. Never assume that users will have researched all the hotel details, such as rooms and location, before they start configuring their booking; some users will explore a site while others will dive straight into the booking processes expecting the information they want to be there. In other words, you should always be thinking about what useful information will help the user move on to the next step.

The types of information they’ll be looking for are:

  • The emotional

    Where do I sign up?

    InterContinental Hong Kong

    The kind of information users search for is also really important to consider. Pictures are consistently shown on usability testing as one of the first things users look for—not surprising, considering the emotional impact they can have on us. The Toluna survey supports this too: 59% of respondents used photos of the destination and accommodation to help them choose a particular place to book from a travel website.

  • The rational

    Users also tend to look for more rational information before making a decision, and what better source than the crowds? 39% of the users on the survey went to TripAdviser for reviews, and a Travel Zoo survey found that an astounding 81% of respondents also used hotel review sites.

  • Price is of course a significant deciding factor. The Travel Zoo survey found 64% of users said price was more important than the destination. Finding a good deal is also important; the Toluna survey showed that 56% said their key reason for booking online was to find lower prices. The increasing popularity of hotel and travel aggregator sites also demonstrates the importance of price, as these sites facilitate research and price comparisons.

How the user chooses

We all like things to be easy when we buy online—an online shopping experience should never make the user feel disappointed or frustrated and should always be credible and trustworthy. Booking shouldn’t be any different.

Clear information is vital, and the Toluna survey agrees: 64 percent of users would abandon their booking if hidden charges were discovered, or if pricing was generally unclear. 19 percent would drop it if they couldn’t find enough information.

Availability is the next user need that hotel sites must satisfy, but this can get quite complicated in a hotel booking process. Most online shops selling physical goods have stock—the number of items in the warehouse. There is a fixed quantity and a set price. Hotels and airlines, however, have a multi-faceted inventory – rooms categorized by type (such as double, single, deluxe), with various rates (like advanced booking rates, special offer rates or flexible rates, and availability). Hotel inventory requires much more management and has many different considerations when dealing with the display of inventory and availability. This can lead to some interesting challenges for the user interface, challenges that many hotels are still trying to get right.

Flight-aggregation service Hipmunk takes a novel approach to this problem, displaying travel data so it’s easier for the user to understand. Inventive solutions like this really improve the whole booking process, not to mention that they encourage users to recommend and reuse the site.

Book ‘em

The actual booking is where the interface design really needs to work hard. To get users from Point A to that final confirmation page, the process needs to be as smooth as possible. Making the process simple and effective for the user is your task, but what makes the user interface more complex is adhering to the hotel business organisation and technical considerations that Alan Cooper’s goal oriented design process brings together.

The business challenges

Before mapping out the booking process, there are several challenges that should be considered. I’ve discovered that hotel business can become very complicated; along with multiple hotels, there could be multiple business rules, such as child policies, cancellation policies, and how room types, rates, and offers are managed. Procuring this type of information from the business is often a challenge of its own, as the details can vary across each property and may not be held in a central location. The best way around this is to ask questions (rather than assume) all throughout the project – from wireframing and prototyping to final development. This way, fewer problems will arise when the system gets tested.

The technical challenges

Hotels, as well as other travel sites, use computer reservation systems. The online booking system we create needs to hook into this existing reservation system. This means that we must thoroughly understand how the reservation system works before beginning to design the interface for our booking system. Getting as much documentation as possible beforehand and ensuring the developers are involved in the design process makes understanding the limitations and requirements of the system much easier.

Booking doesn’t need to be the end for the user journey within hotel websites. This is the fun part! Testing has shown that users respond really well to useful suggestions and information to help them plan their holiday, so think about what’s next—cross-sell more opportunities, be part of the holiday planning process, and find ways to keep the user engaged with the brand. This will only help to improve brand recognition and loyalty by keeping the hotel website in the front of the user’s mind.

Now you know…

Designing a booking process can be quite fun—it’s interesting and complicated, and overall you’re delivering something that should make people feel good. It’s great being involved creating a new process from start to finish, thinking about the user journey and how to create a better user experience. Through the 3 hotel projects I’ve been involved in where we created the full online booking process I’ve found that even though I’m getting closer to a solid framework for it, there are so many things that need to be considered for each individual business and user group.. Framework or not, this is still a challenge. Technology is advancing too, and with that, the future holds the opportunity to create much more efficient, innovative and richer experiences.

So, think of the user. Think of the business. Think of the technology. By marrying these elements, you’ll be that much closer to bringing your user interface together to make something elegant, usable and successful.

Advertise here with BSA

August 16 2011


Top Approaches for e-Commerce Product Videos

Product videos are more engaging and have higher conversion rates than static images. But implementing product videos is expensive and there are many different approaches for doing it.

Product videos started getting a lot of traction on large e-commerce sites in 2010 (though as I’ve already pointed out, they haven’t caught on everywhere). The number of videos launched by top retailers increased dramatically, particularly in preparation for the holiday season.

In their “State of Video in e-Commerce” report for Q1 2011, SundaySky illustrates the total number of product videos offered by top retailers on their e-commerce sites.

One reason that product videos are becoming so popular is that more and more consumers have the fast connections and computers required to display videos without choking. Also, recently released research reports indicate that videos increase conversion over the same product pages that have only static images. For example, Treepodia found in A/B tests for their clients that visitors who watch product pages videos convert more than twice as often then those who don’t. For certain categories, the conversion differential was even higher.

In Usography’s 2011 Q2 UX Audit, we found that 16 of 100 retailers had launched product videos in their primary e-commerce catalogs. We looked through the videos offered by these retailers for patterns, and discovered that the patterns fall into 3 main categories: Contents, Production Method, and Presentation Space. Let’s take a look at what these categories entail.


Product videos launched by different retailers have widely varying purposes, or customer goals, as reflected in their content strategy. Although content approaches varied widely, most fell within the following categories:

  • Product in Use
  • Features and Benefits
  • Instructional
  • Slideshow
  • Narrator and slideshow

Product in Use

Showing a product in use is an effective way of alleviating customer doubts about a product they’re viewing online. With static images, it’s difficult to determine how a product will look and feel when it’s actually being used. This is a reason that customers often cite in interviews for needing to go to the store before purchasing a product they discovered online. Providing a video that shows people using the product can meet the needs of some of these consumers, thereby increasing online conversion. REI’s product videos (illustrated below) are a good example of the product in use video content category.

Features and Benefits

Video can play the role of a sales person, explaining the features and benefits of a product. This is the approach that Cabela’s (illustrated below) has taken with its product videos. Whereas the Product in Use videos seem rather neutral, the Features and Benefits videos are more salesy, and may give the impression of being like a commercial. To encourage customers to watch these videos to the end, make sure that the script focuses on attributes that help viewers decide between similar products.


With products that are more complex to purchase, like home theater systems, it makes sense to have product videos that are instructional in nature. Presumably, the less confused customers are about the product, the more likely they are to investigate and make a purchase. That is the approach that Crutchfield and B&H take with their product videos. Crutchfield’s videos (illustrated below) don’t necessarily address individual products, but talk about how to evaluate or install a category of products.


When a product video doesn’t actually contain motion video clips but still images that are manipulated, the contents tend to be more similar to a slideshow than a commercial. There are images and bullet points that change to other images and bullet points. The PC Mall product videos we reviewed (illustrated below) were of the slideshow variety. The benefit of this type of video is that it is inexpensive to produce, and it gives customers useful information without them having to read the fine print.

Narrator and slideshow

The slideshow product video can be enhanced with real video by splicing in a narrator’s introduction and explanations. The narration portions can be shot in a studio, while the slideshow portion is taken from existing photos and marketing materials. We found this type of video on (illustrated below). Like the slideshow, the benefit of these videos is that they are relatively inexpensive to produce in large quantities, and have the added benefit of a person on camera explaining the benefits of a product.

Production Method

Retailers pioneering product videos tended to use one of the five following methods for producing their videos:

  • In-House
  • Automated
  • Manufacturer
  • Partner
  • User-Generated


The most expensive ways to add product videos to an e-commerce catalog is to produce them in-house. By in-house, I mean that the retailer bears the full cost and responsibility for the video production, whether actually filmed by employees or third parties. The biggest advantage of this approach is that the retailer can directly tailor the script and imagery to speak to the needs and wants of their customer segments to trigger purchases.

Zappo’s (see illustration below) is one of the leading examples of this approach. Mike Robertson, a consultant to Zappo’s on product videos, said that Zappo’s produced almost 60K product videos in house last year alone and plans to increase that to more than 100K videos this year. He also said that 77,316 website visits each month are attributed to Zappos’ video listings in search engines.


Automated product videos transform existing product images and marketing copy into a dynamic presentation, and format it as a video file. The products are not actually filmed in usage. Still images are manipulated to give them the sense of motion, like a multimedia presentation transformed into a video. The advantages are low cost and rapid automated conversion of a complete catalog. Treepodia is a leading provider of automated videos, and asserts (quoted above) that research shows an increased conversion rate due to the automated videos. Retailers like Tool King (illustrated below) are adding large numbers of automated videos to their e-commerce product catalogs.

Manufacturer Produced

Many retailers are likely to wait on their vendors to produce web- and mobile-ready videos before they take the plunge. This isn’t strange, since manufacturers currently provide the visual and marketing assets incorporated into many online product catalogs. Videos produced by manufacturers tend to look like commercials more than demonstrations. Nike (illustrated below), Dell, and Kodak have led the way among manufacturers who provide digital videos for e-commerce consumption. Many manufacturers will probably follow their lead. But even if manufacturers provide the videos free of charge, retailers still have to go through the cost of uploading, indexing, reformatting, monitoring, and updating product videos.

Partner Produced

Some retailers are using relationships they have with partners to get videos produced, which they then load on their e-commerce sites. For example, B&H Photo partnered with the National Association of Photoshop Professionals to produce videos of high end SLR’s. The videos have an instructional focus, and prominently feature logos of both organizations.


Some customers get a thrill from seeing their creations posted on high-traffic web sites. channeled that energy by launching video customer reviews several years ago (illustrated below). The products that have video reviews are still few and far between, but because of the rising popularity of user-generated video on sites YouTube and Vimeo, this approach could become viable for other retailers as well.

Presentation Space

There are a variety of methods for presenting product videos. Each method has advantages and disadvantages. For retailers, the best video presentation is one that transitions from viewing to purchasing in as few steps as possible. The most common presentation patterns we observed in the UX Audit were:

  • Embedded
  • Overlay
  • Separate URL


An embedded video can be viewed without leaving the product detail page. The advantage of this approach is that customers remain on the product page, and can purchase the product afterwards with just one click. The disadvantage of this approach is that the video has to be integrated into the page template and code, and it usually occupies a relatively small area, making it difficult to see details. QVC (illustrated below) and Nike follow this approach. QVC’s product videos are TV clips in which the products were featured, which means they are very relevant to the product purchase decision.


Most sites that have product videos use some kind of player overlay on top of the product page that was being viewed when the video icon was clicked. The advantage of this approach is that it is flexible in terms of the player, code, and size that are used to display the video. The disadvantage is that users then need to close the window in order to return to the product page, a step that isn’t needed in the embedded presentation. Some retailers, like Patagonia (illustrated below), have designed this overlay so that it reinforces the brand.

Separate URL

Some retailers code product videos so that when clicked, they open a new browser window, with its own URL. I’m not sure what the advantage of this is, but if you have ideas about that I’d appreciate you adding a comment at the end of the article. The disadvantage is that users can click away in the new browser window to some other retailer site.

Think before taking the leap

The only reason a retailer should go to the expense of launching product videos is to increase sales. Before committing resources to videos, retail UX teams need to understand their customers’ shopping behaviors and purchase decision processes. Then they can use the above patterns to select the most appropriate approach for their categories of merchandise, perhaps testing a couple of different approaches for conversion rate variation. Video will likely be a feature on nearly every e-commerce site in the near future and it’s up to retail UX teams to figure out what works best for their customers.

Advertise here with BSA

August 09 2011


Deliver the Future, Gradually

The evolution of the iPod

What is the point of good design? To create good experiences. Good design makes the objects, places, and interfaces we use every day pleasurable to interact with. It allows people to do the things they want or need to do, in ways that are (at least) painless, and (at best) delightful.

Good design also does something else: it raises the bar for what people expect from their experiences, advancing the public high-water mark for “best user experience.” As the creator of a web or mobile application, yanking that bar upwards is your goal. But it’s important to keep in mind a key fact: People are resistant to change. You can only raise the bar as high as your audience will let you; deliver an experience that’s too far from what they’re comfortable with, and they’ll walk away.

People just weren’t ready.


Mid-century industrial design pioneer Raymond Loewy (1893-1986) summed up this principle in the aphorism “Most Advanced, Yet Acceptable,” or MAYA. Embedded in this maxim is the truth that designers and innovators must pave the way toward the future, but in gradual steps—delivering experiences that break new ground, but still contain enough of the familiar to be “acceptable” to the people for whom they’re designed.

iMAYA: The principle in action

In the realm of product design, it’s hard to find a better example of MAYA in action than Apple. One only has to look at the evolution of the iPod to see the interplay between “Advanced” and “Acceptable” ratcheting upward over time.

Some early iPod features were, in part, concessions to what was then familiar—such as buttons that were distinct from the scroll wheel (see the lead image for reference). The first generation iPod was a groundbreaking product in its own right; as time broadened both cultural acceptance and technological possibilities, the iPod’s designers were able to push their product design farther and farther, losing the extra buttons and streamlining the interface. Taken to one extreme, the designers of the iPod Shuffle eventually eliminated the playback controls from the unit entirely, placing them on the headphone cord instead. (In the next generation, the Shuffle’s designers reversed this decision—a sign that design innovations which force customers to use your proprietary headphones are unlikely to become Acceptable.)

Now, in the time of the iPhone with a full touch screen, early iPods look quaint, almost archaic. But in 2001, the iPhone would likely have been too far outside the bounds of the familiar to make any sense to consumers. Only because of the progression of MAYA do we take for granted its sleek look and feel today.

Make it sexy

Apple’s success at manipulating MAYA over time demonstrates a key aspect of the MAYA principle: the best way to win public acceptance for a breakthrough innovation is to make it sexy. People are too entrenched in the familiar to choose a newer, better product purely by reason or logic. In author Bruce Sterling’s words, “The customers cannot be harangued with facts in a boardroom. The customers must be seduced.” Eye candy is a crucial part of user experience design. The complete user experience is what turns your customers into loyal fans, but the visual aesthetic is what gets your foot in the door. It’s the reason everyone wants their product to be “the next iPod.”

The candy’s the iPod. We’re the ants.


Apple has built their entire product line on the “make it sexy” mantra. And it’s not hard to find examples of other leading brands—such as OXO, Method, and Simplehuman—whose designers understand the same idea.

How does MAYA apply to UX design for the web?

In website and software application design, the same principles apply: you need to balance the groundbreaking with the familiar. The task-oriented focus of the web makes it all the more imperative that you avoid frustrating your users; you won’t get a second chance to impress them. So when you add exciting and innovative functionality, be sure that you’re including plenty of analogues to an experience they’re already familiar with. When you hit the right balance, customers will learn how to use your site quickly, and come back to use it again. These returning customers are an ideal audience for you to introduce gradually advancing functionality to over time.

Etsy, the e-commerce hub for handmade items, is an excellent example of a site that strikes the right balance between Advanced and Acceptable. Since the products on their site are not household brands, shoppers tend to do more browsing than on traditional shopping sites. Taking advantage of this, Etsy offers a variety of ways to browse—from traditional to innovative.

One of my personal favorite Etsy features is the Color Browser. The Color Browser presents me with a color grid; clicking a color displays thumbnail images of products matching that color, arrayed haphazardly around my chosen swatch. I can click into a thumbnail image for more detail, and I can drag images around the canvas to arrange them how I please—even throwing some off the canvas entirely. It’s a fun and effective way to explore the possibilities of the site if I’m starting with a color preference in mind.

Apparently, Etsy designers are Batman and Transformers fans.

Etsy – Shop by Color

Another Etsy experiment that I loved was the now-defunct Connections browser. This tool started by displaying an icon for a single Etsy user, surrounded by products that he or she likes. I could click on a product to see other users who like it, connected to the product by thin lines in a similar manner to Visual Thesaurus. Over several clicks, I would gradually build a web of interpersonal connections based on users’ favorite items. Why did Etsy ultimately remove the Connections browser? I don’t know for sure, but it may have been replaced by their newer experiment, the Taste Test, which displays recommendations based on items that you rate, Netflix-style. Perhaps Etsy discovered that users care less about browsing based on what other people like, and would rather browse according to their own specific preferences.

Etsy’s browsing tools feel excitingly responsive and somewhat futuristic. The animation and interactivity is rich, smooth and well-executed, seducing me into playing around with these tools until I’ve achieved a level of familiarity, and then I’m off and running. Crucially, the technological slickness is by no means the end of the story; these are genuinely useful features that solve specific problems and allow me to digest information in previously unimagined ways.

Etsy’s browsing tools do 3 things that strike a good balance between Advanced and Acceptable:

  1. Familiar visual metaphors: The visual metaphors involved relate well to things already in my experience. I know what it’s like to sort cards or photos on a messy table, so I have a good physical sense of what’s going on with the color browser; I’m not lost and clicking around randomly.
  2. Traditional fallback options: If I get stuck, there are other, more traditional options clearly and immediately available, such as the top search bar and filter options. These will catch my eye and provide another option before frustration sets in.
  3. Sensible scope: Etsy has wisely confined these novel features to an activity—browsing—which is less hurried and task-driven than most activities on the web. Putting something unexpected and novel into the Search process or the Checkout process could create needless, frustrating barriers; innovation in those areas needs to move forward at an even slower pace.

Break new ground—one step at a time

Raymond Loewy’s MAYA is inseparable from the aesthetic he popularized: streamlined forms that evoke speed and modernity. In Loewy’s time, these were fresh innovations.

Raymond Loewy, standing on speed and modernity.

Library of Congress

The prevalence of this style in product design today speaks to how successful MAYA is at describing the relationship between people and design. As seen with Apple, Etsy, and others, the successful use of MAYA rests on three key mandates:

  • Push the boundaries of design and technology beyond your users’ expectations, but keep enough familiar patterns to let them orient themselves.
  • Gradually advance your design over time, as technology and public sentiment evolve to support this advance.
  • Make it sexy—where reasoned arguments fail, eye candy often succeeds. This applies both to the visual aesthetic, and the technology underneath it.

As a website creator, the impulse to innovate is healthy. And, as with most things, moderation is key. It’s tempting to shoot for something totally unique that nobody has ever seen before. However, it is our job as creators and designers to ground our ideas in enough of the familiar to be acceptable to our users at this moment. Without familiarity, your totally unique feature is doomed. Push the boundaries of the familiar, a little at a time, and your product will stand as a hallmark along the timeline of design advancement.

The homepage image for this article is credited to X-Ray Delta One

Advertise here with BSA

July 21 2011


Creating Gesture Guidelines for Tablets, Part 2

Participant during the Guessability Study

A participant during the Guessability Study

How do you come up with the right gesture for an app or a game? If there is no precedent, then you’re on your own. Here I’ll discuss a 4-step method that’ll allow you to create gestures for specific actions, with validation from end-users.

In the first part of this series, we discussed the importance of having guidelines for gestural tablet interaction. Now that we understand the need to get the interaction techniques right, we’ll learn how to create gestures for specific actions.

How to conduct a gesture creation study

The Basics

Gesture creation is a 4-step process. Each individual stage leads on and informs the proceeding step. This method can be used to discover gestures for more than one action; I used this process for 18 distinct actions during my study.

Setting up the Gesture-Meaning Association test

Setting up the Gesture-Meaning Association test

Guessability study

Show subjects a short, two slide animation: before-and-after screenshots that shows the outcome of the gesture. Here you can view the video I used for the zoom-in action.

Using an app that can draw multiple inputs at once such as Doodle Buddy, place the “before” screenshot as the background of the drawing app.

While recording the screen, ask the participant to draw the gesture that they feel would invoke that desired action.

Setting up the camera to record the gesture creation

Setting up the camera to record the gesture creation.

Take a screenshot of the completed gesture and stop recording on the camera.

Ask the user to rate their created gesture based on the statement: “The gesture I picked is a good match for its intended purpose,” and rate the gesture on a 5-point likert scale from “Strongly Disagree” to “Strongly Agree.”

If you want to be able to identify similarities between participants, then you should aim to have around 10+ users for this stage.

Rating study

Now invite 3 other people to watch each gesture video and ask them to rate the effectiveness of the gesture for the intended action; use the same question that was asked in the Guessability study.

After all the raters have rated each gesture, produce an average score which will identify a consensus on whether specific gestures were a good match for the intended action.

Gesture creation

With all the information you have compiled from the previous two stages, you can identify similarities and issues from the collection of gestures created during the Guessability study.

In my study, for example, I noticed many participants were utilizing letters and symbols to represent certain actions. Therefore, these symbolic gestures were used for many of the gesture/action pairings I created.

Moreover, I noted that gestures that were used in advertising smartphones and tablet devices received high approval ratings; I therefore decided not to adapt or change gesture/action pairings that were already well-known.

For this stage in the process, the way you select gestures depends on your overall goals. For example, if you’re designing a game and you want the action to be challenging to invoke, then selecting the most popular gesture might not be the best choice for you. However, this process will provide you with all the information necessary to make these important decisions.

Gesture-meaning association test

So you have what you believe are ideal gestures for specific actions. Now it’s time to validate the gesture/action pairings you have created.

A small set of users—3 to 5 would be ideal—will be provided with several pieces of paper: half will be the names of the actions and the other half will be the actual gestures. The participants will be asked to match the gesture/action pairings that they believe are correct.

Setting up the Gesture-Meaning Association test

Setting up the gesture-meaning association test

This will allow you to identify the accuracy of selection, where you can discover which pairings were challenging for participants to match, and which ones were easier. Moreover, you can note the speed with which selections were made—were certain pairings selected through a process of elimination?

Final thoughts

This method can go a long way to ensure that the gesture/action pairings you are using in your apps or games are the best they can be.

There will always be actions that are challenging to depict with a gesture, yet this method allows you to identify these, providing you with opportunities to design around such constraints.

Give it a go.

Lead image for this article (on UX Booth homepage) courtesy of quinn.anya

Advertise here with BSA

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...