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.
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?
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?
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.
About Mud Maps
A mud map is a drawing scratched into the dirt. You can use mud maps when there are no other materials at hand and draw them with a stick or boot. Mud maps are low fidelity, but contain the main characteristics of the terrain.
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?
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
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
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.”
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.
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.
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.
Topic: Columns | User Research