One of the best things about user research is that anyone can do it. On the other hand, it takes real commitment and a lot of personal development to do user research well. People commonly assume that research is research—and doing any kind of research is better than doing none at all. Unfortunately, this isn’t always the case. Not all user research is created equal. Flawed research can be a significant liability to the success of a product, as well as the company developing it, so it really is important to get it right.

We first trialled this method in May 2007 for the redesign of an online education and training website. We decided to run design workshops as one of the initial stages in the process in order to explore users’ decisions around education and training, but we wanted to understand what triggered their choices in a broader sense; so we asked users to complete a homework activity.

While I teach whole workshops on the subject of user research, in essence it really is very simple. User research is about understanding an audience; what they need, what they want, what they think, how they interact with other people, information and information systems such as websites. And perhaps most importantly, for all of the above, it’s about why.

There are many user research methods one can use, and there are even more variations and names for them. But regardless of what name they’re given, methods should be chosen that are suitable for the situation at hand.

As discussed in the earlier article Successful collaboration requires support, there needs to be a centralised team that supports collaboration tools throughout the organisation.

One of the key roles of this central team is to help business areas choose the right tools. This starts with determining whether there is a legitimate and practical need for collaboration tools. The right solution (or mix of solutions) needs to be selected, followed by support, guidance and training.

In practice, this means asking a lot of questions. These build an understanding of the current situation, points of pain, business context, and business needs.

To kick-start this process, this briefing outlines a number of questions the central team could ask. Use these as a starting point when approached by business units, and adapt them to fit the specific situation.

These questions must not be seen as obstructive, or as a hurdle designed to minimise the spread of collaboration tools. Instead, they should be used as a basis for constructive dialogue, with both sides learning valuable information.

Information gained from these types of questions is invaluable for the central team, helping them design or adapt collaboration solutions to fit the organisation’s changing needs.

[CM Briefing 2009-14, read the full article]

This is where the concept of “triangulation” comes into its own. Also known as “mixed method” research, triangulation is the act of combining several research methods to study one thing. They overlap each other somewhat, being complimentary at times, contrary at others. This has the effect of balancing each method out and giving a richer and hopefully truer account.

One problem with this approach is, however, that many organisations omit the second part of “launch and learn”. Another is that as the organisation’s web presence matures, the quality of solutions comes to the fore. If users cannot complete what they came to do or if they need to spend too much effort finding the information that is relevant to them, they will simply leave.

As my company planned for a recent study, we noticed we were asking more questions about the product to help us determine how our research could drive key business results. For example, we explored product descriptions, market positioning, selling points, key differentiators, and other critical areas that might require deeper exploration with users.

Want to get some fast feedback on your intranet but both time and resources are very limited? Try the user research version of the elevator pitch – the elevator interview.

A number of my previous Research That Works columns on UXmatters have focused on semi-structured user research techniques. My interest in these techniques stems from my desire to get the most out of my time with research participants and to leverage foundational work from other disciplines to gain unique insights for user experience design. With this in mind, a colleague of mine recommended that I try the laddering method of interviewing, which is a technique that is particularly helpful in eliciting goals and underlying values, and therefore, possibly helpful during early stages of user experience research, as I learned after a brief review of the literature on this topic. This column introduces the laddering technique and describes my first experience trying it for myself.

Its motivating simply because you get to meet your users face to face. When I think of a change in design or when problems are reported I don’t think of my users as a faceless mass. I think of the real people I’ ve met – people who are just trying to do a good days work, people who may face real problems and pain if the intranet is not up to scratch.

A great piece, definitely worth reading in its entirety…

After interviews you’ll find that you’ve lots of interesting thoughts and ideas bouncing around your head, but probably in no clear structure. The results will be much easier to understand and convey to others if they are ordered into a clear narration. The best way to do this to do this is to put everything down on paper and then sift through the results to create a final unified story.

A great example of this bias in surveys was when British Airways was designing its new ‘Raid the Larder’ concept in Club World. The team involved did the right thing and got together some focus groups of regular customers and asked them to name the type of food they would like to have available to snack on during a flight. The respondents were pretty clear – mineral water, apples, maybe a light salad. In due course the larder was stocked with these kinds of things. However, when real customers used the larder they tended to leave the fruit and salad and head straight for the chocolate and cakes.

Importance to the business: Just how important is the project/application in meeting organisational/business goals?

Importance to users: What will happen to users if you mess up. Will they be harmed, or will they just go elsewhere?

$$: How much is the project going to cost? (i.e. how much will be wasted if you mess up)

One of the places we kept noticing this was when we watching people shop online. Asking a shopper to pretend to purchase (“Could you find a pair of shoes you might like to buy and put it in your cart?”) produced extremely different behaviors than when we recruited people who needed the product and gave them the cash to make a real purchase. In the former case, they went through motions and skipped steps that we didn’t see when they were considering and purchasing the product for their own true use.