## Announcements - **Class reps!** Needed now! (need at least 2 in total, ~1-2 UG and ~1-2 PG) - If you would like to nominate as a class rep, please make a private post on the class forum. - **Tutorial 1**: Making, this week make a zine! - **Big class!** - keep showing up, - keep asking questions, - stay constructive and positive (especially with your tutors!) ## Plan for the class - Design Processes - Discovering Requirements - Ideation # The Interaction Design Process How do you get from a problem to something people can actually use? ## 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
Prototyping some solutions (to what?)
## Double Diamond Model
The double diamond model of design (adapted from Design Council, 2025)
## 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
The double diamond model of design (adapted from Design Council, 2025)
## 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[^1] - *Crowd-sourced:* large surveys, crowd-sourcing, community engagement - *Participatory:* users central to planning, ideating, prototyping (co-design, co-creation)
A user participating in face-to-face evaluation at ANU.
## User-centred design principles From *Designing for Usability: Key Principles and What Designers Think* ([Gould & Lewis, 1985](#ref-gould-usability: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](#ref-rogers-beyond-hci: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
Photo by Timon Studler on Unsplash
## Activity: People vs Users
**Talk:** 🙋🏽‍♀️🤷💁🏻🧠🗣️ Find someone near you, ask who they are, and discuss: 1. Who is the most important stakeholder? Users? Managers? People? And why? 2. How would you get information from this stakeholder? Chat for 3 minutes and we’ll hear a few responses.
## Interaction Design Lifecycle
An interaction design lifecycle (adapted from Rogers et al., 2023)
## 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*
An uncommon technology: a VR walkable interface (Je et al., 2021)
## Research through Design Design isn’t only the thing we *study*, it can be the *way the research is done* ([Frayling, 1993](#ref-frayling-research-art-design: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](#ref-zimmerman-research-through-design:2007)). - the formality of this process is still argued ([Zimmerman et al., 2010](#ref-zimmerman-rtd-critique: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](#ref-gaver-expectations-rtd:2012)). # Design Rationales The assignment asks you to write a *design rationale*, but what is that? ## 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](#ref-maclean-argument-behind-artifact: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](#ref-maclean-qoc: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](#ref-maclean-argument-behind-artifact: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](#ref-gaver-annotated-portfolios: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](#ref-buxton-sketching: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](#ref-maclean-qoc:1991)). The insistence on writing the **downside** of every feature alongside its upside comes from claims analysis ([Carroll & Rosson, 1992](#ref-carroll-task-artifact: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](#ref-parnas-fake-it: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. # Discovering Requirements Where do requirements come from? ## 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](#ref-rogers-beyond-hci:2023)) - 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
Image: (Rogers et al., 2023, p. s11.2)
## 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…”*
(Rogers et al., 2023, p. s11.3)
## User stories Communicates a requirements between stakeholders. Have the generic form: `As a , I want so that I can ` 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
**Think:** Come up with a design requirement for **one** of the following products: - 🗣️ A voice-activated smart home assistant that helps individuals control lighting and temperature. - 📲 A phone-based ordering system for a restaurant. - 🤖 A humanoid robot for assisting computer science students in computer labs. Spend 2-3 minutes developing one requirement and then let’s hear a few. 🎤🎤🎤
## 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](#ref-gaver-cultural-probes)) - **Contextual Inquiry**: researcher immersed in context of use, visits the participant and interviews them in context ([Beyer & Holtzblatt, 1997](#ref-contextual-design: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**)
A persona, a scenario, and a goal (© Smashing Magazine)
## 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](https://www.usability.gov/how-to-and-tools/methods/personas.html)
Image source
## Personas: example, Julien the university worker
Example of a persona from research into autonomous taxi services (Hallewell et al., 2022)
## Personas: examples
## Scenarios
- A narrative describing human activities or tasks. - Allows exploration and discussion of contexts, needs, and requirements. - Doesn’t necessarily describe the software/technology used - Core: goal, steps to reach the goal, who the user is (persona) - Extra: other details that might be useful.
- “Nia is a sound designer working in the automotive industry.” - “When tasked with creating sound signals for automotive applications, Nia needs to consider the cognitive flow of users, particularly how different chords interact and influence user attention. To support this logic-making process, Nia uses an AI-powered tool that helps her design a storyboard, select suitable chords, and assign them to the relevant phases.” - “After establishing the storyboard, Nia transitions to another MIDI software via the tool’s connected API for sound creation and refinement.” Example scenario excerpt from Minsik Choi’s ANU research ([Choi et al., 2025](#ref-choi2024scenario)).
## Scenario Mapping: Design Ideation Using Personas
[Scenario mapping](https://www.nngroup.com/articles/scenario-mapping-personas/) 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
Scenario mapping example. Source: nngroup
## 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?) -
The miro board
# Ideation How do you get from one idea to many? ## 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](https://www.nngroup.com/articles/ux-ideation/)) ## 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](https://www.nngroup.com/articles/ux-ideation/)
Ideation doesn’t waste time, it saves time (Aurora Harley)
## Choosing a Technique
**Eight most used by professional designers** ([Hornbæk et al., 2025, Section 31.2](#ref-hornbaek-intro-hci:2025)): 1. Brainstorming 2. Morphological analysis 3. Scenarios 4. Conceptual maps 5. Checklists 6. Analogies 7. Metaphors 8. Storyboards
**Variants:** Braindump, brainwrite, brainwalk, **worst possible idea**, challenge assumptions, mindmap, sketchstorm, **bodystorm**, provocation, SCAMPER, movement, gamestorming, cheatstorm, crowdstorm, co-creation, prototyping, creative pause
## Three ways ideation methods differ Three dials to turn ([Hornbæk et al., 2025, Section 31.2](#ref-hornbaek-intro-hci:2025)): 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).
HCI tutorial tables in 2025
## How to run a brainstorm Some ecommendations ([Hornbæk et al., 2025, Section 31.2](#ref-hornbaek-intro-hci:2025)):
1. **Sharpen the focus:** clear, but not so narrow it limits solutions 2. **Playful rules:** no criticism, no debating the brief 3. **Number your ideas:** aim for ~100 in an hour 4. **Build and jump:** when the rate drops, jump to another part of the problem
5. **Use the space to remember:** spread ideas over tables, walls, whiteboards 6. **Stretch first:** warm up with a word game 7. **Props:** bring physical props, materials, competitors’ products
## 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](#ref-dix2006bad)) using this as a class exercise.
Photo by Andre Hunter on Unsplash
## Activity: What’s the worst possible idea
**Think:** (let’s try it!) What’s the worst idea for: > A way to help students balance work and study. Think for a minute or two and then we’ll hear some answers. ⭐️🎙️🗣️ Prepare for this question: “Why is that bad?”
## 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](#ref-hornbaek-intro-hci:2025)) - 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.
What if the microbit was really REALLY big.
## 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.
A highly metaphorical interface. (Gentner & Nielsen, 1996)
## Inspiration cards
A structured way to force distant associations ([Hornbæk et al., 2025, Section 31.2](#ref-hornbaek-intro-hci:2025)): - **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](#ref-rogerson-smeft-decks:2022)).
Prototyping weird stuff at NIME2015
## 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
Bodystorming some art in 2008.
## 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](https://www.interaction-design.org/literature/article/learn-how-to-use-the-best-ideation-methods-scamper):** Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse - **[Movement](https://thoughtegg.com/provocations-creative-technique/):** turn a provocation into something usable - **Creative pause:** step back, reflect, go outside. Proactive rather than reactive thinking
Beating Creative Blocks Through Reframing
## Involving other people
- **[Gamestorming](https://gamestorming.com/):** gamified ideation for energy and engagement — Fishbowl, Anti-Problem, Cover Story - **[Cheatstorm](https://www.interaction-design.org/literature/topics/cheatstorming):** 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
Co-creation in 2010.
## 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.
Meet you at the bar for questions. 🍸🥤🫖☕️ Unfortunately no drinks served! 🙃
# References
Beyer, H., & Holtzblatt, K. (1997). *Contextual design: Defining customer-centered systems*. Morgan Kaufmann Publishers Inc.
Buxton, B. (2007). *Sketching user experiences: Getting the design right and the right design*. Morgan Kaufmann Publishers Inc.
Carroll, J. M., & Rosson, M. B. (1992). Getting around the task-artifact cycle: How to make claims and design by scenario. *ACM Transactions on Information Systems*, *10*(2), 181–212.
Choi, M., Andres, J., Hunter, A., & Martin, C. P. (2025). Scenario-based design to envision how GenAI can support sound design practices. *Proceedings of the 36th Australasian Conference on Human-Computer Interaction*, 640–646.
Design Council. (2025). *The double diamond: A universally accepted depiction of the design process*.
Dix, A., Ormerod, T., Twidale, M., Sas, C., Silva, P. A., & McKnight, L. (2006). Why bad ideas are a good idea. *HCI Educators Workshop 2006*.
Frayling, C. (1993). Research in art and design. *Royal College of Art Research Papers*, *1*(1), 1–5.
Gaver, B., & Bowers, J. (2012). Annotated portfolios. *Interactions*, *19*(4), 40–49.
Gaver, B., Dunne, T., & Pacenti, E. (1999). Design: Cultural probes. *Interactions*, *6*(1), 21–29.
Gaver, W. (2012). What should we expect from research through design? *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, 937–946.
Gentner, D., & Nielsen, J. (1996). The anti-mac interface. *Commun. ACM*, *39*(8), 70–82.
Gould, J. D., & Lewis, C. (1985). Designing for usability: Key principles and what designers think. *Commun. ACM*, *28*(3), 300–311.
Hallewell, M. J., Hughes, N., Large, D. R., Harvey, C., Springthorpe, J., & Burnett, G. (2022). Deriving personas to inform HMI design for future autonomous taxis: A case study on user requirement elicitation. *Journal of Usability Studies*, *17*(2).
Hornbæk, K., Kristensson, P. O., & Oulasvirta, A. (2025). *Introduction to human-computer interaction*. Oxford University Press.
Je, S., Lim, H., Moon, K., Teng, S.-Y., Brooks, J., Lopes, P., & Bianchi, A. (2021). Elevate: A walkable pin-array for large shape-changing terrains. *Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems*.
MacLean, A., Young, R. M., Bellotti, V. M. E., & Moran, T. P. (1991). Questions, options, and criteria: Elements of design space analysis. *Human-Computer Interaction*, *6*(3–4), 201–250.
MacLean, A., Young, R. M., & Moran, T. P. (1989). Design rationale: The argument behind the artifact. *ACM SIGCHI Bulletin*, *20*(SI), 247–252.
Parnas, D. L., & Clements, P. C. (1986). A rational design process: How and why to fake it. *IEEE Transactions on Software Engineering*, *SE-12*(2), 251–257.
Rogers, Y., Sharp, H., & Preece, J. (2023). *Interaction design: Beyond human-computer interaction, 6th edition*. John Wiley & Sons, Inc.
Rogerson, M. J., Sparrow, L. A., & Freeman, S. O. (2023). The SMeFT decks: A card-based ideation tool for designing hybrid digital boardgames for distanced play. *Proceedings of the 34th Australian Conference on Human-Computer Interaction*, 298–309.
Zimmerman, J., Forlizzi, J., & Evenson, S. (2007). Research through design as a method for interaction design research in HCI. *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, 493–502.
Zimmerman, J., Stolterman, E., & Forlizzi, J. (2010). An analysis and critique of research through design: Towards a formalization of a research approach. *Proceedings of the 8th ACM Conference on Designing Interactive Systems*, 310–319.
[^1]: This one is pretty normal in academic HCI research.