Design / Redesign

Those of us working directly with users – the “user experience researchers,” know that user data is not just subject to interpretation, it is interpretation. Data does not actually “speak for itself.” Even the strictest low-level performance data represents a choice to collect that type of data, and focusing on its collection sacrifices the possibilities of other data or inquiries. When product design decisions are made based on user research, risks emerge with teasing out and selecting appropriate interpretations. In interpretation, I find it useful to speak in terms of a specific “user segment,” the most specific role represented by the research participants. In reports and discussions, I usually present the data by identifying participants as they would refer to themselves – graduate students, designers, financial analysts. This is common practice in market research, where surveys and focus groups are planned by segment. But in usability and user research studies, the simplification of “user” still pervades much of our thinking and reporting.

User analysis models have evolved from simple user profiles and detailed task analyses popular in the 80’s to the personas and scenarios used in current user definition and front-end analysis. While these approaches help construct agreement on specified characteristics of selected user types, they also turn into the de facto “user.” While personas are meant to be used as a way of grounding user types in the details of a specific possible person, they are easily converted into working definitions of “the user.” Project managers and developers still think in terms of requirements and specifications, and may ask about the users, but cannot be expected to respect your “personas.” It’s an HCI thing, and not being part of their professional culture, can seem deliberately mystifying. In traditional firms, organizational stakeholders remain focused on a traditional notion of the user.

There are no generic users, and should be few truly generic or homogenous interfaces. Even the most widely-used website or corporate presence has an intended “reader” with probable goals for visiting the site.

Although the proponents of personas emphasize the utility of designing to a single-user profile distinguished by the selected personas, I’m not sure this always serves the actual anticipated users. It facilitates design practice, settling arguments by constraining design choices across increasing alternative feature decisions that arise from multiple user configurations. But field research (in the service of usability) leads to the realization that people belong to communities of practice, sharing similar goals, outlooks, and values.

Analysis of the social basis of activity leads to a different unit of analysis than the individual user (and their tasks). By analyzing activity we discover how the user constituency may be organized by similar professional commitments, traditional means, shared experiences and practices over time. Scenarios also fail to capture this level of social organization and collaboration. So what do we call the user community connected by shared activity and professional identity?

When looking at the activity and community of those intending to adopt our products, the term user really falls short. But rather than just land a critique on the muddy ineffectiveness of the term user, and our more cryptic use of language in design and usability, I propose some alternatives. And I encourage discourse appropriate to our supposed interest in this issue.

I’ve found it valuable to distinguish representatives of the “community of use” by referring to their generic job titles. In cases where you might see the word user, you will read “accountants,” “financial analyst,” or “researcher.” But then most of my work involves design for information services used by specific professionals. For corporate presence websites, we might use “customer” and “visitor,” at least, distinguishing two different constituencies of interest. You often see the label “investors” linked on public firm sites – this leads to the possible “shareholder” or even “stakeholder” as a user definition label for this situation. For information and telecom services, you have “subscribers.” For public services, you have “citizens,” “voters,” and “community members.” You get the idea.

In some industries, customer (advocated by Holtzblatt and Beyer) often suffices as a catch-all term. But it is often incorrect when designing user interfaces, if the buying customer and product-interacting person are different. For many business contexts, constituent makes sense, although it still doesn’t implicitly refer to the act of using. The problem with any term other than user seems to be our insistence in understanding only the context of use. Since this context is a very limited experience from the “user’s” point of view, we leave a lot of context on the table, which we fail to understand because we scope the issues so narrowly in favor of the user construct. I believe this “user language” stems from the experimental epistemology our profession has emphasized, which requires isolation of variables and subject characteristics. An interpretive stance affords deeper understanding of motivations and constraints for actual use in the person’s work practice. This knowledge allows us to design the right product in the first place!

Of course we will probably continue to use this term of art, or term of convenience, for some time. My purpose was to share with a community of readers my reflections on this way of thinking about the issue – and to suggest to others how an unexamined use of abstractions such as “user” inadvertently guides our methods and interpretations. A critical re-thinking of our language constructs in research helps clarify biases and issues hidden in the way we practice. It should also promote a more engaged and interactive discourse among all stakeholders in the design process, leading to the deeper understanding of our communities of use and our own design practice.