1. Chapter 6
Design Thinking

2. 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

3. 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)

4. 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

5. 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

6. 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

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

8. 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

9. 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

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

11. 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

12. 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

13. 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

14. 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

15. 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

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

17. 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

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

19. 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)

20. 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

21. 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

22. IDEO TechBox Library, database, website - all-in-one
Contains physical gizmos for inspiration
From:

23. The TechBox

24. 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

25. 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

26. Testing prototypes to choose among alternatives

27. 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

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

29. Traditional ‘waterfall’ lifecycle

30. 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

31. Spiral Lifecycle model

32. 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

33. 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

34. 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

35. ISO 13407

36. 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

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

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

39. 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

40. 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

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

42. 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’

43. 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

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

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

46. ‘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?

47. 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

48. 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

49. 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

50. 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

51. 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?

52. 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

53. 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?

54. 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

55. Generate storyboard from scenario

56. Generate card-based prototype from use case

57. Tool support - DENIM

58. 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

59. 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

60. 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

63. 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