Creating systems that work for people

Interaction design involves creating systems that work for people.

• discovering requirements
• defining needs
• ideating possible solutions
• producing prototypes
• evaluating systems

Double Diamond Model

Design Stages

1. Discover: understand the problem and the people affected
2. Define: define the problem clearly so that it can be addressed
3. Develop: create ideas, prototypes, sketches, etc, that might address the problem
4. Deliver: test potential solutions to find promising directions, and iterate

Who is involved in design?

Usually a wide range of people are involved or affected by a design process. We call them stakeholders. Stakeholders includes not just the potential users of a system, but others who are not.

For example:

• users
• customers
• developers
• researchers
• managers / product owners
• government bodies
• non-government organisations (NGOs)

Degrees of Involvement

• Personas: limited/no real users, “fake” user personas to help frame design
• Face-to-face: small groups or individuals in information-gathering or evaluation settings¹
• Crowd-sourced: large surveys, crowd-sourcing, community engagement
• Participatory: users central to planning, ideating, prototyping (co-design, co-creation)

User-centred design principles

From Designing for Usability: Key Principles and What Designers Think (Gould & Lewis, 1985)

• Early focus on users and tasks: who are the users? what are they like? what are the tasks?

• Empirical measurement: users should use simulations and prototypes to carry out work. observe, record, and analyse.

• Iterative design: when problems are found in testing, they must be fixed. design, test, measure, repeat.

People-centred design

Expanding from “users” to “people” with more details (Rogers et al., 2023)

• tasks and goals drive development
• behaviour and context of use are studied
• people’s characteristics included
• stakeholders are consulted throughout development
• design decisions consider context of use, people’s activities, and their environment

Activity: People vs Users

Interaction Design Lifecycle

Connecting to HCI

Design and HCI related but not the same:

• Discover and Define stages are highly related to “uncovers the needs of different kinds of computer users” (from week 1)
• Develop and Deliver are more related to “proposes computer systems (incl. software) that can be better used by humans”

Some HCI research is technical or speculative, inventing technologies that are not yet common or popular

Research through Design

Design isn’t only the thing we study, it can be the way the research is done (Frayling, 1993):

In research through design: making the artefact is the enquiry

• Zimmerman et al. argued this counts as a method for HCI
• build something that reframes a messy problem and embodies a preferred future
• then judge it on process, invention, relevance and extensibility (Zimmerman et al., 2007).
• the formality of this process is still argued (Zimmerman et al., 2010).

Gaver’s caution: what RtD produces is provisional, contingent and aspirational; a portfolio of artefacts and annotations, not one tidy truth (W. Gaver, 2012).

What is a Design Rationale?

• A design rationale is the argument behind your design: why this design and not other options (MacLean et al., 1989)
• Contrast with a description of what you made.

A design is one point in a space of possibilities. The rationale is what maps the space (MacLean et al., 1991).

“A Design Rationale is not a record of the design process — it is a co-product of design along with the artifact and itself has to be designed.” (MacLean et al., 1989)

A quick unit test

could a reader disagree with you?

• Not a rationale: “the button is paw-sized, because dogs have paws” (nothing here to argue with)
• A rationale: “I chose paw contact over nose contact because …, accepting that …” (now we can argue)

Sketches as argument

Bill Gaver and John Bowers argued that an annotated portfolio of design work carries knowledge that doesn’t reduce to a list of findings (B. Gaver & Bowers, 2012).

• annotations capture the family resemblances between designs — “a mesh of similarities and differences”
• a set of artefacts with commentary supports an argument that one might be a better choice than another.
• three sketches with commentary is evidence of a design space you actually explored (Buxton, 2007)

Your sketches are the evidence that your writing interprets, not just decoration.

Components of a rationale

1. Questions: what did you actually have to decide? (not “how do I design for cows”, but “how does a cow select from a list?”)
2. Options: what could you have done? At least two per question.
3. Criteria: what did you judge them on? This is where HCI concepts earn their place.
4. Trade-offs: what did you give up? Every choice has limitations.

Questions/options/criteria come from design space analysis (MacLean et al., 1991). The insistence on writing the downside of every feature alongside its upside comes from claims analysis (Carroll & Rosson, 1992).

You’re allowed to tidy up

Real design is messy. You double back, change your mind, and often discover the real problem while solving the wrong one. Our tidy lifecycle diagram is a tidied-up version of a scruffy reality.

Your rationale does not have to reproduce that mess chronologically. Parnas and Clements: we will never design in a perfectly rational way, but we can present the work as though we had (Parnas & Clements, 1986).

• Do reconstruct your reasoning clearly, so a reader can follow it and challenge it
• Do report dead ends that taught you something — they are evidence of a space explored
• Don’t invent a process you didn’t follow, tidying is not the same as fabrication

In Assignment 1: your portfolio (sketches, prototype photos) shows the process. Your rationale makes the argument.

What is a requirement?

“A statement about an intended product that specifies what it is expected to do and how it will perform” (Rogers et al., 2023, p. 387)

• Discovered through targeted activities or tangentially throughout the design process
• Evolve during design
• Different levels of abstraction and detail
• Needed to avoid misunderstanding and miscommunication

Defining a requirement

• Requirements can be captured casually, e.g., “app needs to be fast”
• Can be useful to have more details, precision about the requirements, who needs them, and why.
• Formal methods exist for capturing requirements in complex projects
• Epics, user stories in Agile methodologies
• Volere “Atomic Requirements Shell” (see figure)
• “Description, Rationale, Source, Fit criterion, Customer satisfaction…”

User stories

Communicates a requirements between stakeholders. Have the generic form:

As a <role>, I want <behaviour> so that I can <benefit>

e.g.,:

• “As a student, I want to choose a tutorial time that doesn’t clash with other activities, so that I can attend all my classes in a week.”
• “As a lecturer, I want to adjust the number of students in tutorials, so that I can provide a good learning experience.”

A user story is a simple way to connect a requirement to a particular type of user in a particular situation. In agile, user stories can be grouped into larger arrangements called “epics” and even bigger groups called “initiatives”.

Types of requirements

• Functional requirements: What the product will do

• Data requirements: type, properties of data involved in an interactive system

• Environmental requirements: context of use, what are the circumstances in which interaction happens?

  • Phsyical environment: noise, lighting, movement, etc
  • Social environment: sharing data, collaboration
  • Support environment: assistance, training or help available or integrated
  • Technical environment: technologies available for the system (phone, watch, laptop, supercomputer?) or technical limitations

• User characteristics: abilities, skills, attributes of users

• Usability and user experience goals: what goals (see last week) prioritised and tracked?

Activity: Requirements

Data Gathering

There are lots of ways to discover requirements, some examples are below:

• Observation and Ethnography: observing people in real situations
• Diaries and interviews: (aka, asking), talk to people about their requirements, or ask them to record information
• Focus Group, User Study: talking with one or multiple people
• Questionnaires: asking people to answer specific questions
• Cultural Probes: sending arts & crafts materials to users to find out about their life/needs (B. Gaver et al., 1999)
• Contextual Inquiry: researcher immersed in context of use, visits the participant and interviews them in context (Beyer & Holtzblatt, 1997)

In this course we focus on interviews and user studies as methods for data gathering. Our focus is on the evaluation stage of design, but these methods can work at the discovery stage as well.

Personas and Scenarios

More detailed than a user story, includes:

• the person, their characteristics, motivations, etc (persona)
• their story, when, where, how, as a sequence of events (scenario)
• the goal, needs to fulfil, reason to interact with a system (goal)

Personas

• Rich descriptions of typical users
• Don’t describe specific people but realistic
• Describe goals, behaviours, activities, environment
• How would this person use this product?

Examples on Usability.gov

Personas: example, Julien the university worker

Personas: examples

Scenarios

Scenario Mapping: Design Ideation Using Personas

Scenario mapping is a group activity for generating ideas for a product or system using personas and a specific scenario. (PS: you’ll do a similar activity in next week’s tutorial).

• choose a scenario and persona,
• split a scenario up into steps (use sticky notes)
• choose categories for ideas, e.g.: design ideas, questions, problems, friction points, comments
• brainstorm ideas under specific categories

Activity: Scenario Mapping Example

Activity: Let’s scenario map 🗺️💁🏻🎤

• Have a look at the following miro board and add a post it. (how many students are here? can we break miro?)

• https://miro.com/app/board/uXjVJa-m2gU=/?share_link_id=689171092569

What is Ideation?

We’ve already done some ideation today! But what do I mean by that?

Ideation is the process of generating a broad set of ideas on a given topic, with no attempt to judge or evaluate them. (Aurora Harley, nngroup)

Fundamentals of Ideation

• ideas are not evaluated
• ideas are recorded and documented
• collaboration leads to diverse ideas

Generating many ideas: high probability that at least one is close to ideal.

Ideation for Everyday Design Challenges, nngroup

Choosing a Technique

Three ways ideation methods differ

Three dials to turn (Hornbæk et al., 2025, Section 31.2):

1. How far you reach for associations. The further out, the more novel the ideas, but the value might decrease
2. How other people are involved. Groups can generate more ideas but very large groups are difficult to manage.
3. What representation you use. Brainstorming is mostly verbal; sketching and storyboarding are visuospatial; bodystorming is physical.

Brainstorming and its variants

Shared principles across nearly all the variants:

• Postpone criticism: don’t throttle the generative phase
• Divergence: encourage wild, diverse ideas
• Quantity: as many as possible
• Build on others’ ideas
• Equal significance: every participant and idea counts

The named variants mostly change who writes when: braindump (individually, then share), brainwrite (write, pass on, elaborate), brainwalk (move between ideation stations).

How to run a brainstorm

Some ecommendations (Hornbæk et al., 2025, Section 31.2):

Lateral Thinking: Worst Possible Idea

Is this the opposite of brainstorming?

• Come up with the worst ideas you can think of
• Playful, fun, adventurous, effective
• Know that ideas won’t be scrutinised for being wrong

Dix argued that bad is the new good (Dix et al., 2006) using this as a class exercise.

Activity: What’s the worst possible idea

Does lateral thinking work?

Not everybody likes lateral thinking.

• Lateral thinking techniques (provocation, random words, worst possible idea) are a bit controversial (Hornbæk et al., 2025, Section 31.2)
• Wild ideas can be easy to find, but it’s not clear that they are valuable.
• Forced ideas are often variations on existing solutions.

So why do we do it? Because it gets a room talking and lowers the stakes for contributing; but it may not lead to better designs.

Analogies and metaphors

• Analogy: a comparison between two things — powerful for both communication and sparking ideas
• Metaphor: carry a structure from a domain the user already knows into your interface
• Provocation: challenge the status quo to explore new realities (a lateral thinking technique)

Both analogy and metaphor are in the professional top eight — these are not warm-up games.

Analogies in practice: interface metaphors

Exploit similarities to user’s knowledge of other domains. E.g.,

• Cards: Familiar, strong associations (playing, business, credit), flick through, sort, themed, structured
• Desktop and Recycle bin
• Shopping trolley and checkout
• Surfing the web

We’ll come back to design metaphors for AI in week 12.

Inspiration cards

A structured way to force distant associations (Hornbæk et al., 2025, Section 31.2):

• Technology cards — a technical opportunity or threat
• Domain cards — an experience or activity from users’ lives
• Draw at random, pair them, and ideate from the collision

E.g., distributed smart speakers × a family dinner.

Keeps ideas metaphorical and technically realistic. Card decks are a real HCI research contribution — see the SMeFT Decks for hybrid boardgames (Rogerson et al., 2023).

Ideating in other representations

Not everything is a sticky note.

• Sketch: simple, rough, quantity over quality enough detail to convey meaning, no more (much more next week)
• Storyboard: a visual story
• Prototype: building forces decisions and provokes new ideas. Thinking by doing.
• Bodystorm: physically act out the scenario, with props — combines empathy, brainstorming and prototyping

Unsticking a blocked session

Ideation gets stuck: you hit a wall, or anchor on an early idea (design fixation, more next week).

• Challenge assumptions: what did we assume about users, context, activities? Are those accurate and important?
• Mindmap: problem in the middle, ideas around it, connect with lines
• SCAMPER: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse
• Movement: turn a provocation into something usable
• Creative pause: step back, reflect, go outside. Proactive rather than reactive thinking

Involving other people

• Gamestorming: gamified ideation for energy and engagement — Fishbowl, Anti-Problem, Cover Story
• Cheatstorm: reuse ideas from earlier sessions as stimulus
• Crowdstorm: the target audience generates or approves ideas — social media, surveys, focus groups
• Co-creation workshops: combine methods over hours or days — icebreakers, vision, empathy, insight mining, framing, ideation, prototyping

Questions: Who has a question?

Who has a question?

• I can take cathchbox question up until end of the lecture
• For after class questions: meet me outside the classroom at the bar (for 30 minutes)
• Feel free to ask about any aspect of the course
• Also feel free to ask about any aspect of computing at ANU! I may not be able to help, but I can listen.