(Floe) User states and contexts

Introduction

"User states & contexts" (interim name) is a user modelling tool for conceptualizing, designing, and evaluating the ability of a design to be consumed and operated by users in a wide range of states and contexts. That is, given a design or design idea, will users, in the most inclusive sense, be able to use it?

This tool is motivated by the need to keep up with the considerations of basic use (consumption and operation) for all the many states and contexts users can be in. State and context are defined as follows:

State: personal factors that may affect the individual's ability to use a product or system.

Context: physically external context that may affect an individual's ability to use a product or system.

Each dimension we consider is a faculty of the user (i.e., state) or their environment (i.e., context) that may affect the use of a given product or system. In particular, we are interested in the effect of a user's state and context and not its cause. For instance, an effect of a state and context is that Sally may not be able to see well; we are interested in this. The cause may be that she has inherently low vision (i.e., a state) or that it is too bright outside (i.e., a context); we are not interested in this.

Dimensions of considerations include factors that may be personal or environmental. Dimensions of relevance depend on the product or system of interest.

Examples of dimensions include: vision, hearing, speech, dexterity, cognition, language ability, social context, internet access availability.

Because a user's state and context shifts throughout the day, week, and life of a user, what may be true at one moment may not be true in another. For instance, a user's needs for a given product in the morning at the office may be different in the afternoon in the car. This tool attempts to capture the space of these varying states and contexts in order to make the considerations for designing all needs more transparent.

This tool should be used in conjunction with personas or other user modelling techniques. See section "Why not personas?".

About name, "user states and contexts"

"User states and contexts" refers to the cause, whereas each of the elements of consideration is an effect. The tool's name is being temporarily used mainly as a nod to the underlying understanding of abilities/disabilities. It is not, however, what populates the elements of the framework. As such, it is a misnomer that should be corrected once we think of something more appropriate.

Introduction (older draft)

What are "user states and contexts"?

User states and contexts are an articulated understanding of the users which are used to: 1) ensure designers, developers and evaluators are thinking on the same page wrt users and their needs, and 2) designers and developers have a reference artifact to work against while generating and evaluating design ideas (i.e., mindfulness of user needs).

We are attempting to enumerate various user states and contexts which may have a direct effect on the use and access to a given OER, whether it be physical or cognitive (e.g., vision-related), contextual/environmental (e.g., noisy environment), or otherwise.

A user "state" refers to a personal factors (e.g., sensory, motor, cognitive), while a user "context" refers to his or her environmental considerations (e.g., regional context, technological availability, etc.).

These "states and contexts" are factors that relate directly to a user experience (e.g., online video lecture, interactive simulations, etc.). In particular, these factors can be classified under the following buckets (three of which are borrowed from WCAG's own principles):

Perceivability (e.g. sensory)
Operability (e.g. dexterity)
Understandability (e.g. cognitive, communication, cultural)
Availability (e.g. internet access)
Portability (e.g. device platform)
and a catch-all, Other

Why not personas?

Initially, we considered the construction of personas to distill, articulate, and externalize our understanding of users. Upon further consideration, we realized this was both impractical and undesirable for the FLOE project for at least two reasons: 1) The breadth of target OER users is extremely wide, and appropriately capturing relevant groups within the population is impractical, and, perhaps more importantly, 2) A key goal of FLOE is to be inclusive of the diversity of humans and their varying needs and preferences. Personas, which deliberately groups common needs and preferences into archetypal users, is not well-suited to capturing the diversity and variance in user needs and preferences at a granular level.

Advantages (vs. personas)

* Bypasses the problem of insufficient granularity in personas, as an actual user would be represented by a combination of these states and contexts.

* Avoids typecasting or classification of users into deterministic character + goal-based buckets (which downplays the diversity and multiplicity of user needs and preferences).

* Provides us with a reference point for bringing stakeholders to a similar understanding about user needs.

* Provides us with a reference point during design conceptualization and prototyping for being mindful of user contexts and evaluating ideas against (i.e., a sounding board for ideas)

Disadvantages (vs. personas)

* Lacks details around the personality, history, emotions, immediate goals, medium/long-term aspirations, etc. of the user

* Less "compact" than personas (personas are often created in handfuls, whereas the combination of enumerated states/contexts could number extremely high; there is a practical/logistical benefit to categorizing users).

* Doesn't "humanize" the users (e.g., doesn't tell a story about archetypal users, provide emotional or sociological context, etc.).

* Doesn't assist in prioritizing common user needs (no character biography to compare against).

* Focuses primarily on functional requirements.