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.
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?
“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.
Topic: Columns | User Research
2011年12月31日 星期六
Bite-Sized UX Research
2011年12月30日 星期五
10 Heuristics for User Interface Design
Ten Usability Heuristics
by Jakob NielsenThese are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.
- Visibility of system status
- The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
- Match between system and the real world
- The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
- User control and freedom
- Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
- Consistency and standards
- Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
- Error prevention
- Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
- Recognition rather than recall
- Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
- Flexibility and efficiency of use
- Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
- Aesthetic and minimalist design
- Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
- Help users recognize, diagnose, and recover from errors
- Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
- Help and documentation
- Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
2011年12月26日 星期一
2011年12月25日 星期日
Check out this website I found at 2011年12月21日 星期三
2011年12月19日 星期一
2011年12月12日 星期一
Why you Should Bury your Sign Up Button
Why you Should Bury your Sign Up Button
A short while ago I was involved in a project redesigning a home page of a website. I dutifully designed the page in the common fashion, using a bold headline, some bullet points, and a juicy call-to-action button. It was very similar to many of the startup home pages that you might run across every day.
The goal of the redesign was to increase conversion on the primary call to action of sign-up. We wanted to double or triple (or more) the number of people who were signing up and trying out the product.
I knew the redesign was a vast improvement over the existing one, merely because the page better communicated what was going on. Instead of a vague headline that wasn’t communicating value to readers I used a much more descriptive one that helped orient people immediately to have some idea of what the site does. And the button…well let’s just say that it was so hot it made you want to click it.
So we launched, and then we looked at the data. Uh Oh. No big increase in conversion, certainly not enough to change the business. The conversion rate had improved about 20%, which is OK, but the rate itself was so low to have very little effect on the company’s bottom line.
What was wrong? Why wasn’t there a big improvement in conversion? Why was our click-through so low on what was obviously the primary call-to-action? Didn’t we follow all of the visual design rules here? Make headline big and bold. Check. Make a bullet list of important points. Check. Make a beautiful, sexy button that looks like it was born to be clicked. Check.
Why then, were people not clicking the sexy button?
It’s at this point when you have to step back and ask yourself: what exactly is design? Is design creating something for creation sake? We certainly had done that, and we had already done as much work as is done on most redesign projects. Most projects would have launched and been done…when redesign is the goal the launch is the end.
But that’s not what passes as good design these days. Good design is design that works. So to honestly assess the redesign I did I had to admit…this design was still not working.
Damn was that hard to admit. Really, really hard to admit. I hated admitting it because it was an admission that I failed. I’ve not often admitted that on projects in the past that just didn’t get the usage that I wanted. In so many cases it was easier to say to myself that what I did was better than what was there before and the work of launching was enough. It is so easy to confuse getting stuff done with doing good work.
Yet, this admission also allowed me to see the problem more clearly. Once I accepted that the redesign still wasn’t working, I created the opportunity to find out why not. See that interesting little trick I pulled there? Failure is an opportunity to problem solve! We all love to problem solve, right?
So in hindsight the answer is obvious…people weren’t clicking “Sign Up” because they were not ready to. They saw the button and did not care enough to click it. I could have made it flashing big-ass and red, but still nobody would have clicked on it.
No visual design wizardry at this point would have improved things. No matter how much we tweak the call-to-action, we’re not going to significantly improve click-through on it. We’re not fighting an attention war here…we have people’s attention because they’re on our website. No, we’re fighting an emotional war. We need to convince people of the value of what we’re offering enough so they actually care. They are aware that our big-ass honking button is there…how could they not be? We made it impossible to miss! in fact they’ve read the text on it that says “Sign-up for Free”. They can barely get it out of their peripheral vision…
No, our visitors can see clearly…they’re not failing to notice the button. And they can read…they can see what the button says. They’re also not obstinate…they’re not doing this just to spite you.
The hard fact is that they just don’t care.
Or more precisely, they don’t care yet. They’re interested, but they do not know enough to care. We have not given them enough of a reason to care. They are not ready to take that step.
So the right answer in this situation is not to give our call-to-action a stronger drop shadow, double its text size, make it fire engine red (#CE1620), or make it blink. No amount of visual design on that button will make people click it more. The right answer is to remove the button altogether and replace it with something that people do want to click. Something they do want to do…the appropriate next step in their lifecycle as a customer.
I call this Designing for the Next Step. And in my next post I will explain what I’m talking about in much more detail…
Addendum: The folks at Zurb have published an example of a 350% improvement from simply burying the sign-up button. That’s some serious improvement.
Why you Should Bury your Sign Up Button « Bokardo
Why you Should Bury your Sign Up Button
A short while ago I was involved in a project redesigning a home page of a website. I dutifully designed the page in the common fashion, using a bold headline, some bullet points, and a juicy call-to-action button. It was very similar to many of the startup home pages that you might run across every day.
The goal of the redesign was to increase conversion on the primary call to action of sign-up. We wanted to double or triple (or more) the number of people who were signing up and trying out the product.
I knew the redesign was a vast improvement over the existing one, merely because the page better communicated what was going on. Instead of a vague headline that wasn’t communicating value to readers I used a much more descriptive one that helped orient people immediately to have some idea of what the site does. And the button…well let’s just say that it was so hot it made you want to click it.
So we launched, and then we looked at the data. Uh Oh. No big increase in conversion, certainly not enough to change the business. The conversion rate had improved about 20%, which is OK, but the rate itself was so low to have very little effect on the company’s bottom line.
What was wrong? Why wasn’t there a big improvement in conversion? Why was our click-through so low on what was obviously the primary call-to-action? Didn’t we follow all of the visual design rules here? Make headline big and bold. Check. Make a bullet list of important points. Check. Make a beautiful, sexy button that looks like it was born to be clicked. Check.
Why then, were people not clicking the sexy button?
It’s at this point when you have to step back and ask yourself: what exactly is design? Is design creating something for creation sake? We certainly had done that, and we had already done as much work as is done on most redesign projects. Most projects would have launched and been done…when redesign is the goal the launch is the end.
But that’s not what passes as good design these days. Good design is design that works. So to honestly assess the redesign I did I had to admit…this design was still not working.
Damn was that hard to admit. Really, really hard to admit. I hated admitting it because it was an admission that I failed. I’ve not often admitted that on projects in the past that just didn’t get the usage that I wanted. In so many cases it was easier to say to myself that what I did was better than what was there before and the work of launching was enough. It is so easy to confuse getting stuff done with doing good work.
Yet, this admission also allowed me to see the problem more clearly. Once I accepted that the redesign still wasn’t working, I created the opportunity to find out why not. See that interesting little trick I pulled there? Failure is an opportunity to problem solve! We all love to problem solve, right?
So in hindsight the answer is obvious…people weren’t clicking “Sign Up” because they were not ready to. They saw the button and did not care enough to click it. I could have made it flashing big-ass and red, but still nobody would have clicked on it.
No visual design wizardry at this point would have improved things. No matter how much we tweak the call-to-action, we’re not going to significantly improve click-through on it. We’re not fighting an attention war here…we have people’s attention because they’re on our website. No, we’re fighting an emotional war. We need to convince people of the value of what we’re offering enough so they actually care. They are aware that our big-ass honking button is there…how could they not be? We made it impossible to miss! in fact they’ve read the text on it that says “Sign-up for Free”. They can barely get it out of their peripheral vision…
No, our visitors can see clearly…they’re not failing to notice the button. And they can read…they can see what the button says. They’re also not obstinate…they’re not doing this just to spite you.
The hard fact is that they just don’t care.
Or more precisely, they don’t care yet. They’re interested, but they do not know enough to care. We have not given them enough of a reason to care. They are not ready to take that step.
So the right answer in this situation is not to give our call-to-action a stronger drop shadow, double its text size, make it fire engine red (#CE1620), or make it blink. No amount of visual design on that button will make people click it more. The right answer is to remove the button altogether and replace it with something that people do want to click. Something they do want to do…the appropriate next step in their lifecycle as a customer.
I call this Designing for the Next Step. And in my next post I will explain what I’m talking about in much more detail…
Addendum: The folks at Zurb have published an example of a 350% improvement from simply burying the sign-up button. That’s some serious improvement.
