Show converted presentation markdown
DESIGN RATIONALES AND MODELS
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
WHERE ARE WE NOW?
==> picture [451 x 254] intentionally omitted <==
==> picture [142 x 21] intentionally omitted <==
----- Start of picture text -----
DEPARTMENT OF COMPUTER SCIENCE
AARHUS UNIVERSITY
----- End of picture text -----
==> picture [184 x 15] intentionally omitted <==
----- Start of picture text -----
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
25. FEBRUARY 2026 LAB COORDINATOR
----- End of picture text -----
==> picture [36 x 35] intentionally omitted <==
WHAT TO DO NOW (THIS WEEK)?
You should now do:
-
Read literature for week 5 - and earlier weeks ;-)
-
Your own inspirational work – edging closer to final Problem Area decision.
-
Start planning empirical work. Requires narrowing down user group.
-
Tooling exercises.
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
STATUS AND MESSAGES
Monday trip!
How is it going?
Context, theme, subtheme, user group?
Any observations done? Places visited?
Choosing your topic? Done? Close?
Any questions?
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
SUB-ASSIGNMENT 1
-
Motivation for choice of subtheme, context and user group.
-
Initial positioning in relation to the theme (read some inspirational literature, introduce the field/theme and draw parallels + point out differences in approach)
-
Tentative problem formulation (what will you actually do in this project, what are your tentative hypothesis around practice and use, and what could help/fix/better/enhance this?)
-
Preliminary plan for your user research (who, when, what, how? Plans, contacts, emails, methods to try - this can be added as appendix if needed, but make sure to keep it concise).
DEPARTMENT OF COMPUTER SCIENCE
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
DESIGN RATIONALES AND MODELS
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
IN TODAY’S LECTURE
What is a design rationale?
Design Spaces
Contextual Design
Personas – representing users and roles
Working models
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
WHAT ARE IMPORTANT ASPECTS OF A GOOD DESIGN PROCESS? (2 MINUTES)
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
Result? The users liked it? The designer is proud of it? Sticking to the budget? Listening to the users? Getting paid? Getting promoted? Getting recognition? Teamwork? Fun? Cake every Friday? Societal impact? Many daily users?
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
A happy customer? Spearheaded by a hotshot? Spoken about in the media? Using the newest technologies? Being completely unique? Involving the user every step? Sales after launch? Scalability? Handover? Celebrating when it’s done? Instagram Influencers loving it? Trustpilot score? Certifications?
==> picture [36 x 35] intentionally omitted <==
WHAT IS THE MOST CRUCIAL ASPECT OF A GOOD DESIGN PROCESS?
DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026 AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
DOCUMENTATION!
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
==> picture [36 x 35] intentionally omitted <==
WHY?
Design processes are long and complex, and involves many variables and parties
You often do not nail it the first time
Iterations and Fluidity
Learning and revisitability
DEPARTMENT OF COMPUTER SCIENCE
SIMON HOGGAN CHRISTENSEN LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
DESIGN RATIONALE
A survey paper of representation methods for Design Rationale For this lecture we focus on understanding the concept (sect 1-3)
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
SIMON HOGGAN CHRISTENSEN LAB COORDINATOR
AARHUS UNIVERSITY
DESIGN RATIONALE (LEE AND LAI)
To document genealogy (tracing of lineage) of a design’s final appearance and the decisions that lead to it
To link issues to formal design decisions (example: global menu to reduce screen clutter)
Document selection and de-selection arguments
- Supporting and counter arguments on issues for the design
May lead to generalizable patterns and reusable design-decision relations (Fischer 1991)
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
WHAT IS DESIGN RATIONALE?
Design rationale is write-down of arguments and decisions made during a design process, and the reasons for why those arguments were brought up, and the decisions were made. Primary goal is to support designers by providing a means to record, describe, justify and communicate the argumentation and reasoning behind the design process (MacLean 1991), including but not limited to:
-
The reasons behind a design decision
-
The justification for a design decision
-
The other alternatives considered
-
The trade-offs evaluated
-
The argumentation that led to the decision (what if the argument was BS?)
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
WHAT IS DESIGN RATIONALE?
“Design rationale in the most general sense is an explanation of why an artifact is designed the way it is”
- LEE AND LAI, 1992
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [294 x 376] intentionally omitted <==
DESIGN SPACE
Design Space is a representation of alternative design options + analysis of pros/cons and relations.
From MacLean 1989:
“The design space consists of a decision space (alternative options which might be appropriate}, and an evaluation space(explicit reasons such as consistency and criteria for choosing from among the possible options).”
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
==> picture [314 x 369] intentionally omitted <==
DESIGN SPACE
Evaluation Space
Mapped differently in a lot of HCI literature… Issue (and Design Rationale) being the most impactful difference from Lee and Lai, adding potential issue handling to your argument space.
Design Rationale vs Design Space
Design Rationale describes the Design Space (MacLean).
Using for example the QOC model to represent Design Space options, generates Design Rationale.
Interesting possible exercise: Part of group specs decision space, another the beginning of evaluation space
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
SIMON HOGGAN CHRISTENSEN LAB COORDINATOR
==> picture [314 x 369] intentionally omitted <==
DESIGN SPACE
Long story short:
The map metaphor is a bit funky…
Think of products as clusters (buildings) on the map. The Design Space is the entire map, linking (making roads) and including/excluding certain alternatives (neighbourhoods).
QOC model used extensively in this process, and sticking to just this might be simpler.
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
THE QOC MODEL
Developed by McLean at Xerox PARC A brilliant comparative tool Helps map Design Space Part of your Design Rationale
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
==> picture [525 x 326] intentionally omitted <==
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
PARKING GATE: SAME CORE FUNCTIONALITY, SAME QUESTION – DIFFERENT DESIGNS
==> picture [329 x 247] intentionally omitted <==
Pay-by-plate is a radical change within/of design space
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
21
DESIGN SPACE
==> picture [401 x 349] intentionally omitted <==
----- Start of picture text -----
evaluation space
“How does the user
pay for parking?”
Pay-by-plate Privacy
Ease
Machine
Culture
with card
decision space
What happens if
user has lost ticket?
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
25. FEBRUARY 2026 LAB COORDINATOR
----- End of picture text -----
==> picture [142 x 21] intentionally omitted <==
----- Start of picture text -----
DEPARTMENT OF COMPUTER SCIENCE
AARHUS UNIVERSITY
----- End of picture text -----
==> picture [36 x 35] intentionally omitted <==
DESIGN SPACE
Is useful for emplacing your design and the alternatives/related design (for analysis, juxtaposition and distinctions)
Is useful for expanding horizons and taking different/novel interactions/systems into account.
It is a concrete way of making constraints visible and impactful in design
- For example through questions or criteria in QOC
DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
THE ROLE OF A DESIGN RATIONALE
Support and capture the design argumentation during a design process
When iterations occur, designers can go back and avoid mistakes or decisions already tested and rejected
Argument for why the final design appear as it does and support for designing the next version of the product
- A formerly too expensive or too clunky solution has become feasible in the mean time, and the process can be started from better position
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
24
REPRESENTATIVE QUESTIONS
Made by Lee and Lai to provide a framework for assessing different representations Since it’s used to assess representations/models way of making Design Rationale; Also a brilliant set of questions to help your design rationale and status meets Can be used as a part of sit-down meetings to organize your team’s thoughts Not all representations and models answers all questions
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
REPRESENTATIVE QUESTION SET EXAMPLE
Italic: Maybe for status meets? Orange: Maybe for Ideation and Concept Dev.?
What are our user’s biggest issues? What are our biggest issues? What is the status of the current design?
What did we discuss last week and what do we need to do today/this week? What are alternative designs and what are their pros and cons?
What if we do not consider power/portability/user interface/GPU muscle/CPU muscle? Which issues are inherently linked?
What would the consequence of removing this aspect/part be? Which unresolved issues do we still have?
How do past designs or other fields deal with a similar issue?
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
WHY IN ITPDP?
Tools, representations, models to help keep track of design documentation Help structure solved problems and the user-centric elements of your design Graphical representations to use for the report, that shows field knowledge if used correctly. Future work for your report Preparation for your exam
Avoid having to say “… I don’t know we why did that, actually…” J DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
SUMMARY
Make sure to document your design issues, positions, arguments with decision. Use it for your internal discussions. And for feedback. And for the report. And for the demo.
When a reviewer ask ”why didn’t you put that button on the top instead of here?” Your design rationale will help you provide the answer.
-
the answer may be feasibility of construction, or the occurrence of accidental push during an evaluation or.
-
If you don’t have an answer, then the design may appear coincindental and not well argued…
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
CONTEXTUAL DESIGN AND CONTEXTUAL INQUIRY
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
CONTEXTUAL DESIGN
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
SIMON HOGGAN CHRISTENSEN LAB COORDINATOR
AARHUS UNIVERSITY
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
User-centered design process
Focus on collecting and interpreting data of users in the field Focus on creation of prototypes and systems as end goal
“…Understand users in order to find out their fundamental intents, desires, and drivers. But these are invisible to the users - so the only way to glean this is to go out in the field and talk with people.”
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
Step-wise method and principle-based
-
Especially helpful for people who will not specialize in field study
-
Fits into a software development cycle; products of field study work made visible
Guides analyst on how to understand & document what he/she sees
Not really users as co-designers
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
Principle: System design must support and extend users’ work practice
Behavior, attitudes, goals, and intents of users; all part of work practice.
Work practice is part of the larger context – so is technology. Any and all system/tech change will impact work practice.
DEPARTMENT OF COMPUTER SCIENCE
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
Principle: People are experts at what they do – but are unable to articulate their own work practice
Field work = crucial to pick up on these practices/tendencies/events. Tacit knowledge. Multiple methods can help with this – participate in natural context.
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
Principle: Good design requires partnership and participation with the users
Designers = experts in design. Users = experts in work practice. Partnership = proper design focused on context and practice. Step in and do your part – ask questions, offer interpretations!
DEPARTMENT OF COMPUTER SCIENCE
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
Principle: Good design is systemic
Good design considers the system as a whole, and it’s impact on it. Methods can support generating overview of possible outcomes and implications. Treat issues and problems to be solved as a part of the whole.
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
CONTEXTUAL DESIGN (BEYER & HOLTZBLATT)
Principle: Design depends on explicit representations
Use drawings, sketches, prototypes, mock-ups, models, videos, animations etc. Visual representation is key and makes design thoughts sharable.
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
CONTEXTUAL DESIGN PROCESS
==> picture [574 x 320] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
CONTEXTUAL INQUIRY - FIELD STUDIES
Often two elements: Direct Observation and Interviews (+ Contextual Interviews (TBA))
Field studies are useful to understand:
-
The use context
-
Challenges and potential value added by a new design
-
People and their roles (end-user, indirect user, manager)
-
Features of the place/space
-
Understand the activity that you want to support
-
Communications and patterns of interactions
-
Local culture
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
WHAT ARE FIELD STUDIES?
It is not simply “hanging out” with users Field studies are (and requires the analysists to be):
-
Systematic and careful
-
Without assumptions (as much as possible!)
-
Thoughtful
-
Respectful
-
Productive!!
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
WHY FIELD STUDIES?
“Ground” designs in real activity, not assumptions
Do NOT falsify empirical data…
Helps understand “situated activity” not “rationalized accounts”
-
See exceptions, exception handling, mechanics
-
User behavior needs to be understood at a low-enough level to design for it
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
AN EXAMPLE FROM DEVELOPMENT OF “FINDING NEMO”
==> picture [402 x 296] intentionally omitted <==
“Finding Nemo”-movie animators had to ”ground them selves” by practicing scuba diving to become familiar with under water phenomena in order to be able to draw and animate them.
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
BASIC RULES & PRINCIPLES
Be an apprentice:
Carefully frame questions
-
Be polite –> the user is the expert in their domain
-
Be humble –> assume you don’t understand something
Be open-minded
- Expect to see a lot of things you didn’t think you would
Check interpretations;
-
Do not ask leading questions
-
Do not ask Yes and No questions
-
Focus on getting concrete data
Don’t be too narrow… Don’t be too wide
-
Begin by observing more WIDELY than defined problem(!)
-
REDEFINE boundaries of problem
-
Work within that new “unit of analysis”
-
Reflect back to user; debriefing
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
INTERVIEW TECHNIQUES
In interviews – be concrete and relate to daily work examples
-
Ask about examples from yesterday or last week
-
Critical Incident Technique , Wendy Mackay (expanded upon next slide)
-
Page 7: https://www.lri.fr/~mackay/VideoForDesign/print/print.pdf
Exceptions are as important as the routine situation
-
Listen to user anecdotes and workarounds
-
Exceptions may reveal important requirements and conditions – or just common practice
Be aware of potential intention conflicts (culture/hierarchy)
- Different user groups (or levels) do not necessarily share the same experience/intention
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
EXAMPLES FOR CRITICAL INCIDENT TECHNIQUE
Ask for a concrete, critical incident
-
Positive: Can you remember the last time when you were really happy with the UI?
-
Negative: What happened the last time when you very disappointed by the system?
Let the user go through the entire scenario
-
Positive: Identify useful features and design rationales
-
Negative: Identify break down scenarios
Ask for as many details as possible
Ask why this situation was in particular memorable
Do not ask suggestive or general questions
-
Why is this UI so good?
-
E.g., Do you like the UI?
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
SIMON HOGGAN CHRISTENSEN LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
RECORDING YOUR DATA
Notes Pictures (get consent, adhere to GDPR regulations) Video (get consent, adhere to GDPR regulations) Sound (get consent, adhere to GDPR regulations) Sketches and drawings Scenarios (post hoc description) Notes on roles/personas
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
46
FIELD STUDIES - PREPARATION
You have already done some observations (right?) – but mainly inspirational!
For future field work:
Secure permission to be at the site
Plan ahead, don’t expect to get into calendars quickly – it’s good to have a foot in the door someway You want to observe the natural workflow of your users:
-
Ask that users not “clean up” their desks or desktops, calendars, and so on because you will be there. Politely explain that you want to see things as they normally occur
-
Prepare and test all data recording equipment
On arrival, be professional, courteous and patient. Remember that you are a guest. Some might see it as additional workload.
DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
CONTEXTUAL INTERVIEWS
Not your typical Q&A interview
- A mix of observation & questions
Who to interview: those doing the work, not just management
-
2-3 hours of observing a user work, including “shadowing” them around the workplace
-
Observe the natural flow of activity and occasionally interrupt to explain and clarify what they are doing.
-
You can ask users to “think aloud” to understand their thought process.
-
Your questions are guided by what you see.
Recording: Notetaking, audio record, and perhaps video-record
Save the last 15 minutes with the user to review what you learned
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
HINTS AND ADVICE
Good idea to combine techniques
-
Observation and Interviewing have different strengths and weaknesses
-
Combination ensure quality of investigation
From pure analysis to design oriented activities
- Scenario and mock-up design may reveal useful knowledge about current state of affairs
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
PERSONAS
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
==> picture [36 x 35] intentionally omitted <==
50
PERSONA
Persona is personified but generalistic. Not the same as an archetype (abstract) or a person (individual). A persona description gives details about the user group(s) you are designing your interactive system for It highlights the group specific requirements and context associated with persona.
More on that in lecture: Sketching User Experiences (Minna) https://www.interaction-design.org/literature/article/four-different-perspectives-on-user-personas DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
51
PERSONA
Sub-assignment 2
==> picture [404 x 200] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
52
– PERSONAS EXAMPLES A TRAVEL APP
DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026 AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
53
DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR AARHUS UNIVERSITY
54
55
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
56
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
| 25. FEBRUARY 2026 ITPDP - RATIONALE AND MODELS |
LAB COORDINATOR SIMON HOGGAN CHRISTENSEN |
|---|---|
USE OF PERSONAS
Analyze and reveal requirements for system/app design from different perspectives (use scenarios, drivers, intent) Integrate in scenario descriptions (later assignments) Use persona description for your new design (or styling) Utilize for prototyping and evaluation planning
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
57
REMEMBER THE NOT-AVERAGE
”Extreme characters” (also used for ‘Ideation’ later in the course) Extremes in travel app
-
The passionate business person and car-driver that almost never use public transportation
-
• Elderly who do not have knowledge of smartphones
==> picture [320 x 253] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
CONTEXTUAL INQUIRY – PROCESSING RESULTS
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
GOT DATA? NOW WHAT?
Create “models” that capture the data (order different from literature)
- Physical Model:
a map of the site with details about equipment location
- Flow Model:
Depicts work-flow between users/personas
- Sequence Model:
Depicts work tasks
- Artifact Model:
Describes the tools that people use to complete tasks
- Cultural Model:
Captures bigger context of cultural factors that influence how things are done
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
PHYSICAL MODEL – HOTEL CASE
==> picture [383 x 232] intentionally omitted <==
Map of site with important features
Include digital photographs to elaborate Include traffic and potential “incident” areas or bottle-necks.
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
FLOW MODEL
Represents how work is divided & coordinated Flow models for different types of workers
-
- Diagram who is involved in the work
-
- Show communication flows between people, and how those communications are achieved (through invoices, face-to-face, messages)
-
- Mark breakdowns in communication & coordination
DEPARTMENT OF COMPUTER SCIENCE
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
FLOW MODEL – HOTEL CASE – STEP 1: ROLES
- Define Personas (+tasks) in circles
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
==> picture [500 x 346] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
-
FLOW MODEL – STEP 2: FLOW - Define Personas in circles
-
Define Artifacts in squares
-
Define Relational Actions with arrows
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
==> picture [184 x 15] intentionally omitted <==
----- Start of picture text -----
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
25. FEBRUARY 2026 LAB COORDINATOR
----- End of picture text -----
SEQUENCE MODEL
Represents work tasks by point of view (POV), shown as a sequence of steps of actions
Diagram:
-
Intent/Purpose of the action sequence
-
Trigger that causes the action to start
-
The steps that achieve the intent
-
Breakdowns/problems in getting the task done
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
SEQUENCE MODEL EXAMPLE – HOTEL BOOKING
Diagram:
-
Intent/Purpose of the action sequence
-
Trigger that causes the action to start
-
The steps that achieve the intent
-
Breakdowns/problems in getting the task done
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
ARTIFACT MODEL
Artifacts are the things people use in to complete a tasks (documents, maps, notes, the web, spatial layout of items when planning something)
-
- Collect artifacts, pictures of artifacts
-
- Check with customers that you understand what they are for
-
- Annotate these to identify in detail their functions
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
ARTIFACT EXAMPLE – HOTEL DIARY
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
==> picture [184 x 15] intentionally omitted <==
----- Start of picture text -----
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
25. FEBRUARY 2026 LAB COORDINATOR
----- End of picture text -----
ARTIFACT EXAMPLE
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
CULTURAL MODEL
Understand the local culture and the cultural assumptions. This is the broader context.
For each point of view
-
Start with each “influencer”—different groups of people, organizations, institutions—that affect how that person understands and does their work 2. Arrange these as bubbles or balloons that have different scope reflecting how much influence they have on the worker
-
Identify breakdowns
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
==> picture [471 x 420] intentionally omitted <==
----- Start of picture text -----
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN
25. FEBRUARY 2026 LAB COORDINATOR
----- End of picture text -----
CULTURAL MODEL - EXAMPLE
Goals and relationships between user groups and organizational values Constraint focused
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
MODEL EXAMPLE EXERCISE!
Group 1, 2: Physical Model example of FORMLab or PROTOLab Group 4, 5, 6: Flow Model example from (one of) your jobs Group 7, 8, 3: Sequence Model example from a recent novel interaction/experience Group 12, 13, 16: Cultural Model example from a community Group 20, 11: Artifact Model 3 x examples of tools for work activities from your life (can be pictures) or Google J
15 minutes, then quick presentations.
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY
SUMMARY:
The 5 models capture:
-
How the physical environment supports the work [Physical model]
-
The people, their relationships, and their communications [Flow models]
-
How tasks are carried out [Sequence models]
-
How artefacts support the work or are processed as part of the work [Artifact models]
-
How work is constrained by organizational values [Cultural models]
DEPARTMENT OF COMPUTER SCIENCE
==> picture [36 x 35] intentionally omitted <==
ITPDP - RATIONALE AND MODELS SIMON HOGGAN CHRISTENSEN 25. FEBRUARY 2026 LAB COORDINATOR
AARHUS UNIVERSITY
SUMMARY
DEPARTMENT OF COMPUTER SCIENCE ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026 AARHUS UNIVERSITY
==> picture [36 x 35] intentionally omitted <==
74
SUMMARY
Document your design and design rationale!
Design needs to take the user, the context, and constraints of the problem domain into account Thus, user involvement in design is important.
Prepare for design through contextual inquiries
-
Capture your understanding in the five models, personas and scenarios
-
Triangulation
Later envisionment through prototyping become essential
- Based on contextual inquiry models, personas, and scenarios
Plan your field study methods carefully - get help from TAs
DEPARTMENT OF COMPUTER SCIENCE
ITPDP - RATIONALE AND MODELS 25. FEBRUARY 2026
SIMON HOGGAN CHRISTENSEN LAB COORDINATOR
==> picture [36 x 35] intentionally omitted <==
AARHUS UNIVERSITY
==> picture [783 x 440] intentionally omitted <==