Knowing your users

Traditional product planning typically starts with understanding your current or potential markets. Markets consist of people who will ultimately purchase your product (or, if your product is free, the people who will use your product). Markets are populations that are often defined in terms of demographics data that can be tied to purchasing power, although if your product is internal (such as an intranet application), or if you work for a non-profit or government organization, the way you define your market may be different. Understanding your market is just as important for products that happen to be Flex applications as they are for any other products.

For applications, however, understanding your market is not sufficient. You must also clearly define and get inside the heads of your target users. Understanding users is often confused with understanding markets. Although the two are related they are not the same thing. Market data tends to be broad and quantitatively measurable (so that it can be correlated with revenue expectations). Examples of target markets might be "25 to 40 year old suburban mothers" or "the members of the R&D department" or "voting residents of the state of California." Clearly identifying this information is critical for pricing decisions, market messaging, and to guide effective user definition. However, marketing data by itself does not contain sufficient information for designing Flex applications.

To obtain this information, you must take a closer look at the people behind the statistics. Use your marketing data as a starting point to identify the people who will use your product. Next, focus on qualitative data about their behavior: what they do, how they think, what they want to accomplish. Popular methods of acquiring this data include interviewing potential users about their needs and desires, visiting their work sites or homes to observe them doing tasks relevant to your product, asking them to keep diaries as they go through their day, and so on. Should you decide to engage in such activities, it is worthwhile to employ a user researcher to plan and conduct your research and to ensure that you are getting answers to the right questions that will help you make a better design. (Beyer and Holtzblatt’s book, Contextual Design, outlines a thorough process for conducting design research. Kuniavski’s book, Observing the User Experience, is an excellent, practitioner-focused reference on a variety of research techniques. You can find references to these books in Appendix B: For further reading.)

Whether you decide to do extensive research, light research, or no research at all, you must have answers to a few important questions.

Figure 1. The aspects of application planning build on one another. Defining markets leads to identifying users, users articulate their goals in using your application, and their goals motivate the content they work with and the tasks they perform. All of this information helps you design a successful Flex application.

First, you must understand your users’ goals—their reasons for using your product. For example, if you are designing a financial application, do your users want to browse through the most up-to-date market information and have access to powerful and complex graphical analysis tools to help them decide how to invest their money? Or do they want to spend as little time as possible to get their finances in order? Both of these may be perfectly reasonable goals depending on who your target users are, but designing for one versus the other will result in a very different product. Trying to satisfy both types of people with the same user experience would only result in a frustrating experience for both types of user, a recipe for disaster when it comes to application design.

Second, you should understand the tools and artifacts your users employ in their work or play. If you are designing a portable music player, listen to your users’ music collections. For a photo browser, examine their pictures. For a business administration support system, pore over your users’ forms and records and databases. As you do so, ensure that you understand not just the artifact itself, but what users do with the artifact (if they do anything with it at all).

Figure 2. Get copies of key artifacts your users create or use regularly. It’s often a good idea to annotate these artifacts to explain what users do with them. The example above describes how someone uses a corporate reimbursement form.

Finally, you should understand how your users are engaging in the activities your product intends to support today. For productivity software, we often call these "workflows" or "tasks." These are the words I will use, but you may wish to choose another word if your product is designed for other domains such as entertainment or education. Very few (if any) products introduce entirely new workflows; users are always accomplishing their goals somehow today. Even if you expect them to change their workflows to more efficient and delightful ones once they get their hands on your product, understanding how and why they do things today helps you ensure that the new ways will actually improve their lives.

Figure 3. Tasks and workflows are often best represented using diagrams such as the ones above. It’s useful to annotate diagrams with current problems and opportunities that your Flex application should address.

The true test of understanding is the ability to communicate. Once you feel confident you understand your users’ goals, artifacts, and workflows, communicate them to the other members of your design and development team. Document this understanding so that you can easily refer back to it later in the design process. (Note: Personas are a popular, but by no means the only, way of communicating and recording user goals, workflows, and artifacts.) This will help remind you what your real users want when the difficult trade-offs of the design reveal themselves.

Depending on your design challenge, you may also wish to answer questions about the environment in which your users work, the culture of their organization, or other details. But ensuring that you deeply understand these key aspects of how your users behave—what their goals are, what artifacts they use, and what activities they engage in—is critical to designing a great Flex application. The next two sections will explain why.

Page 2 of 4

Previous Page

Next Page