User Centred Design

Intro

• In a broad sense, an interactive technology is any technology intended to help people complete a task, achieve their goals.
• Look and feel come second, what people need to do comes first.
• “Design is not about how things look. Design is about how things work.” – Steve Jobs

Usability

• Key thought is making interactive systems usable i.e. giving them usability meaning:
  • Effective
  • Efficient
  • Learnable
  • Memorable
  • Satisfying
  • Positive User Experience
    • Enjoyable
    • Fun
    • Entertaining
    • Aesthetically pleasing
    • Supportive of creativity
  • The system/its interface should be "transparent" to the user – the user should be concentrating on their task, not how to get the system to do the task.

Personas

• “The user” dehumanizes your users, making them abstract, and slippery to get a hold of in terms of knowing what their goals are and how they will act.
• Understanding that gives a first step to being able to conceptualize what the system should do.
• Are realistic representations of skills and attitudes towards technology.
• At their best when based on data and observation.
• A robust cast of characters that can be drawn on during design meetings and activities.

Persona Briefings

• The persona briefing captures different aspects of the user and collects them under broad categories.
  • e.g. A day in the life • Work actvties • Household & leisure activities • Goals, fears & aspirations • Computer skills, knowledge & abilities • Market size & influence • Demographic attributes • Technology attributes • Technology attiudes • Communicating • Quotes

Scenarios

• Scenario Based Design: Elaborate the design by writing scenarios (=stories) about the current domain and existing interactions.
• Problem scenarios - Describes current practice.
• Activity scenarios - Describes ideas of how to meet the users needs.
• Claims Analysis: Examine features of existing practice looking for good and bad aspects.

Conceptual Design

• There is a pervasive myth of the ‘dumb user’ in computing – that users are essentially incompetent knuckleheads who intentionally screw up the system.
• In reality, almost always, it is dumb design – the system has been constructed in such a way that it not only doesn’t take the human into account.
• The reason we can play any sport is because we have a clear view of the concepts (e.g. bat, ball, pitch), the relationships between those concepts (e.g. ball is bowled down the pitch to the bat), and the rules of how they work together (e.g. you can have two batters, one at each end).
• Concepts – tell us what types of things the person will need to know.
• Using out scenarios we can identify things that users need to know about
• If the list of concepts is really long, or seems at odds with our personas, then we might need to rework our concept load on the user.
• Some concepts we can borrow from other applications and use them (the ones that the user is familiar with) : because they match the mental model about how the world works for the user.
• Mental Models – are the understanding that people have about concepts and rela9onships in the real world that they use to make decisions or react to events.
• What happens when a system violates the mental model of the user?
  • The person will not know what to do next (unable to form the next goal)
  • The person will make an error (provoked or unprovoked).
• In order to have a good system that is easy to learn and remember, it would be good if we had:
  • A clear set of concepts that can be applied to an application
  • A clear set of relationships that describe how those concepts relate to one another – A mapping from the concepts and relationships we want to use to a mental model of the users who will be using our system
• How ? Metaphors.
• The notion of a metaphor in interaction design is the translation of the physical to the digital – where you borrow concepts and rules so that users can apply their knowledge of the physical world.
• The most famous example is the Desktop Metaphor
• Metaphors are very useful, but there are problems:
  • What happens when people try to do something that is forbidden ?
  • Not all metaphors transfer into the digital setting.

Task Analysis and Modelling

• We need to understand the user needs and their goals to analyse their interaction with complex systems.
• A task is the set of activities (physical and/or cognitive) in which a user engages to achieve a goal.
• Task analysis refers to techniques for investigating and representing the way people perform activities: what people do, why they do it, what they know, etc.
• An approach to Task Analysis is task decomposition which is a method of splitting tasks into ordered subtasks.
  • ‘Stopping rules’ can be specified to determine the level at which it is appropriate to cease decomposing the task.
• Task modelling: – representing results of task analyses as task models
  • a specific task model describes one instance of a task as performed by one person
  • a generic task model generalises across many instances to represent the variations in the task

Hierarchical Task Analysis

• HTA represents tasks as a hierarchical decomposition of subtasks and operations, with associated plans to describe sequencing.
  • Tasks and Subtasks: activites to achieve particular goals/subgoals
  • Operations: the lowest level of decomposition; level determined by a ‘stopping rule’
  • Plans: specify the sequencing of activities associated with a task and the conditions under which the activities are carried out
• Written either as structured, indented text or using a structured chart notation

Task Analysis Process

• Identify user groups, select reps.
• Collect data to elicit information about:
  • Goals
  • Activities
  • Reasons underlying the activities.
  • Info resources they use.
• Create specific task models initially.
• Generalize across specific models to create a generic task model : from each task model for the same goal produce a generic model that includes all ways of achieving the goal.
• Check models with users, stakeholders and iterate.
• For the decomposed tasks, activities, write plans.
• Plans will specify the order of tasks e.g. fixed sequence, optional tasks, wait for tasks etc, parallelism. Described in natural language.
• Model why people do things as well as how.