October 15, 2007

User data sources

We get feedback from users when we’re able to do usability tests, which is not often enough. What other sources are good for user data?

Companies often fail to take advantage of internal sources of user data. In defining requirements for the next release, do you talk to Tech Support or Customer Service to identify the most frequent or critical usability issues they’ve heard about from users? Those teams also are on the front line for hearing about new features that users want.

Technical Writers and Documentation Specialists also can be gold mines of information. If those folks are not already on your team, find them and ask their thoughts. Chances are, the things they have a hard time documenting are good issues to be explored.

Marketing and Product Management might have valuable data for you from surveys, focus groups, interviews, etc.

If your organization has a Training group, ask them what’s working and what the users want changed. Observe the training sessions yourself, too, and listen to people’s questions.

How about Sales Reps and Consultants who go out in the field? Try sending a User Experience Specialist on customer visits with them, to emphasize how important the customers are to your company, and to solicit feedback and requirements in a way that’s probably different from how the Sales Reps and Consultants do it.

However you do it, don’t rely on any single source to provide you with user data. Get feedback from multiple channels, compare and contrast the data across channels, and look for patterns and ”a-ha” nuggets in the data.

Filed under: Usability, Process_and_Strategy | Permalink

August 20, 2007

Remote Usability Testing

What are the pros and cons of remote usability testing?

Remote usability testing is an excellent method for getting feedback when study participants, facilitators and/or observers are in different physical locations. Using web conferencing software such as WebEx, GoToMeeting or UserVue, remote testing enables screen sharing among everyone involved in the study. When the study participant has control of the screen (in presenter mode), everyone can see in real time what that user is doing. A simultaneous telephone conference call enables people to hear what the user says as he or she works through tasks.

This method offers convenience and can save a great deal of time and money, as you can run sessions with users anywhere in the world without incurring travel costs. It’s also useful for enabling distributed development teams to observe sessions (we’re big fans of multi-disciplinary team members observing sessions live, whenever possible).

A few downsides to remote testing should be considered. Unlike testing in person, remote testing does not let you see the expressions on a user’s face, unless the user has a webcam.  Facial expressions, gestures and other body language can be important sources of data. In addition, remote tests require slightly more preparation than in-person tests. For example, you need to ask potential participants about firewalls, operating systems and other system requirements to make sure they’ll be able to access the web conferencing software. Also, the web conferencing software adds another layer of technical complexity to the session, which may frustrate or confuse less-savvy Web users.

For the most part, though, the cons of remote testing are minor when you consider the benefits.

Filed under: Usability, Process_and_Strategy | Permalink

May 14, 2007

Customer requirements and end-user requirements

My company thinks about customer requirements but does not think about end-users. What’s your advice?

For a software company, “customer” and “end-user” often are different. A customer is the one who buys the software, and an end-user is the one who’s stuck using it. Customers and end-users can have very different goals and requirements for the software. Customer requirements are usually driven by Product Management, while a User Experience group may own the end-user data. It’s critical for all of the people who collect requirements to communicate frequently and for both kinds of data to feed into planning for new releases.

End-user input and feedback are especially important in understanding why specific features are needed and how they should work.

Case in point: A software company we know created a new product feature based on a single large customer’s request. After the expensive new feature had been developed and released, the company learned that their customer’s request came from a desire to fix a workaround issue that could have been solved with just a few field-level changes on a single screen. Had end-user data been considered, the company would have saved a lot of money.

In a perfect world, Product Management and User Experience constantly communicate what they’re hearing from customers and end-users so that requirements can be validated or refuted just from talking to each other. (Other good data sources include Support, Customer Service, Sales and Training.)

In cases where there is a dispute over what Development time should be spent on, a smart person at a high level in the organization should determine the requirements based on the company’s overarching business goals.

Filed under: Process_and_Strategy, Usability | Permalink

April 10, 2007

Incorporating User-Centered Design into an Agile Development Process

My company just switched to an Agile Development Process. How can I incorporate user-centered design and research activities into Agile Development?

Agile Software Development is a process that minimizes risk by limiting the amount of time and effort associated with each software release. There’s a lot we like about Agile, as opposed to traditional waterfall development (which involves finishing a discrete, concrete step before starting the next step) or the old “pass it over the wall” method. However, an Agile process must be implemented carefully in order to avoid introducing usability problems and other issues into the user experience. For advice on how to do this, please see our paper on Incorporating User-Centered Design into an Agile Development Process, the content of which is longer than we care to post in this blog.

Filed under: Process_and_Strategy | Permalink

January 17, 2007

Measuring a behavior change program

How do you do research for an online wellness program that spans the course of several weeks and measures changes to behavior over time?

In this instance, where the feedback you are looking for has much to do with the efficacy of a program over time, get feedback from people who have completed and who have failed to complete the behavior change program.

Conduct a survey to ask questions that help determine participants’ success. Were they able to change their behaviors? For how long have they maintained change? Compared to other programs they may have used, how useful was this program in helping them to change behaviors?

Then you can walk them through parts of the program in chronological order and ask them to think aloud as they review the steps, thinking back on their experiences.

Another approach is to ask participants to keep a diary to record their thoughts as they use the program. You can then review the data with them at the end. We’ve had varying levels of success with this, as the diary adds a burden to their regular schedules. However, if you come up with a good incentive for them to make diary entries, they can provide very rich information.

Filed under: Usability, Process_and_Strategy | Permalink