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

August 20, 2006

Personas and user feedback

We already know a lot about our users, and we’ve created detailed personas. Do we need to do usability testing, too?

It’s very valuable to know as much as possible about your users when designing a user experience. Among the things you should know about are the environment in which the users work, the systems and tools they use, the most frequent and important tasks they do, their workflow, and their mental models of their tasks.

But even if you spend significant time understanding your users up front, you still won’t know for sure how they will react to an actual system you are designing. Even the most talented professionals sometimes make mistakes in requirements gathering and/or guess wrong when designing a user interface that’s supposed to be easy to learn, efficient and appealing for other people. Whether to do usability testing is really a question of how confident you want to be in your design before a development team puts time, energy and money into implementing it.

We have found that the most effective process includes not only understanding your end-users up front, but also iterating on early designs and prototypes based on direct user feedback from usability testing.

Filed under: Usability, Process_and_Strategy | Permalink

March 05, 2006

Introducing user-centered design

I am the only Information Architect + Designer in an IT Solutions company. I am also fresh out of college. How can I introduce some processes to work with the programmers / coders who are working on Enterprise Solutions?

This is a question we could speak about endlessly! The good news is you’ve completed the first step. The company hired you to do IA and design work, so they are interested in what you have to say and what you can teach them about processes.

When introducing user-centered design processes, first think about the culture in which you work and consider your internal audience. For example, in an Enterprise Solutions company, how much freedom do developers have to create screens “their own way” versus using standards and guidelines? Developing effective standards and guidelines for screens, components and workflows is one good way to show your value and position yourself as an expert resource. Standards and guidelines are also beneficial because you are the only IA, and it’s likely you will not be able to personally design, or redesign, every screen of a solution by yourself.

In some organizations, conducting informal “brown bag lunches” or similar activities is a good way to determine who your advocates are and what barriers exist within the organization. Give a brief overview of a topic in IA or user-centered design that you know well. Then, leave plenty of time for questions and discussion so you can learn about your internal audience, their needs and their perceptions of you and what you can do for them.

Be careful not to stretch yourself too thin. Come up with a small set of goals for yourself and focus based on where you can add the most value. Also, consider where other people (new hires, consultants, trainers, etc.) might be able to help meet your and your organization’s goals.

For more information, check out Expero’s Resources page for links to books, organizations and articles of interest.

Filed under: Process_and_Strategy, Usability | Permalink