Understanding Your Users - A Practical Guide to User Requirements Methods, Tools, and Techniques

Understanding Your Users - A Practical Guide to User Requirements Methods, Tools, and Techniques

by: Kathy Baxter, Catherine Courage

Elsevier Reference Monographs, 2005

ISBN: 9780080520087 , 810 Pages

Format: PDF, ePUB, Read online

Windows PC,Mac OSX suitable for all DRM-capable eReaders Apple iPad, Android Tablet PC's Palm OS, PocketPC 2002 und älter, PocketPC 2003 und neuer, Windows Mobile Smartphone, Handys (mit Symbian) Read Online: Windows PC,Mac OSX,Linux

Price: 77,29 EUR

More eBook Details

Understanding Your Users - A Practical Guide to User Requirements Methods, Tools, and Techniques


 

CHAPTER 2

BEFORE YOU CHOOSE AN ACTIVITY: LEARNING ABOUT YOUR PRODUCT AND USERS


 

Introduction


When working with a product team, your first objectives are to learn about the product and the users. It is key for you to ascertain as much as possible about the existing product in terms of its functionality, competitors, customers, etc. In addition, you need to assess what is currently understood about the users and begin to create user profiles. This information will enable you to choose appropriate user requirements activities so that you can ultimately improve your product. In this chapter we will detail how to collect product information from a variety of sources and how to make sense of the information readily available to you. We will also discuss how to create user profiles, personas, and scenarios, and how to use these as design tools. Finally, we present two excellent case studies. The first illustrates how to conduct a competitive analysis and the second details the successful use of personas.

At a Glance

> Learn about your product

> Learn about your users

> Pulling it all together

Learn About Your Product


Before you even begin working with a single user, you need to understand the domain you are working in. We cannot stress enough how important it is to do your homework before jumping into one of the user requirements activities described in this book. You may be extremely pressed for time and think you can learn the domain while you are collecting data from users. Big mistake! You will need to answer many questions for yourself. What are the key planned or available functions of the product? Who are the competitors? Are there any known issues with the product? Who are the product’s perceived users? In addition to helping you collect effective requirements, this knowledge will also earn you necessary respect and trust from the product team (refer to Chapter 1, Introduction to User Requirements, “Become a Virtual Team Member” section, page 19).

Limiting your homework to speaking with the product team is often not enough. We hope that the product team you are working with is composed of experts in the domain and that they have done their homework as well. Unfortunately, this is not always the case. Particularly with new products, the product team is learning about the users and the domain at the same time you are. It is important to interview the product team and learn everything you can from them, but you must also supplement that information with data from other sources. In addition, the more you know about the product and domain, the more respect you get from the product team. You may never know as much as some of the product managers; however, there are always some fundamentals they will expect you to know or to pick up quickly. In the very beginning you can get away with being naive; but with time, stakeholders will expect you to understand what they are talking about.

In this chapter, you will read about a variety of sources that you can use to learn about the product you are dealing with, and your end users. Keep in mind that this section is not intended to tell you what to do instead of collecting user requirements. It is intended to tell you about some of the research you will want to conduct before you even consider running a user requirements activity. In addition, we have included two very enlightening case studies, one related to gaining a better understanding of your product, and the other to gaining a better understanding of your users. The first study is from Diamond Bullet Design and it discusses a competitive analysis that was done to compare online business school libraries. The second study is from Microsoft and it details the process of creating and using personas.

If you do not have a background in usability, you will need to be aware of some of the founding principles. You need to understand what questions can be answered by a usability activity and what questions should be answered by a design professional. We strongly recommend that you refer to Appendix A (page 678) to learn about usability resources available to you as well as Appendix B (page 688) for a list of usability training courses. If you require supplemental assistance, you can refer to Appendix D (page 698) for a list of usability consultants that can work with you.

Data are out there that can help you learn a lot about the product. In this section, we tell you how you can use log files, marketing, customers, and general research to help you become a domain expert. Regardless of whether this is a brand new product or a new release of an existing product, there is still a lot of existing information that can help you.

At a Glance

> Use your product

> Networking

> Customer support comments

> Log files

> Your marketing department

> Early adopter or partner feedback

> Competitors

Use Your Product

It may sound trite, but the best way to learn about your product is to use it (if it already exists). In the case of a travel website, you should search for a hotel and flight, make a reservation, cancel your reservation, ask for help. Stretch the product to its limits.

Networking

You are surrounded by people who know about your product and domain, you just have to get to know them. Start by finding out whether your company has a usability group (that is if you are not a part of such a group). Meet the people who support your product and read their usability reports. If you are unable to watch a live activity, ask to view tapes of previous activities for your product and related products. What previous usability issues were encountered? What user requirements have been documented so far?

You should also meet the content writers for the company. These are the folks who create the user manuals and online help (for websites and web applications). What is difficult to document – either because it is difficult to articulate or because the product is so complicated to explain?

If your company offers training courses, attend classes. Speak with the folks who teach the courses. What is hard to teach? What types of question are users asking? What tips (not documented) are the instructors offering?

Customer Support Comments

If you are working on a product that already has an existing version and your company has a Help Desk or Customer Support Group, you can learn a great deal about your product by visiting that department.

People rarely call or e-mail in compliments to tell a company how wonderful their product is, so those calls pertain to issues that you should become familiar with. If you can access logs of customer questions, problems, and complaints over time, you will see trends of difficulties users are encountering. Perhaps the user’s manual or Help isn’t helpful enough. Perhaps the product has a bug that wasn’t captured during QA. Or perhaps users do not like or cannot figure out a “feature” the product team thought every user had to have. This can give you a sense of where you will need to focus your efforts to improve the product.

Users may not be able to accurately describe the problem they are having or may misdiagnose the cause. Likewise, customer support may not have experience with the product under consideration. Although this should never be the case, it often is. If the support staff are not very familiar with the product in question, they may also misdiagnose the cause of the customer’s problem or may not capture the issue correctly. This means that, once you have a log of customer feedback, you may need to conduct interviews or field studies with users to get a full understanding of the issues.

Log Files

If you are responsible for the usability of a website, web server log files may provide an interesting perspective for you. When a file is retrieved from a website, server software keeps a record of it. The server stores this information in the form of text files.

The information contained in a log file varies but will typically include: the source of a request, the file requested, the date and time of the request, the content type and length of the transferred file, the referring page, the user’s browser and...