Categorizing Your Audience

Essays in this series about understanding your audience:

A critical element of a good commerce site is a design built around a well-understood audience, because the success of a site depends on meeting the needs and requirements of the people who use the site. The audience for a web site isn't just a homogeneous group of identical people; even with a small audience that shares very similar goals for using a web site, the individual end-users will vary across a range of characteristics, understandings, priorities, etc. Understanding a site's audience(s) requires some scheme for categorizing users into "chunks" whose needs and requirements can be identified, managed and accommodated.

Sites are designed by people, for people. For a site to fulfill the purposes behind its creation, the site must attract and please its users. If a site is intended for or targeted to a particular type of user, then the appeal and functionality of the site can be optimized for that type of user. The other side of this view is that if a site is intended for a particular type of user, then an obvious measure of the site's success is the extent to which this type of user's needs and desires are met.

Any categorization scheme must also take into account the point-of-view of the team that creates it. A categorization will provide definitions of end-users and their associated characteristics, goals, etc., but some definitions will have negative impacts on the user experience because the definitions used by developers may not reflect a true user point-of-view.

Below are several common user categorization schemes, organized - with respect to the end-user's point-of-view -- in order of most abstract through most concrete.

Categorizing Users by Function

A scheme for identifying users based on functions of the site is usually based on a designer's or developer's understanding of the web site. As a developer, when I create a commerce site that includes functionality for searching the product database, and functionality for purchasing these products, it's logical and reasonable to expect me to map my experience with the behind-the-scenes view of the site to the expected user: I would expect users to fall into the two categories of visitors who just use the search engine, and shoppers who make purchases (probably after using the search engine to find the products to purchase).

This view will have various repercussions for the web site and its creators, because it establishes a paradigm for categorizing users (visitors versus shoppers), for understanding user interaction with the site (what makes a visitor become a shopper? Is that even possible?), and for assigning value to site metrics (how many users are visitors versus how many are shoppers?). The danger is that the paradigm may be wrong or incomplete, and that failures downstream may be difficult to diagnose.

Some possible errors stemming from this particular paradigm might include:

a misunderstanding of how this site's "shoppers" actually behave: differentiating between people who buy and people who don't buy will fail to capture users who search for products, but don't purchase those products the same day;
a lessened focus on user search behavior: if the important distinction becomes people who buy versus people who search but don't buy, will the success or failure rates of searches be noticed by the web team? If many users are failing in their search attempts -- say they are trying natural language searches on an engine that doesn't handle them -- then the pool of good product results that can be converted to purchases is lower than it could be and you wouldn't realize that this was a problem;
lack of understanding of user client-side capabilities: dividing users by site function doesn't address the ability of users to perform these functions, for example a user who can't access a secure server and so can't purchase online. And for this example, you again wouldn't necessarily realize that this was a problem.

The core problem with this scheme of classifying users based on site functions is that the classifier projects his or her concept of the site -- the developer's point-of-view -- onto the user. This view is necessarily slanted: as a developer, I may be building a search engine but outsourcing the commerce engine to another company, so my project plans, budgets, timetables, etc. for these two functions are very different. As a developer, search and commerce functions have very clear and distinct boundaries, and my projecting these boundaries onto a user's behavior would be a disservice.

Categorizing Users by Role

A scheme for identifying users based on user roles or modes of interaction with the site is, intuitively, more useful for understanding the site's audience. An excellent (and well-articulated) example of a role-based classification of audience is the article "Designing Your Audience" by Jeffrey Zeldman, found at http://www.alistapart.com/stories/who/who1.html. Mr. Zeldman categorizes site visitors into three groups:

USERS are people who employ tools (software) to accomplish tasks: calculating, comparing, finding, outlining, writing, designing.

VIEWERS are people who seek entertainment. They want to be surprised, seduced, led along a path. Their goal is the journey, not the end result.

READERS are that rare (but growing) breed of web user who turn to a website as they might turn to a novel or magazine article.

Mr. Zeldman's classification scheme borrows from literary criticism and views the user's interaction with a web site as an interaction with an man-made artifact or text. From a theoretical point-of-view, this classification makes a lot of sense, especially if the goal is to compare sites or generate a broad, high-level theory about the world wide web.

I do think, however, that this scheme is too broad for the purpose of providing a quality user experience.When I examine the behavior of users at a particular commerce site, or when I'm designing such a site, this broad categorization doesn't help me understand such questions as "who is most likely to buy from the site?" or "can users find what they are looking for?"

Role-based user categorization schemes have several general shortcomings.

A role is a schema consisting of a self-view, a structured world paradigm, and a framework of definitions, concepts and rules governing interaction with other roles, agents and objects. Any definition of a role, or assignment of identity based on role, must be very well researched or it risks being superficial and inconsistent. A role assignment that doesn't reflect actual behavior is not helpful. Identifying a user as having the interaction behavior - and hence the role - of a viewer doesn't address a.) what the person thinks about commerce in general, b.) what the person thinks about the particular merchandise available on the web site, or c.) what it would take to help the person make the decision to buy from the site.
People play many different roles, often at the same time. Categorizing users by role must address the determination of the primary role as well as the relative importance of the other roles being played.
Role definitions may be driven more from developer projections and expectations than from actual user behavior. Roles that aren't based on observations of real users are not helpful and can in fact be detrimental to the site's usability and its ability to meet its business goals.
Role definitions may prioritize mode of interaction over user goals, intentions, or tasks. Users are more likely to be motivated by concrete goals than by abstract philosophies when they surf commerce sites. Positing a type of user that is a "viewer" doesn't directly address a user who intends to buy a birthday present for a favorite nephew.
Role definitions are often based on arbitrary distinctions. When considering the design and creation of a web site, the only place arbitrariness has any place is in the behavior, predicted or observed, of users; arbitrariness on the part of the design or creation team will result in the exclusion some set of users.
Role definitions say nothing about characteristics of users, such as what systems they are likely to be using, what their connection speed might be, what experience they have, etc.

Categorizing Users by Knowledge/Experience Domains

Jakob Nielsen, in his book Usability Engineering, uses the following scheme to categorize users along three axes:

general knowledge of and familiarity with computers: Users can be measured along a scale of familiarity with computers ranging from not at all experienced to very experienced.
expertise in using the web site: Users can be measured along a scale of level of expertise using the web site, ranging from people new to the site to people with great familiarity with the site.
understanding of the task domain: Users can be measured along a scale of their understanding of the kinds of tasks required or available at the site. For example, a typical commerce site is essentially a store, a place to purchase something, so there is a set of tasks commonly associated with commerce that should be accomplishable on the site. A user who is very familiar with both commerce and online commerce should have a better grasp on the relevant tasks than would somebody who is less familiar with commerce.

This scheme is very useful from a general interface design point-of-view, since usability practice shows that certain interface design points can be optimized for identifiable levels of knowledge or experience in one of these domains. For example, Nielsen writes that "a common way to cater to both expert and novice users is to include accelerators in the interface to allow expert users to use faster, but less obvious, interaction techniques."

When used in isolation, this scheme is less useful for a quality assurance effort, because it fails to consider some concrete characteristics of users, such as the goals and motivation behind a user's interaction with the site, or the specific nature of the possible tasks involved in achieving these goals.

[More information on the book Usability Engineering.]

Categorizing Users by Shared Similarities

Any scheme for identifying users should be derived from observation of users, which means looking for groups of users that share similar goals, desires, needs, abilities, and client-side environments. The important thing is to group users based on properties that inhere in them, such as their characteristics, and not in a web designer's expectation of them, such as predicted behavior. Look for their real behavior.

This level of information concretizes user trends and metrics into quantifiable components, and groups users into sets of users. Once a set of users has been identified on the basis of an observable trait or measurable data point -- for example, users who connect to the Internet via a 2800 baud or slower modem -- you have a more consistent identifier than one derived from a functionality scheme or a role scheme.

For example, an online bookstore will have a number of easily identified sets of users, including:

users who have no interest in buying anything -- they just want to poke around or research topics, authors, etc.
users who have a desire to buy a specific book, and come to the site for that explicit purpose
users who want to buy a gift for someone

These sets are identifiable by purpose or intent, but an equally valid way of identifying users is by client-side environment:

users who use Netscape Navigator on Windows 95
users who use Microsoft Explorer on Windows 95
users who use AOL on a Macintosh
users who use Lynx on a Unix workstation

And then there are users identified by connectivity issues, for example:

users who have a cable modem
users who have a 14.4 modem
users who connect from behind a corporate firewall

The effort invested in identifying user sets pays off in better information about real user needs and behaviors, which in turn translates the following advantages for the web site team:

More complete use cases for testing.: With a clearer understanding of how different groups of users interact with the site comes a more accurate set of potential paths through the site's architecture and functionality. Good use cases should reflect real behavior, not predicted paths.
Comprehensive understanding of user client-side environments.: Studying user behavior and characteristics will show the kinds of platforms, operating systems and browsers used by your audience, which in turn will help you decide which environments to include in your design targets and in your test routines.
A more usable site.: With a better understanding of the needs of different sets of users, and how these needs may themselves differ, developers can create alternate ways to meet needs, perhaps creating multiple paths to get from "here" to "there".
Less unconscious exclusion.: Arbitrary decisions result in the exclusion of groups of users; increased focus on users as groups of people sharing similar characteristics or behavior will uncover groups that are unable to interact with site due to restrictive design elements. Users should only be excluded because of well-thought out and understood decisions; an example would be a commerce site that requires the client-side capability to handle SSL protocols in order to ensure privacy and security of financial information. Such a requirement excludes users of older browsers, but this exclusion is based on what is to the company a sound business reason.
A more appropriate marketing strategy.: A better understanding of groups of users allows a company to target promotions to those users' needs and desires.
An understanding of the milestones of the commerce track.: Ignoring a developer's view of the functionality of the site and examining what users do and want to do on the site yields an obvious milestone: the user's decision to buy. Any number of different people and groups of people may interact with a commerce site, but there is only that one decision point that is critical to the site's ability to drive sales. Understanding users gives the site's developers information to use in convincing those people who haven't passed this milestone to make the decision to buy.