As Allen continued to interact with the new system, his frustration with it grew. Phil, the software developer sitting next to him, could see that Allen wasn't very happy with his work. So, he asked, "What's wrong? What are you looking for?" Allen said, "I want to enter the latitude and longitude of this store, and I don't see where I can do that." Phil said, "Well you can enter it into that location field." "Yes, but I can also enter 'Corner of Central and Elm'." "Yes, that's true; the user can enter whatever they want". Allen exclaimed, "That is the problem! How will I be able to feed this into a mapping program if I don't have the precise coordinates?"

This scene is all-too-familiar with software developers. Phil, with good intentions, thought he knew what Allen wanted, but never really talked with him enough to discover what Allen really wanted to do with the system. For customer-centered design to be possible at all, the software development process needs to include techniques for learning about customers and how they work. This means that software developers must discover the everyday work practice of their users.

Unfortunately, it is easier to look at how other applications implement a certain feature than to talk with users. An easy target of the unfortunate ramifications derived from this practice would be Microsoft. Microsoft produces many of the products that sit on a developer’s desk. And even though people such as IT managers and developers like and buy their products, Microsoft’s products are often disliked by their users. On the flip side, one need look no further than Apple. Despite Apple’s history of committing one business blunder after another, it was able to emerge as a competitive leader because of its profoundly loyal customer base. Apple’s customer base remains so loyal because its software is so easy to use. Designers at Apple speak and interact with users enough to know them and how they use a software product.

So, what are the primary steps in getting to know your users? When you sit to talk with them, what should you talk about? How do you get your user to provide solid information that can be incorporated into a software system? There are two tools that can guide your discussions with users and provide a useful form of documentation for future reference. These include identifying the user's roles and goals, and creating a persona to describe a typical user of each role. The methods for gathering enough information to identify and create user roles and goals are interviews, direct observation, and work-flow analysis.

Roles and Goals

A significant contribution to the overall usability of a system can come from discovering the roles a user may assume when interacting with a system. Developers often consider this aspect of product development when they think about security, but seem to forget that the different roles may want or need to interact with the system in a completely different way.

Once the user roles have been defined and described, goals for each role should be identified. Goals are the reason a person uses the system at all. Software should make a task easier to perform. Knowing what the task is and creatively coming up with ways to solve that problem is what developing a software system is all about. Good interaction design has meaning only in the context of a person actually using it for some purpose. You cannot have purposes without people - the two are inseparable. What’s more, the most important goals are personal ones, held only by the individual. Some real person is interacting with your product - not some abstract corporation - so you must regard people’s personal goals as higher than the corporation’s. Your users will do their best to achieve the business goals, but only after their own personal ones are achieved. The most important personal goal is to maintain peace of mind - flow. The essence of good interaction design is to devise interactions that let users enter a state of optimal performance and maintain it for an extended period of time. In this way they increase their productivity, and are happier as they do so.

Now that we understand what we are trying to develop, there are a few methods used to gather the information that we can use to develop roles and goals: interviews, and direct observation.

Interviews

Developers have rarely ever been taught how to interview someone. Communication or Journalism majors probably, but software developers, definitely not. So, the thought of sitting down with someone to talk about the use of a system may seem a bit daunting. It doesn't have to be though. People tend to like to give their opinion on various topics, and especially on a software system that will affect their day to day tasks. So, really all you need is a bit of preparation.

To prepare for these interviews, it is very helpful to create a list of potential user types based on what you know about the system. In general, you will want to interview two or three people in each role you identified as important to the focus. Determine what you want to learn from these users and develop a set of interview questions to help you collect this information. Plan for the interview to last only 20 to 30 minutes - some people may be willing to allot up to 60 minutes, but be sure they are engaged and you are not wasting their time. As you talk with people, listen for the steps the user follows, places of hesitation, and intentions of the user. Be prepared to take notes or capture the interview on video. Some good high-level interview questions to start with may be:

• What is the work the user does?
• How does this work fit into the customer’s whole work life?
• What are the key work tasks?
• Who is involved in making the work happen?
• Who are the informal helpers?
• Who provides the information needed to do the job, and who uses the results?
• What makes a good or bad experience with such systems?
• What are the critical success factors on which you are evaluated?
• How are these related to your use of the system?
• Ask the user to share a few stories that are typical of her actual use of the system.

Detailed interview questions may include:

• What are your typical problems, challenges, pain points and pleasure points?
• Can you describe the people/roles involved with those problems?
• What steps have you taken thus far to solve the problem?
• Are there any constraints in your current solution? (i.e. time, budget, etc.)
• What information do you need to make decisions?
• What activities or conditions waste your time?

Summarize the interview paying special attention to functions including:

• Searching and browsing of information
• Saving named sets of information for later use
• Viewing information to be used in some way.
• Scheduling items using different delivery options.
• Viewing news and documents by subject matter of interest to the user.
• Creating a profile of preferences that makes the software application easier and faster to use.
• Viewing recommended and related items
• Viewing content details such as prices, history, special conditions, parts or special items.
• Viewing comparisons of selected items, attribute by attribute
• Allowing easier methods for user to navigate very large sets of items.

Direct Observation

It has been my experience that direct observation is the best way to gather information about how someone performs a task, and how a system may help them. While one-on-one interviews provide an untainted view of a person's opinions, they may be inaccurate because of the user’s attitudes or a desire to report that their behavior aligns with company policy. Rather than asking users what they want, it is more effective to focus on what users do, what frustrates them, and what promotes peace of mind. For maximum efficiency, combine user interviews with direct observation, allowing you to collect a significant amount of data in a short period of time.

When choosing individuals to observe, identify the individuals who do the work. Sometimes you may end up talking with a manager, who is more likely to tell you how they want things to happen rather than what actually does happen. For direct observation to be effective, you need to see the work getting done which should reveal the details of the tasks at hand and identify the most important aspects of those tasks. Observation also helps you learn more about the job than you ever will by talking with people. Observations to make special note of include: the responsibilities of the individual, people who have common goals, the communication flow between people, informal structures (i.e. ways that people work outside of formal process and around policy), and paper or virtual artifacts which are considered 'real' (like objects in an object oriented design). The actions people take to perform their work reveal how they approach their job and what matters to them. A system that builds on these aspects can improve the work they do. Understanding the real intent is key to improving the way people accomplish a task; observation will enable you to redesign, modify, and remove steps in a process while still enabling the user to achieve their underlying intent.

While I know it is not comfortable or familiar for a developer to get out and interact with users, I really encourage you to get out to talk with and observe users of your system before you start to build it. Your users will appreciate it, and you will too when you don’t have to rework portions of the system that don’t meet your users’ needs.