Whats in Design Rationale

Authors: Jintae Lee, Kum-Yew Lai
Year: 1991
Full title: in Design Rationale
ITPDP26 - Design Rationales and Models.pdf Open PDF
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

  1. Motivation for choice of subtheme, context and user group.

  2. Initial positioning in relation to the theme (read some inspirational literature, introduce the field/theme and draw parallels + point out differences in approach)

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

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

  1. Physical Model:

a map of the site with details about equipment location

  1. Flow Model:

Depicts work-flow between users/personas

  1. Sequence Model:

Depicts work tasks

  1. Artifact Model:

Describes the tools that people use to complete tasks

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

    1. Diagram who is involved in the work
    1. Show communication flows between people, and how those communications are achieved (through invoices, face-to-face, messages)
    1. 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:

  1. Intent/Purpose of the action sequence

  2. Trigger that causes the action to start

  3. The steps that achieve the intent

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

  1. Intent/Purpose of the action sequence

  2. Trigger that causes the action to start

  3. The steps that achieve the intent

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

    1. Collect artifacts, pictures of artifacts
    1. Check with customers that you understand what they are for
    1. 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

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

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

  1. How the physical environment supports the work [Physical model]

  2. The people, their relationships, and their communications [Flow models]

  3. How tasks are carried out [Sequence models]

  4. How artefacts support the work or are processed as part of the work [Artifact models]

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