Chapter 6 Design Thinking

Chapter 6 Design processes Activity-centered vs. human centered design Double diamond Human-centered design Activity-centered vs. human centered design The industrial design context Budget Time Variety of participants Conflicting requirements Accessibility, universal/inclusive design Avoiding stigma Complexity vs. confusion Standards Deliberately making things difficult

Incremental Problem Specification “you cannot understand the problem without having a concept of the solution in mind” Horst Rittel Asymmetry of knowledge Description of Problem Space (customer) solution Description of Solution Space (sales rep)

What is involved in the process of design Observation Identifying needs and establishing requirements for the user experience Idea Generation Developing alternative designs to meet these Prototyping Building interactive prototypes that can be communicated and assessed Testing Evaluating what is being built throughout the process and the user experience it offers

Core characteristics of human-centered design Ideally Stakeholders, including users, should be involved through the development of the project Iteration is needed through the core activities Each iteration gets design closer to final design

Why go to this length? Help designers: understand how to design interactive products that fit with what people want, need and may desire appreciate that one size does not fit all e.g., teenagers are very different to grown-ups identify any incorrect assumptions they may have about particular user groups e.g., not all old people want or need big fonts be aware of both people’s sensitivities and their capabilities

Usability goals Effective to use Efficient to use Safe to use Have good utility Easy to learn Easy to remember how to use

User experience goals • satisfying • aesthetically pleasing • enjoyable • supportive of creativity • engaging • supportive of creativity • pleasurable • rewarding • exciting • fun • entertaining • provocative • helpful • surprising • motivating • enhancing sociability • emotionally fulfilling • challenging • boring • annoying • frustrating • cutesey

Design principles Generalizable abstractions for thinking about different aspects of design The do’s and don’ts of interaction design What to provide and what not to provide at the interface Derived from a mix of theory-based knowledge, experience and common-sense

Usability principles Similar to design principles, except more prescriptive Used mainly as the basis for evaluating systems Provide a framework for heuristic evaluation

Usability principles (Nielsen 2001) Visibility of system status Match between system and the real world User control and freedom Consistency and standards Help users recognize, diagnose and recover from errors Error prevention Recognition rather than recall Flexibility and efficiency of use Aesthetic and minimalist design Help and documentation

What is involved in design? It is a process: a goal-directed problem solving activity informed by intended use, target domain, materials, cost, and feasibility a creative activity a decision-making activity to balance trade-offs It is a representation: a plan for development a set of alternatives and successive elaborations

Importance of involving users Expectation management Realistic expectations No surprises, no disappointments Timely training Communication, but no hype Ownership Make the users active stakeholders More likely to forgive or accept problems Can make a big difference to acceptance and success of product

Degrees of user involvement Member of the design team Full time: constant input, but lose touch with users Part time: patchy input, and very stressful Short term: inconsistent across project life Long term: consistent, but lose touch with users Newsletters and other dissemination devices Reach wider selection of users Need communication both ways Combination of these approaches

What is a user-centered approach? User-centered approach is based on: Early focus on users and tasks: directly studying cognitive, behavioral, anthropomorphic & attitudinal characteristics Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analysed Iterative design: when problems are found in user testing, fix them and carry out more tests

Some practical issues Who are the users? What are ‘needs’? Where do alternatives come from? How do you choose among alternatives?

Who are the users/stakeholders? Not as obvious as you think: those who interact directly with the product those who manage direct users those who receive output from the product those who make the purchasing decision those who use competitor’s products Three categories of user (Eason, 1987): primary: frequent hands-on secondary: occasional or via someone else tertiary: affected by its introduction, or will influence its purchase

Who are the stakeholders? Check-out operators • Suppliers • Local shop owners Customers Managers and owners

What are the users’ capabilities? Humans vary in many dimensions: size of hands may affect the size and positioning of input buttons motor abilities may affect the suitability of certain input and output devices height if designing a physical kiosk strength - a child’s toy requires little strength to operate, but greater strength to change batteries disabilities (e.g. sight, hearing, dexterity)

What are ‘needs’? Users rarely know what is possible Users can’t tell you what they ‘need’ to help them achieve their goals Instead, look at existing tasks: their context what information do they require? who collaborates to achieve the task? why is the task achieved the way it is? Envisioned tasks: can be rooted in existing behaviour can be described as future scenarios

Where do alternatives come from? Humans stick to what they know works But considering alternatives is important to ‘break out of the box’ Designers are trained to consider alternatives, engineers often are not (focus on problem solving) How do you generate alternatives? ‘Flair and creativity’: research and synthesis Seek inspiration: look at similar products or look at very different products

IDEO TechBox Library, database, website - all-in-one Contains physical gizmos for inspiration From: www.ideo.com/

The TechBox

Working in multidisciplinary teams Many people from different backgrounds involved Different perspectives and ways of seeing and talking about things Benefits more ideas and designs generated Disadvantages difficult to communicate and progress forward the designs being create

How do you choose among alternatives? Evaluation with users or with peers, e.g. prototypes Technical feasibility: some not possible Quality thresholds: Usability goals lead to usability criteria set early on and check regularly safety: how safe? utility: which functions are superfluous? effectiveness: appropriate support? task coverage, information available efficiency: performance measurements

Testing prototypes to choose among alternatives

Design Processes: Lifecycle models Show how activities are related to each other Lifecycle models are: management tools simplified versions of reality Many lifecycle models exist, for example: from software engineering: waterfall, spiral, JAD/RAD, Microsoft, agile from HCI: Star, usability engineering

A simple interaction design model Exemplifies a user-centered design approach

Traditional ‘waterfall’ lifecycle

Spiral model (Barry Boehm) Important features: Risk analysis Prototyping Iterative framework so ideas can be checked and evaluated Explicitly encourages considering alternatives Good for large and complex projects but not simple ones

Spiral Lifecycle model

The Star lifecycle model Suggested by Hartson and Hix (1989) Important features: Evaluation at the center of activities No particular ordering of activities; development may start in any one Derived from empirical studies of interface designers

The Star Model (Hartson and Hix, 1989) UCD is a very general philosphy that instantiates itself in the context of a design project. Within HCI there have been many attempts to come up with actual life cycles where users are central. Examples include Rubinstein and Hersch successive iteration of 5 stages, info collecion, design, implementation, evaluation and deploment. The one here is taken fromHartson and Hix model came about by analysing how design takes place in practice evaluation is central: results of each ativity are evaluated before going onto next one both bottom-up and top -down required in waves software designers are familiar with this in their work and call it ‘yo-yoing’ it is important to do both structure and detail at the same time in practice this is what is done - but the end result suggests otherwise corporate requirments dictate a top=down approach which is wha gets recorded ch 5 of Developing User Interfaces (An Overview of Systems Analysis and Design) p- nice step-by-step methodology for doing user-centred design

Usability engineering lifecycle model Reported by Deborah Mayhew Important features: Holistic view of usability engineering Provides links to software engineering approaches, e.g. OOSE Stages of identifying requirements, designing, evaluating, prototyping Can be scaled down for small projects Uses a style guide to capture a set of usability goals

ISO 13407

Design Process Summary Four basic activities in the design process Identify needs and establish requirements Design potential solutions ((re)-design) Choose between alternatives (evaluate) Build the artefact User-centered design rests on three principles Early focus on users and tasks Empirical measurement using quantifiable & measurable usability criteria Iterative design Lifecycle models show how these are related

Prototyping and construction What is a prototype? Why prototype? Different kinds of prototyping low fidelity high fidelity Compromises in prototyping vertical horizontal Construction

What is a prototype? In other design fields a prototype is a small-scale model: a miniature car a miniature building or town

What is a prototype? In interface design it can be (among other things): a series of screen sketches a storyboard, i.e. a cartoon-like series of scenes a Powerpoint slide show a video simulating the use of a system a lump of wood (e.g. PalmPilot) a cardboard mock-up a piece of software with limited functionality written in the target language or in another language

Why prototype? Evaluation and feedback are central to interaction design Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing Team members can communicate effectively You can test out ideas for yourself It encourages reflection: very important aspect of design Prototypes answer questions, and support designers in choosing between alternatives

What to prototype? Technical issues Work flow, task design Screen layouts and information display Difficult, controversial, critical areas

Low-fidelity Prototyping Uses a medium which is unlike the final medium, e.g. paper, cardboard Is quick, cheap and easily changed Examples: sketches of screens, task sequences, etc ‘Post-it’ notes storyboards ‘Wizard-of-Oz’

Storyboards Often used with scenarios, bringing more detail, and a chance to role play It is a series of sketches showing how a user might progress through a task using the device Used early in design

Sketching Sketching is important to low-fidelity prototyping Don’t be inhibited about drawing ability. Practice simple symbols

Card-based prototypes Index cards (3 X 5 inches) Each card represents one screen or part of screen Often used in website development

‘Wizard-of-Oz’ prototyping The user thinks they are interacting with a computer, but a developer is responding to output rather than the system. Usually done early in design to understand users’ expectations User >Blurb blurb >Do this >Why?

High-fidelity prototyping Uses materials that you would expect to be in the final product. Prototype looks more like the final system than a low-fidelity version. For a high-fidelity software prototype common environments include common interface scripting languages. Danger that users think they have a full system…….see compromises

Compromises in prototyping All prototypes involve compromises For software-based prototyping maybe there is a slow response? sketchy icons? limited functionality? Two common types of compromise ‘horizontal’: provide a wide range of functions, but with little detail ‘vertical’: provide a lot of detail for only a few functions Compromises in prototypes mustn’t be ignored. Product needs engineering

Construction Taking the prototypes (or learning from them) and creating a whole Quality must be attended to: usability (of course), reliability, robustness, maintainability, integrity, portability, efficiency, etc Product must be engineered Evolutionary prototyping ‘Throw-away’ prototyping

Conceptual design: from requirements to design Transform user requirements/needs into a conceptual model “a description of the proposed system in terms of a set of integrated ideas and concepts about what it should do, behave and look like, that will be understandable by the users in the manner intended” Don’t move to a solution too quickly. Iterate, iterate, iterate Consider alternatives: prototyping helps

Is there a suitable metaphor? Interface metaphors combine familiar knowledge with new knowledge in a way that will help the user understand the product. Three steps: understand functionality, identify potential problem areas, generate metaphors Evaluate metaphors: How much structure does it provide? How much is relevant to the problem? Is it easy to represent? Will the audience understand it? How extensible is it?

Considering interaction types Which interaction type? How the user invokes actions Instructing, conversing, manipulating or exploring Do different interface types provide insight? WIMP, shareable, augmented reality, etc

Expanding the conceptual model What functions will the product perform? What will the product do and what will the human do (task allocation)? How are the functions related to each other? Sequential or parallel? Categorisations, e.g. all actions related to telephone memory storage What information needs to be available? What data is required to perform the task? How is this data to be transformed by the system?

Using scenarios in conceptual design Express proposed or imagined situations Used throughout design in various ways scripts for user evaluation of prototypes concrete examples of tasks as a means of co-operation across professional boundaries Plus and minus scenarios to explore extreme cases

Generate storyboard from scenario

Generate card-based prototype from use case

Tool support - DENIM

Prototyping Summary Different kinds of prototyping are used for different purposes and at different stages Prototypes answer questions, so prototype appropriately Construction: the final product must be engineered appropriately Conceptual design (the first step of design) Consider interaction types and interface types to prompt creativity Storyboards can be generated from scenarios Card-based prototypes can be generated from use cases

Design Rationale Used to support the design process by Encouraging exploration of different potential designs Motivating the conceptual evaluation of potential design features Recording this activity as partial documentation of design Horst Rittel meant IBIS (issue-based information system) approach to slow down designers to make them more reflective on their design

IBIS Issue – a design question Issues are not independent Position – a potential answer to the question Argument – reasons for/against the potential answer Issues are not independent Can create a graph of relationships among issues Part/whole relations among issues Prerequisite/informing relations among issues

Chapter 6 Design processes Activity-centered vs. human centered design Double diamond Human-centered design Activity-centered vs. human centered design The industrial design context Budget Time Variety of participants Conflicting requirements Accessibility, universal/inclusive design Avoiding stigma Complexity vs. confusion Standards Deliberately making things difficult