User Centred Design

From Suhrid.net Wiki
Jump to: navigation, search

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
    • A conceptual model is a designers intended mental model for the users of a system - a set of ideas of how it is organized and operates.
  • 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.

Information Architecture

  • An information architecture is a way of expressing the model by which information is structured on a website or other interactive system.
  • This is different than information design where you are trying to decide what information should be expressed and how it should be visualized.
  • So largely this is about rules about concepts and relationships -­‐ it is a policy by which people understand how your site is structured.
  • So the site or interactive system architecture must match the mental model of the user which will make it easier to use.
  • Card sorting is a technique to find out about the mental models of the users.
  • For e.g. for a recipe website it is useful to know how users will group ingredients together.

Interaction Styles

  • Lots of methods of communicating with systems, they can be classified into five interaction styles.

Conversational/Dialogue

  • e.g. Command line dialogue
  • Command has to be absolutely right, little natural feedback.

Menu

  • Set of options, cant deviate from them.
  • Should be able to use a menu without any prior knowledge as the menu leads the user through the interaction.
  • Excellent for novice and infrequent users.
  • Expert users get annoyed, lack of flexibility.
  • Only works if there is a logical grouping of items.

Form Fill

  • Solves problem when there are too many categories for a menu.
  • Based on metaphor of filling paper form.
  • If well designed, any user can use them.
  • Can confuse user.

Direct Interaction

  • Simply select the object and interact with it.
  • WIMP - Windows, Icons, Menus, Pointers.
  • Nature of widgets provide cues.
  • Dont always real world metaphors, direct manipulation becomes tedious for repetitive tasks.
  • Also directly interact without reference frame such as mouse.
  • Gestures: many devices use common gestures to decrease memory load for the user.

Natural Language Interaction

  • Speech recognition.
  • Very flexible, ultimate in conversational metaphor.
  • Weakness - get into loops if recognition fails.
  • Accent problem.

Interaction Design

  • Draw on HTA's, scenarios, goals/plans, interaction styles, devices and...
  • Principles.
  • Numerous researches have come up with a set of principles to guide interaction design:
    • Shneiderman's 8 golden rules.
    • Nielsen's 10 usability heuristics.

Support User Goals

  • Make goal satisfaction conditions visible and easy to infer.

Memory Load

  • Use recognition rather than recall.
  • One of the key reasons to move to direct manipulation is not having to rely on recall memory.

Visibility of System Status

  • Make what has to be done completely obvious.

Feedback

  • Providing info to the user on the current state of the system, what has been achieved.
  • Helps the user keep track of where they are in the interaction.
  • Feedback has to be immediate rather than delayed.

Consistency

  • Design interfaces should have similar operations and use similar elements for similar tasks.
  • Main benefits are consistent interfaces are easier to learn and use, can predict operations, less likely to make errors.

Closure

  • The sense of having completed something.
  • e.g. getting money in the atm.

Readability

  • Fonts
  • Colour/Background
  • Group things that are used together.
  • Alignment, Multiple columns etc.

Match between system and real world

  • Speak users language, follow real world conventions, making info appear in a natural and logical order.
  • No computing language or HCI language.
  • e.g. use shopping basket.
  • Make information appear in a natural and logical order. for e.g. for Arabic countries, natural reading order is right to left.

Prototypes

  • Need a bridge between talking to users in the abstract and building a full blown system.
  • Prototyping is that bridge.
  • Very useful while discussing ideas with stakeholders.
  • Encourages reflection on design, explore alternative designs without committing to one idea.
  • Dimensions:
    • Fidelity: Rough and ready or fully working applications.
    • Evolutionary Fitness: Something we carry forward in each stage, abandoned as soon as evaluation is done.

Low Fi Prototype

  • A low fidelity prototype is a rough and ready prototype: easy to make, clear to stakeholders that they can be criticized, designers dont have too much stake in them.
  • Storyboarding: Each panel demonstrates a beat in time. A beat can be changes of context within an application, users inputting something, system responding with feedback or errors.
  • Interaction Sketching: creation of thumbnails, layouts rapidly. Produce many designs to explore design space. Lots of tools, templates available.
  • Wizard of Oz: Human simulates the system.

High Fi Prototypes

  • Uses material we expect to find in the end product, looks like the final thing.
  • "Real" look and feel, serves as a living specification. Disadvantages: worth the expense if it might be changed later ? Developers can be reluctant to change it.

Evaluation

  • Heuristic Evaluation: Experts go through a system looking for problems guided by heuristics.
  • Experts do it individually and then come together go through all problems they found and agree on a final set of problems and a rating of severity for each problem.
  • Also can be collaborative.
  • User evaluations: done by real users. See how system performs on usability criteria.
  • Representative set of users perform representative tasks, work naturally and provide ratings at the end of the session.
  • Identifying problems: through think aloud protocol or retrospective verbal protocol.

Interaction Design Patterns

  • Examine the interaction between a user and the system.
  • Describe challenges a user faces when performing a particular task.
  • Provides a language for designers and users to communicate with.
  • Describe dynamic, changing systems.
  • Vary in level of abstraction.. eg. high level - return to safe state, to application specific such as Web tabbed navigation.
  • e.g. Breadcrumb trail, Drag and Drop,
  • Closed loop in public display systems.
  • Wizard - lead the user through interface step by step.
  • Pattern languages also exist.