Bite-Sized UX Research

By Steve Baty

Published: May 7, 2008

It’s not uncommon for projects to lack the time, money, or resources to conduct ideal user research activities. There are many reasons why this occurs:

  • Sometimes we’re brought onto a project late.
  • Perhaps we’re new to an organization that doesn’t really get UX.
  • Maybe a company is rushing to bring a product to market for some reason—and there are plenty of good and bad reasons this might be so—and there simply isn’t time to “go big”.
  • Perhaps your client or organization is following an Agile development methodology.
“As UX professionals, we can always add value, at any stage in a project.”

At such times, it can be tempting to just throw up our hands in dismay and do nothing or lament the fact that everything isn’t perfect. But the simple fact is that, as UX professionals, we can always add value, at any stage in a project—even if a project team can’t act on our advice straight away.

Focus on Winning Small Victories Often

Regardless of the cause for your company’s resource crunch, focus on getting small wins as often as possible throughout your involvement in a project. This is a fairly common piece of advice that crops up time and time again, but it’s very much worth repeating. And it applies just as readily to both situations where time is short and those when there’s just not enough of you to go around.

This advice is equally valid for UX professionals who find themselves in new positions as the sole user experience person. It’s common for new hires to ask: “How do I sell the benefits of UX?” The answer is generally something along the lines of: “Focus on small wins.” In other words, don’t waste your energy putting together a series of case studies on how other people have created value at other organizations. Instead, do something positive and tangible—however small—and it’ll carry a lot more weight.

Go for Impact

Concentrate on getting bang for your buck. Depending on your circumstances, you may not get many opportunities to demonstrate the value of UX, and when time is short, there can be a tendency to just do something—anything. It’s an urge you should try to resist. If you want to have a greater impact, ask your project team—the project manager, the development team, and the business stakeholders—a few pointed questions before you get started:

  • What are the critical features of the Web site or application?
  • What features would be hardest for the developers to change once they’ve developed them?
  • What are the areas of greatest ambiguity in terms of user requirements, audience groups, or competitive offerings?

And then ask a few more questions:

  • How can I best document my user research findings, so the project team can use them?
  • Do we have time for iterations? And if so, how many?

With this information, you can start planning some activities that focus on the most important elements of the project—the critical features for success; the features that are hardest to change; or the gray areas of the project—and deliver some real value.

It’s all very well to say “do something small,” but what, exactly, can you do?

Early Days

You can demonstrate the value of UX during the early stages of a project—such as scoping, initial designs, general requirements, and so on—when there’s the potential for more leeway in the feature set of an online service and more ambiguity around users’ needs. Some activities that can demonstrate value early in the process—and may even alleviate some of your resource constraints further down the track—include the following:

  • user interviews or contextual enquiries—Get out of the office and meet some of your prospective users. This is a really low-cost way of rapidly building up an understanding of your users’ needs and their context of use. You’ll also learn in what ways users differ from each other and may uncover some surprises. The best part is that—aside from the cost of your time—it’s largely a free activity. 
  • competitor reviews—Help map out the current state of the domain, allowing your team to set better targets. Look at the existing offerings of your competitors to identify the things they do really well and the things they’re failing to do well. Competitor reviews also provide you with a baseline set of features that represent the barrier to entry and can also help to identify opportunities the obvious gaps represent.
  • internal stakeholder interviews—If you don’t have direct access to your audience, go and talk to the business stakeholders and ask them about the decision-making process by which they selected and prioritized features. This can help you uncover assumptions that you can test as a project progresses. It can also provide insights into the mental models in operation for the project.
  • mud map personas—There’s a good chance you won’t have the time or resources to conduct the in-depth user research you’d need to turn out well-defined audience personas. However, low-fidelity personas that capture all of the information you do know about your audience segments can be valuable as time progresses. While you can flesh out these mud maps as you learn more about your audience, they also serve to demonstrate how little your team currently knows first-hand about your target users.

What About Card Sorts?

Conducting a card-sorting exercise early in a project is desirable when the concept space is not well understood. Early on, you’d typically perform an open card sort, which may require more time and resources—for recruitment, implementation, and analysis—than you have.

Although it is possible to design, recruit, conduct, and analyze a card sort in a matter of days, the question remains whether you might spend that time on another task, offering higher impact to the project. However, there are times when nailing the information architecture is the most critical element for the success of a project, and a card sort would be the best use of your time.

What to Deliver?

“The critical features of your project will drive your choice of what elements to detail.”

Although your time may be short, don’t abdicate responsibility for an information architecture to others. Do wireframes, even if you show only some elements in detail. The critical features of your project will drive your choice of what elements to detail. You might spend your time designing the elements that are most important to the success of a project, leave less important elements to the development team, and iterate the design of those less important elements later on, when you have more time. Alternatively, design and test complex elements that it would be costly to redesign and reimplement at later stages in a project.

As Time Goes By

As a project moves out of its early stages and into the implementation cycle, you can start shifting your attention from requirements to refinement. At this stage of a project, useful activities include

  • user walkthroughs
  • closed card sorts
  • usability testing
  • definition of metrics

User Walkthroughs

You can do small-scale user walkthroughs of wireframes, a paper prototype, or a stack of screen shots for very little cost. The aim is to generate feedback from real users—or, at least, realistic users—on the design of features at a relatively early stage in a project—that is, before too much development work has taken place.

This activity doesn’t necessarily have to be a big deal. Take a stack of paper printouts to a local cafe and ask people if they’ll walk through a task or two with you, in exchange for a coffee or snack. Don’t take up too much of any one person’s time. It’s better to get several different people to try out a feature or two rather than possibly annoying people by demanding too much of them. They’re trying to relax after all!

Iterate this process if you can.

Closed Card Sorts

“Focus on task failures and look for common mistakes participants make.”

A closed card sort is a little easier to conduct than an open card sort— and, in my opinion, a lot easier to analyze. Using decks of cards representing a site’s structure as you’ve designed it, ask people to find their way to particular low-level pages. You can plan your card sort based on the major user tasks, critical features, or areas of known ambiguity.

You can easily conduct a closed cart sort just about anywhere, and it should take only a few minutes per task. For each task you test, note the path each user takes—that is, the card a user selects at each step—and whether a user successfully located the low-level page.

You can carry out a test like this in a single day, including its setup. Since time is short, focus on task failures and look for common mistakes participants make. Report only such issues, but make the full test results available to your project team. You don’t want to be the bearer of only bad news. Instead say: “A lot of stuff worked well, but here are some things we need to look at changing.”

Usability Testing

Using whatever version of a Web site or application you have available—whether wireframe printouts or a low-fidelity prototype—conduct a more formal usability test, during which you ask each participant to complete all tasks. Although this can be time consuming, a usability test with six participants takes just a few days and can provide valuable insights for your project team.

You can take this opportunity to test your whole design solution. Alternatively, you can concentrate on high-impact features, according to your time, people, and budget constraints.

As a finished Web site or application becomes more tangible, continue doing iterative, small-scale usability testing. There will come a time when you can’t incorporate the findings from your testing into the upcoming release, but your recommendations can form the basis for a subsequent version.

Define Metrics

If you’ve joined a project very late, there may be very little you can do to influence the finished product. However, you can still add value to the project by defining a set of analytics that can help the project team make design decisions during the product lifecycle. So, get the team to record page-completion times for a multi-step transaction process, make sure you get good search logs and reports, and give yourself an opportunity to learn something about how customers are interacting with your site.

Don’t be disheartened if your project team can’t incorporate your changes straight away. Start laying the groundwork for the next iteration of the product or service and stay ahead of the curve if you can.

Summary

“Undertake small, tactical, iterative user research activities throughout the course of the project.”

If you don’t have the resources of a large UX team, with the budgets and timelines to undertake the ideal user-centered design (UCD) or activity-centered design process, you can still make a valuable contribution to a project. Undertake small, tactical, iterative user research activities throughout the course of the project. Focus your efforts on the areas of greatest impact, and produce documentation that your project team can understand and use efficiently.

If you demonstrate value through a series of small, high-impact UX activities, the extra budget, people, and timeline flexibility you need will eventually come your way. Then, you can come closer to implementing your ideal UX process.

I’d like to thank Ruth Ellison, of Stamford Interactive, Daniel Szuc, of Apogee, and Russ Unger, of User Glue, for motivating me to write this column and for their input into the ideas it presents.

8 Comments

Great article, Steve! It’s very consonant with the UX guerrilla strategies that UX Recife network discussed during its last gathering, in April. This short PowerPoint presentation is in Portuguese, though the strategies are in English: guerrilhaux.ppt

As part of this article: Evangelizing Usability to 700 People: Strategies for Building a User-Centered Organizational Culture

Interesting.

Great article, Steve. While reading your article, I thought that one of the biggest problems for UX professionals may be getting the crew behind you when you come up with a beautiful idea. A great way to do this may be A/B —or in some cases, multivariant—testing. By setting up a small test, it can be easy to gather evidence to push your idea to the front. When you don’t have the possibility to A/B test on your own, you can use Google’s free Website Optimizer.

During the past months, I’ve been testing some design patterns and tried to implement them into our projects, I find it an easy way to win goodwill inside our organization.

For user walkthroughs, I have often used employees at my company, particularly those who do not interact with the product on a daily basis. I would have a hard time going to a cafe and asking strangers for their help(!), but I have no problem approaching administrative assistants, order expediters, and others, to spend a few minutes doing a walkthrough.

Additionally, many employees not involved in the creation process of products often like the chance to do something that helps craft the final outcome—their managers tend to understand this.

I just joined a team in the last couple of iterations of the final product as UX Manager. Definitely struggled to add UX value while not completely redefining the team’s goals.

It’s hard to walk into an agile environment and, at the last minute, modify ~40% of the IA and ~60% of the UI. I had to do a lot of compromising.

May be overkill, but these are important under pressure guidelines:

  • Provide actual screen shots to your team of ambiguous and/or critical modifications or additions.
  • Document changes, especially if you are working with a team of developers who are sharing tasks.
  • Commit to your changes and be able to provide, in clear documentation, what you submitted.
  • Provide standards—that is, form layout standards, color standards, on so on.
  • Force consistency.
  • Most Importantly, communicate and be sure every developer knows the overall scheme or goal you have developed. Hand out a standards document.

Thank you all for the comments and feedback.

Henk: A/B testing is a good technique, although I left it out for the sole reason that it can require involvement from people outside the UX team. But if it’s available to you, then it’s worthwhile carrying such tests out.

Filipe: I’ll have a look through that PowerPoint when my head’s a bit clearer—Portuguese is beyond me right now.

Gary: Getting others within the organization engaged in the design process is well worth the time and effort, and they can provide you with good input as well.

Jason: Those are good points—and good advice for people working in agile development environments. I think those first and last points are applicable to all design teams, not just agile.

Steve

Hi Steve,

Hello from sunny Cairo. I really like this article so much, and I would like to ask you for an article about how to educate your company to use UX techniques and apply some usability tests.

Same for the clients. Sometimes, we all face a client who thinks he knows everything, and he thinks that what he needs is the correct thing. so as a UX designer, how can you convince him? Or would you just step back from the project?

Thanks a lot.

Mohammed

Great article. Thanks for sharing.

There are some great examples for working in an agile development environment here. In addition to those, I’d be very interested in what you—and others—would suggest when working in a team where Business Analysts (BA) are responsible for the requirements gathering phase—which is prior to the design phase—of the project. I’m finding it difficult to make inroads into the early stages of a project.

Ideas?

Marcus

Join the Discussion

Asterisks (*) indicate required information.