Problem Area

Authors: Daniel Bulant, Mihai Petrut, Vladyslav Buzilov
Year: 2026
ITPDP26 - Physical Prototyping.pdf Open PDF
Show converted presentation markdown

PHYSICAL PROTOTYPING

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

AGENDA

Messages

Project planning and prototyping Using prototypes in concept evaluations Digital Fabrication

Electronics

Supervision after lecture

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

MESSAGES

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

THE ITPDP PROJECT

==> picture [634 x 357] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

THE ITPDP PROJECT

==> picture [634 x 357] intentionally omitted <==

==> picture [35 x 35] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

THE ITPDP PROJECT

From Brightspace under “ITPDP 2026” Presented at first lecture about course introduction

Eligibility for exam

To be eligible for the exam, each student must hand in all tooling exercises and supporting assignments, and every group must hand in the final report, be represented in the plenary sessions, and - of course - the exam related demo session and oral exam.

Goals and requirements for the final project

The IT product must be placed clearly in relation to one of the three subthemes (or have deviation agreed upon with course educator).

The group must demonstrate an understanding of the target user group's needs and conditions, using theory and tools introduced in this course, and/or theory/tools presented earlier in their study programme.

The solution must position itself as relevant to the future users, utilizing ethnomethodological work and user-centered design to ensure validity. A successful evaluation is however not a requirement, but reflection and analysis of validity, process and outcome is the main end result.

The context of use and the challenges identified in the user studies must be taken into account.

The solution must include multiple clients/components and the cloud (typically via web technology). Several subcomponents and resources that can communicate, e.g., a system with a mobile app, a physical installation, and with automatic storage of sensor data in the cloud.

The IT product may involve a smartphone as part of the solution, but there must be an interaction with physical/tangible components in the environment or on the user, which you have designed and fabricated yourself.

Arguments must be made based on the needs of the users, usage of theory and methods, and the business potential in relation.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

WORKLOAD AND EXPECTATIONS

Euro ean standard: 1 ECTS = 25-30 hours of work. p

For Aarhus University, it has been set at 28 hours.

ITPDP is slightly different.

First part (seen as a 5 ECTS course): 140 hours per person, including lectures/TØ, from 26th of January to 17th of March.

Second part (seen as a 15 ECTS course): 420 hours per person, including lectures/TØ, from 18th of March to June 17th. This is equal to a minimum of 32 hours per week. The rest of the course schedule is exam period and exam preparation time.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

WORRYING TENDENCIES

Resource hour overview:

Estimated teaching time: 68-70 hours, not including supervision.

1 person group: The overall project should reflect 490 hours of work. 2 person group: The overall project should reflect 980 hours of work. 3 person group: The overall project should reflect 1470 hours of work. 4 person group: The overall project should reflect 1960 hours of work.

In the current state, your project should currently represent roughly 230 hours per person. For a three person group = 425 hours of work (30% deducted, prioritization)

Can you honestly say that you have put this time into the project, preparation, lectures, reading etc.? If yes, then great!

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PROJECT PLANNING

A course. university

Project planning and implementation is part of the learning outcomes – we cannot guide and/or hand-hold you the entire way.

Make sure to keep yourself updated via the Course Schedule on Brightspace. Please ignore all other sources, as mentioned multiple times.

Be present… We cannot teach or supervise students who do not show up.

You can technically stay away from now until final report and exam, as long as Interview Assignment and Tooling Exercises are done. But don’t.

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PHYSICAL PROTOTYPING

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

MVP

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

“… Version of a product with just enough features to be usable by early customers”

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

MINIMUM VIABLE PRODUCT (MVP)

Often a term used in “Agile Prototyping”.

A way to create clear goals to be able to evaluate/validate a prototype/concept.

What is the minimum features our prototype needs to have, in order to solve the identified problem and/or answer the research question?

Build towards simplistic representations of your vision – not individual small parts.

==> picture [613 x 98] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

Agile Prototyping for technical systems – Schuh et al.

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

BUT HOW DO YOU PLAN THIS?

==> picture [713 x 300] intentionally omitted <==

https://activecollab.com/blog/project-management/moscow-method

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

MOSCOW EXAMPLE - KITCHEN TIMER

    • Time can be set (up to two hours) Timer can be set (up to 24 hours) - - Hours and minutes are separate Hours, minutes and seconds - - The user gets notified User gets multimodal feedback - - The timer can be reset Multiple concurrent timers - - Timer can be paused Small enough to carry - - Fits in the kitchen Battery lasts for full longitudinal - Battery lasts more than max. timer study duration Must have Should have - - Timer = multiple weeks? Could have Will not have Cloud-connection - - Smartphone connected Statistics and food categorization - - Contextual multimodal feedback Credit-card like footprint - Fusion sensing (thermometer?) - Solar panel

But… how do we prioritize these??

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

HOW TO PRIORITIZE POST MOSCOW

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

HOW TO PRIORITIZE IN MOSCOW

Aim high, scope appropriately – you should push yourself. Free Features First

Impact-analysis (Remember scenarios? Personas? Contextual Design?) The art of choosing the right ecosystem/backbone Pessimistic approximations

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

AIM HIGH, SCOPE APPROPRIATELY

Push yourselves, but lean into your skillset.

Always scope based on project goals (in this case course goals and delimitations). Do not let an overly simple MVP set you back.

An MVP is built to be your fallback – leave it alone, document, take pictures, make videos. Your MVP is then baseline for next iteration.

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

IMPACT ANALYSIS

Focus on scenario-based design and contextual design – use it!

Which features will have the most (positive) impact?

You understand your user and the context – use the analysis to strengthen arguments for feature prioritization.

==> picture [356 x 119] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

IMPACT ANALYSIS - KITCHEN TIMER

-
Time can be set (up to two hours)
-
Hours and minutes are separate
-
The user gets notified
-
The timer can be reset
-
Timer can be paused
-
Fits in the kitchen
-
Battery lasts more than max. timer
Must have
-
Timer can be set (up to 24 hours)
-
Hours, minutes and seconds
-
User gets multimodal feedback
-
Multiple concurrent timers
-
Small enough to carry
-
Battery lasts for full longitudinal
study duration
Should have
-
Timer = multiple weeks?
-
Smartphone connected
-
Contextual multimodal feedback
Could have
-
Cloud-connection
-
Statistics and food categorization
-
Credit-card like footprint
-
Fusion sensing (thermometer?)
-
Solar panel
Will not have

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

“FREE FEATURES FIRST”

Free features are not necessarily free, but requires very little technical reiteration.

Hardware vs. software Simple additions or changes

==> picture [254 x 210] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [140 x 153] intentionally omitted <==

==> picture [135 x 114] intentionally omitted <==

==> picture [191 x 144] intentionally omitted <==

==> picture [135 x 114] intentionally omitted <==

==> picture [258 x 199] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

IMPACT ANALYSIS - KITCHEN TIMER

-
Time can be set (up to two hours)
-
Hours and minutes are separate
-
The user gets notified
-
The timer can be reset
-
Timer can be paused
-
Fits in the kitchen
-
Battery lasts more than max. timer
-
Timer can be set (up to 24 hours)
-
Hours, minutes and seconds
-
User gets multimodal feedback
-
Multiple concurrent timers
-
Small enough to carry
-
Battery lasts for full longitudinal
study duration
-
Timer = multiple weeks?
-
Smartphone connected
-
Contextual multimodal feedback
-
Cloud-connection
-
Statistics and food categorization
-
Credit-card like footprint
-
Fusion sensing (thermometer?)
-
Solar panel
Must have
Should have
Could have
Will not have
-
Time can be set (up to two hours)
-
Hours and minutes are separate
-
The user gets notified
-
The timer can be reset
-
Timer can be paused
-
Fits in the kitchen
-
Battery lasts more than max. timer
-
Timer can be set (up to 24 hours)
-
Hours, minutes and seconds
-
User gets multimodal feedback
-
Multiple concurrent timers
-
Small enough to carry
-
Battery lasts for full longitudinal
study duration
-
Timer = multiple weeks?
-
Smartphone connected
-
Contextual multimodal feedback
-
Cloud-connection
-
Statistics and food categorization
-
Credit-card like footprint
-
Fusion sensing (thermometer?)
-
Solar panel
Must have
Should have
Could have
Will not have
-
Time can be set (up to two hours)
-
Hours and minutes are separate
-
The user gets notified
-
The timer can be reset
-
Timer can be paused
-
Fits in the kitchen
-
Battery lasts more than max. timer
-
Timer can be set (up to 24 hours)
-
Hours, minutes and seconds
-
User gets multimodal feedback
-
Multiple concurrent timers
-
Small enough to carry
-
Battery lasts for full longitudinal
study duration
-
Timer = multiple weeks?
-
Smartphone connected
-
Contextual multimodal feedback
-
Cloud-connection
-
Statistics and food categorization
-
Credit-card like footprint
-
Fusion sensing (thermometer?)
-
Solar panel
Must have
Should have
Could have
Will not have
-
Time can be set (up to two hours)
-
Hours and minutes are separate
-
The user gets notified
-
The timer can be reset
-
Timer can be paused
-
Fits in the kitchen
-
Battery lasts more than max. timer
Must have
-
Timer can be set (up to 24 hours)
-
Hours, minutes and seconds
-
User gets multimodal feedback
-
Multiple concurrent timers
-
Small enough to carry
-
Battery lasts for full longitudinal
study duration
Should have
-
Timer = multiple weeks?
-
Smartphone connected
-
Contextual multimodal feedback
Could have
-
Cloud-connection
-
Statistics and food categorization
-
Credit-card like footprint
-
Fusion sensing (thermometer?)
-
Solar panel
Will not have

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

https://www.uxpin.com/studio/blog/design-sprints/

TIME AND SPRINTS

A gile development methodologies often refer to the term “sprint”.

I strongly suggest using this approach for testing feasibility in feature-based prototyping.

Suggested framework for prototype sprint: Inspired by the often used “5-day design sprint” (or similar artzy naming scheme) Following MoSCoW prioritization and free-features-first analysis. Have initial brainstorm about implementation strategy. Divide most crucial features up, and sprint them in pairs. Work 24-72 hours on each feature depending on impact (two features being worked on simultaneously). End with feasibility assessment and construct time plan based on last sprint. Or scrap.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

PROTOTYPE EVALUATION

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

THE FALLACY OF FLAWLESS

Prototypes are inherently flawed.

Small factors and variance makes a difference for replicability and comparability.

The obvious end-goal is a self-sustained and robust system.

Often that is not the case… and maybe not the best and easiest way to add additional features?

DEPARTMENT OF COMPUTER SCIENCE

==> picture [184 x 183] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

WIZARD OF OZ

==> picture [518 x 357] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

https://www.nngroup.com/articles/wizard-of-oz/

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

FINISH, FIDELITY, FEEDBACK

Maryam Tohidi, William Buxton, Ronald Baecker, and Abigail Sellen. 2006. Getting the right design and the design right.

and

End goal of a prototype evaluation:

  • To validate concept

  • Evaluate user appropriation

  • Problem-solution fit

  • Feedback on future iterations

Prototype fidelity matters!

==> picture [131 x 206] intentionally omitted <==

Youn-Kyung Lim, Erik Stolterman, and Josh Tenenberg. 2008. The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas.

Users find it easier to critique lower fidelity prototypes.

Sometimes using multiple low-fidelity, feature-focused prototypes is the right way… … For evaluation J

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

DIGITAL FABRICATION

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

MANUFACTURING METHODS

Additive Manufacturing Subtractive Manufacturing 3D printing as example CNC (Computer Numerical Control) millin as exam le g p Adding layer by layer Taking away layer by layer Material base = often lastic Material base = often metals/wood p Often used for fast initial rotot in Often used for sturd construction p yp g y

==> picture [152 x 152] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

Combo = Hybrid Process

==> picture [184 x 185] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING 13. APRIL 2026

SIMON HOGGAN CHRISTENSEN LAB COORDINATOR

AARHUS UNIVERSITY

Meh?

1. What type of features does your product have?

  • small organic and intricate features → additive methods

  • large or sharp features, drilled and tapped holes or other fastening features →subtractive methods

2. What type of material do you want to work with?

  • thermoplastics and resins → additive methods

  • materials like metals, wood, or foam → subtractive methods

  1. How many units do you want to produce?
  • low-volume production or iterative prototyping → additive methods

  • large-volume production runs → subtractive methods

  • Meh?

RAPID PROTOTYPING

Purpose: Rapidly creating tangible artifacts or prototypes to filter/validate certain aspects.

Addendum: In house. By yourself. Something you hopefully made. Without ruining yourself… … or the equipment J

Most common practice and understanding: Utilizes digital fabrication, due to speed and work/process synchronizity.

Any fabrication occupying more than a few days is no longer rapid prototyping – it’s invested construction.

Invested construction is not a bad thing – perfect for prototyping towards final demo. Rapid prototyping is your tool to quickly test, validate and scrap. Anything too detailed - and invested - in can become hard to scrap.

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

RAPID PROTOTYPING

Mastering techniques, process, equipment = Absolute control regarding time and scope

DEPARTMENT OF COMPUTER SCIENCE

==> picture [446 x 441] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO

DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AGENDA

  • Why Arduino for prototyping

  • Alternative prototyping platforms (and what you will be taught about in other courses)

  • Code examples

  • ESP32 Wizard of Oz

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO AS PROTOTYPING PLATFORM

Readily available here and big part of our lab-ecosystem

Lots of documentation and code examples + tutorials

Easy prototyping, hook-up, HATs, powering etc.

Many variations, sizes and beefiness

==> picture [251 x 251] intentionally omitted <==

Often limiting: CPU/GPU power, threading/cores, memory, GPIO pin amount, buffer sizes, communication.

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

ALTERNATIVE PLATFORMS

Wemos D1 Mini (cheap WiFi board based on ESP8266)

ESP 32 (great platform with lots of possibilities)

RPI (when you want something in between a PC and an Arduino) ATMEL MCU family (used in PhysComp. When you want to create custom circuits) NUCs/Smartphones (for webapps/apps, graphics-intense tasks)

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO IDE

~~Arduin~~ o is an open-source electronics platform based on easy-to-use hardware and software. https://www.arduino.cc/en/software

==> picture [708 x 285] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ESP32

~~ESP32~~ is widely used in System-on-Chip (SoC) solutions designed for Internet of Things (IoT) applications due to its:

  • Integrated WiFi and Bluetooth

  • Lower power consumption with deep sleep modes

  • More I/O Features (than Arduino)

==> picture [264 x 263] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

PINOUTS?

==> picture [558 x 400] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ESP32

==> picture [737 x 374] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO V.S. ESP32 V.S. ESP8266

==> picture [850 x 352] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO COMPONENTS

DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

COMPONENTS – WHAT OPTIONS DO WE HAVE?

  • ~~Many~~ components will be covered in Physical Computing next semester: - Entire lecture set on sensors and what types we have in lab as inspiration. Engineering Interactive Technologies delves further into making novel sensing techniques.

  • Entire lecture set on actuators – even more time to delve into actuators in Multimodal Interaction and Shape Changing Objects and Spaces

  • For now: Use Johannes’ component inspiration kit and chomskylab.dk – and talk to supervisors/TAs/Labtools for further advice/inspiration.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO CODE EXAMPLES

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

ARDUINO CODE EXAMPLES

“AnalogInOutSerial.ino”

“Arrays.ino”

”Smoothing.ino”

“switchCase.ino”

WiFi network examples (third-party examples)

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

ANALOGIN OUTSERIAL

Example of map Example of analogRead Example of Serial.print

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARRAYS

Array example because slightly different syntax compared to java

DEPARTMENT OF COMPUTER SCIENCE

SIMON HOGGAN CHRISTENSEN LAB COORDINATOR

PHYSICAL PROTOTYPING 13. APRIL 2026

AARHUS UNIVERSITY

RUNNING AVG

”Smoothing.ino” in Arduino--> Examples Running average data smoothing Useful for sensor and input with noise Noise = variance in data without change in input

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

SWITCHCASE

Crucial for ITTT cases and sensing

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ESP32 EXAMPLE – YOUR WOZ CHEATSHEET

ESP32 is a brilliant platform for the Wizard of Oz method.

Example code in Brightspace.

Simple UI via WiFiServer à interaction with ESP32 Easily adaptable.

Of course only used for evaluation and prototyping, not the final demo J

==> picture [216 x 390] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

INSTALL THE ESP32 BOARD IN ARDUINO IDE

  • Open IDE and go to Tools > Board > Boards Manager

  • Search "ESP32", select " esp32 by Espressif Systems ", and click Install

  • Reopen Arduino IDE

  • Under Tools>Board you should see esp32 à ESP32 Dev Module option

==> picture [224 x 449] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

INSTALL USB CABLE DRIVER

~~Downl~~ oad Link: https://www.silabs.com/developer-tools/usb-to-uart-bridge-vcp-drivers

  • Windows Users: The Arduino Installer should install the USB Driver automatically. But in case it doesn't work, download from the link. Windows 10 users should use CP210x Universival Windows Driver , and Windows 8.1,8 and 7 users can use CP210x Windows Driver.

  • MacOS Users: Download the CP210x VCP Mac OSX Driver . After installing, accept Privacy changes and prompts. If install fails, install legacy driver variant.

  • Testing if the USB driver works (all OS): in the Arduino menu Tools>port before plugging in your ESP with the USB cable. You should see either none or one entry listed. Now plug in your ESP microcontroller and take another look at Tools>port . You should hopefully see one more entry. On Windows this will often be something like COM3 . On Mac it will be USB_to_UART or cu.usbserial

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

TESTING AND GETTING INFO

  • Open FileàExamples à Basics à BareMinimum and test that upload works to your ESP32.

  • During upload the device MAC adress will be written (including other useful info)

==> picture [613 x 162] intentionally omitted <==

  • Now it’s time to get on WiFi, by either using your phone hotspot as WiFi, or connect to AU-IoT via Simon (bring him your device MAC address)

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

GETTING ON WIFI

include const char ssid = "AU-IoT"; const char password = "test1234"; void setup(){ Serial.begin(921600); delay(1000); WiFi.mode(WIFI_STA); //Optional WiFi.begin(ssid, password); Serial.println("\nConnecting"); while(WiFi.status() != WL_CONNECTED){ Serial.print("."); delay(100); } Serial.println("\nConnected to the WiFi network"); Serial.print("Local ESP32 IP: "); Serial.println(WiFi.localIP()); }

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

void loop(){}

Or your phone hotspot SSID + pass

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

GETTING ON WIFI

  • Result 1:

==> picture [613 x 108] intentionally omitted <==

  • Result 2: Endless connecting loop (retry SSID/pass or another WiFi)

  • Result 3: Connection failed (retry)

  • Result 4: Gibberish (check baud rate).

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

REACTING TO ONLINE INPUT

  • Open the .ino file from Brightspace called ”ESP32_WifiWorkshopFinal” (unedited code can also be found via link, remember to change SSID credentials and baud).

  • Read through to understand what it does. It is a very basic HTTP-request ”ESP32 as web server”-setup, and is great for future prototyping!

  • Set up a breadboard with your ESP and two LEDs to pin 26 and 27 (remember a 220 ohm resistor to each + GND pin)

  • Use your computer/phone to control the pins (write the IP in the URL-field in a browser)

  • Optional - IoT Doorbell: Edit the code to work with a single buzzer instead of two LEDs – maybe even make a little melody?

DEPARTMENT OF COMPUTER SCIENCE

Idea and code from: https://randomnerdtutorials.com/esp32-web-server-arduino-ide/

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

==> picture [176 x 88] intentionally omitted <==

itPDP-2026-W3-design-EN.pdf Open PDF
Show converted presentation markdown

ITPDP2026- WEEK 3: DESIGN PROCESSES, PROJECT MANAGEMENT, AND DESIGN ETHICS

Clemens Nylandsted Klokmose Department of Computer Science Human-Centered Computing Section clemens@cs.au.dk

AARHUS UNIVERSITY

https://studypedia.au.dk/haandter-pensum/laesestrategier

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

2

AARHUS UNIVERSITY

PLAN

› Design processes

› Involving users

› Project management

› Design ethics

==> picture [222 x 222] intentionally omitted <==

› GDPR

==> picture [47 x 40] intentionally omitted <==

==> picture [222 x 146] intentionally omitted <==

----- Start of picture text -----
ITPDP 2026
----- End of picture text -----

AARHUS UNIVERSITY

PEOPLE AND PROTOTYPES

  • › Chapter in Moggridge (2006) describes IDEO's methods

  • › What is design? (Covered in FIT-DES)

  • › It is important to understand the needs and desires of users

  • › Observation and participation

  • › Often tacit and implicit knowledge that can only be uncovered experimentally

  • › Many versions of prototypes are needed (Later lecture)

  • › Prototypes are tangible and visible proposals

  • › User can "experience" a prototype and thus better evaluate proposed solutions

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

THE GOOD DESIGN?

  • Transparency and tacit knowledge (Polanyi, Bødker, and more)

  • › Fluid use without breakdowns

  • › Leverages the users' intuition* (that is uncovered experimentally)

  • › Scientific verification is often long and complex

Examples of assessment criteria for design projects:

  • The height of creativity/innovation

  • Aesthetics/quality

  • Whether human factors/values are taken into account

  • Performance and technology

  • Finish and presentation

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

THE GOOD DESIGN: AFFORDANCES (BILL GAVER)

› Perceptible possibilities (Gibson, 1979)

› We sense immediately

  • › That one can walk up a flight of stairs

› Sitting on a chair

› Tilting a door handle › Turning on faucet

  • › Computer user interfaces should be designed with equally clear affordances...

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

AFFORDANCES

==> picture [47 x 40] intentionally omitted <==

==> picture [190 x 279] intentionally omitted <==

==> picture [225 x 226] intentionally omitted <==

2026

ITPDP

7

AARHUS UNIVERSITY

Need to repair a design that does not ”afford" the right action possibilities to the user

==> picture [47 x 40] intentionally omitted <==

==> picture [504 x 378] intentionally omitted <==

----- Start of picture text -----
ITPDP 2026
----- End of picture text -----

DESIGN DISCIPLINES AND TECHNIQUES

How do we understand the problem area and the needs of users?

AARHUS UNIVERSITY

LIMITATIONS WITH INCREASING COMPLEXITY

› For a holistic understanding of groups, organizations, society and the globe

› From the facts of human proportions and physics

ITPDP 2026

AARHUS UNIVERSITY

ANALYSIS METHODS

==> picture [116 x 121] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

ITERATIVE DESIGN PROCESS

  • › Same type of activity is repeated to reduce uncertainty about the design

  • › Many cross-cutting jumps between activities

  • › From limitations to idea generation over prototyping less uncertainty back to remaining limitations

==> picture [47 x 40] intentionally omitted <==

==> picture [304 x 341] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

IDEO: 51 WAYS TO LEARN ABOUT USERS › IDEO Method cards

  • › 4 Categories

  • Learn – from facts that can be collected

  • Look – at what users do

  • Ask – about their contributions;

  • Try – out ideas

  • › The entire collection of 51 cards is available as a book/card box

› https://stoutbooks.com/products/ideo-method-cards-51-ways-to-inspire-design-61457

  • › In the chapter, only 4 examples from each category

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUSUNIVERSITY LEARN

› Analyze the information you’ve collected to identify patterns and insights.

› FLOW ANALYSIS

  • How Represent the flow of information or activity through all phases of a system or process.

  • Why This is useful for identifying bottlenecks and opportunities for functional alternatives.

  • Example Designing an online advice Web site, flow analysis helped the team to gain a clearer sense of how to make it easy to find your way around the site.

COGNITIVE TASK ANALYSIS

  • How List and summarize all of a user’s sensory inputs, decision points, and actions.

  • Why This is good for understanding users’ perceptual, attentional, and informational needs and for identifying bottlenecks where errors may occur.

  • Example Logging the commands that would be involved in controlling a remotely operated camera helped the team establish priorities among them.

› HISTORICAL ANALYSIS

  • How Compare features of an industry, organization, group, market segment or practice through various stages of development.

  • Why This method helps to identify trends and cycles of product use and customer behavior and to project those patterns into the future.

  • Example A historical view of chair design helped to define a common language and reference points for the team members from the client and consultancy.

AFFINITY DIAGRAMS

  • How Cluster design elements according to intuitive relationships, such as similarity, dependence, proximity, and so forth.

  • Why This method is a useful way to identify connections among issues and to reveal opportunities for innovation.

  • Example This affinity diagram shows what’s involved in transporting young children, and helps to identify the opportunities to improve the design of a stroller.

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUSUNIVERSITY LOOK

  • › Observe people to discover what they really do—not what they say they do.

› FLY ON THE WALL

  • How Observe and record behavior within its context, without interfering with people’s activities.

  • Why It is useful to see what people do in real contexts and time frames, rather than accept what they say they did after the fact.

  • Example By spending time in the operating room, the designers were able to observe and understand the information that the surgical team needed.

› A DAY IN THE LIFE

  • How Catalog the activities and contexts that users experience for an entire day.

  • Why This is a useful way to reveal unanticipated issues inherent in the routines and circumstances people experience daily.

  • Example For the design of a portable communication device, the design team followed people throughout the day, observing moments at which they would like to be able to access information.

SHADOWING

  • How Tag along with people to observe and understand their day-to-day routines, interactions, and contexts.

  • Why This is a valuable way to reveal design opportunities and show how a product might affect or complement user’s behavior.

  • Example The team accompanied truckers on their routes in order to understand how they might be affected by a device capable of detecting drowsiness.

PERSONAL INVENTORY

  • How Document the things that people identify as important to them as a way of cataloging evidence of their lifestyles.

  • Why This method is useful for revealing people’s activities, perceptions, and values as well as patterns among them.

  • Example For a project to design a handheld electronic device, people were asked to show the contents of their purses and briefcases and explain how they use the objects that they carry around everyday.

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUSUNIVERSITY ASK

› Enlist people’s participation to elicit information relevant to your project.

CONCEPTUAL LANDSCAPE

  • How Ask people to diagram, sketch, or map the aspects of abstract social and behavioral constructs or phenomena.

  • Why This is a helpful way to understand people’s mental models of the issues related to the design problem.

  • Example Designing an online university, the team illustrated the different motivations, activities, and values that prompt people to go back to school.

› COLLAGE

  • How Ask participants to build a collage from a provided collection of images and to explain the significance of the images and arrangements they choose.

  • Why This illustrates participants’ understanding and perceptions of issues and helps them verbalize complex or unimagined themes.

  • Example Participants were asked to create a collage around the theme of sustainability to help the team understand how new technologies might be applied to better support people’s perceptions.

› FOREIGN CORRESPONDENTS

  • How Request input from coworkers and contacts in other countries and conduct a crosscultural study to derive basic international design principles.

  • Why This is a good way to illustrate the varied cultural and environmental contexts in which the products are used.

  • Example A global survey about personal privacy helped to quickly compile images and anecdotes from the experiences of the correspondents.

CARD SORT

  • How On separate cards, name possible features, functions, or design attributes. Ask people to organize the cards spatially, in ways that make sense to them.

  • Why This helps to expose people’s mental models of a device or system. Their organization reveals expectations and priorities about the intended functions.

  • Example In a project to design a new digital phone service, a card-sorting exercise enabled potential users to influence the final menu structure and naming.

2026

ITPDP

AARHUSUNIVERSITY TRY

  • › Create simulations and prototypes to help empathize with people and to evaluate proposed designs.

› EMPATHY TOOLS

  • How Use tools like clouded glasses and weighted gloves to experience processes as though you yourself have the abilities of different users.

  • Why This is an easy way to prompt an empathic understanding for users with disabilities or special conditions.

  • Example Designers wore gloves to help them evaluate the suitability of cords and buttons for a home health monitor designed for people with reduced dexterity and tactile sensation.

SCENARIOS

  • How Illustrate a character-rich storyline describing the context of use for a product or service.

  • Why This process helps to communicate and test the essence of a design idea within its probable context of use. It is especially useful for the evaluation of service concepts.

  • Example Designing a community Web site, the team drew up scenarios to highlight the ways particular design ideas served different user needs.

› NEXT YEAR’S HEADLINES

  • How Invite employees to project their company into the future, identifying how they want to develop and sustain customer relations.

  • Why Based on customer-focused research, these predictions can help to define which design issues to pursue for development.

  • Example While designing an Intranet site for information technologists, the team prompted the client to define and clarify their business targets for immediate and future launches.

INFORMANCE

  • How Act out an “informative performance” scenario by role-playing insights or behaviors that you have witnessed or researched.

  • Why This is a good way to communicate an insight and build a shared understanding of a concept and its implications.

  • Example A performance about a story of mobile communications shows the distress of a frustrated user.

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

REMEMBER THE EXTREMES

› ”Extreme characters”

Example

  • › Extremes in IT design for the home

  • › The homeless living in a shopping cart

› The film actor with uniformly decorated apartments in New York, Paris, Tokyo and LA

==> picture [47 x 40] intentionally omitted <==

==> picture [344 x 273] intentionally omitted <==

2026

ITPDP

IDEATION

AARHUS UNIVERSITY

IDEO - IDEA GENERATION

  • › 8-10 participants – responsible for documentation appointed

  • › 50-100 ideas in an hour

  • › Rules

  • › No critical assessments

  • › Stimulate wild ideas

  • › Build on other people's ideas

  • › Stay focused on the topic

  • › Hold on to one "thread" at a time

  • › Really good ideas can stop the process and restart it somewhere new

  • › Ideas are taken over into an "envisionment" activity, where it is visible and tangible

2026

ITPDP

AARHUS UNIVERSITY

FUTURE WORKSHOPS

Critique phase

› Brainstorming problems in current practice

› No discussion – just get problems on the board › Group issues and prioritize importance

Fantasy phase

› Brainstorm wild/utopian ideas (that can solve the problems identified)

› No discussion – just get ideas on the board

› Group ideas and prioritize them in terms of value creation

Realization phase

› Take the high-priority ideas › Delimit to realistic visions

  • › Prepare concrete proposals for realization

==> picture [47 x 40] intentionally omitted <==

(Jungk & Müllert, 1987;Kensing & Halskov, 1991)

2026 21

ITPDP

THE ROLE OF THE DESIGNER & THOUGHTFUL INTERACTION DESIGN

Löwgren and Stolterman

AARHUS UNIVERSITY

LÖWGREN & STOLTERMAN

Places the designer at the core of the process

L&S argue that the responsibility for the vision at the designer (p.34ff)

L&S argue that the responsibility for the design process is at the designer (p.38ff)

L&S argue that the designer should engage and manage the relations in the design process (p.32ff).

==> picture [241 x 190] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

LÖWGREN & STOLTERMAN Designing the design process

› Design starts earlier than project owners may think

› Select appropriate methods/techniques

  • › Pay attention to and care for a common vision

  • › Pay attention to roles and stakeholders

==> picture [240 x 190] intentionally omitted <==

  • › Pay attention to design as a project

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

LÖWGREN & STOLTERMAN

Divergence

“Designer expands her thinking to cover broader issues, find alternatives, and explore more opportunities” (L&S, p. 29)

Convergence

“Convergence is about focusing on a specific solution or a synthesis of several ideas” (Ibid.)

  • What is the primary issue?

  • • Who to involve and how?

  • How would the shape look like?

  • • What is the interaction modality?

  • • What kind of feedback it give?

==> picture [79 x 76] intentionally omitted <==

Design choices

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

LÖWGREN & STOLTERMAN

  • Vision : The first organising principle that help the designer respond to the situation at hand

  • Operative Image : The first (and consecutive) externalisations of the vision

  • Specification : The final “design”

==> picture [214 x 202] intentionally omitted <==

  • specification

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

LÖWGREN & STOLTERMAN

› Leaping between detail and the whole

  • › Focusing on dilemmas in the domain

  • › Alternatives and contraditions

  • Get the dilemmas and

trade offs on the table early in the Vision activity

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

INVOLVING USERS

AARHUS UNIVERSITY

PERSPECTIVES ON PEOPLE AND MACHINES

People are Machines are
Machine-centered Vague
Unorganised
Unsystematic
Unfocused
Emotional
Illogical
Precise
Orderly
Focused
Logical
Human-centered Creative
Sensitive to situations
Oriented towards change
Has resources
Can make flexible decisions
Dumb
Rigid
Insensitive to change
Devoid of fantasy
Can only make limited and
deterministic decisions

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

USER INVOLVEMENT

  • None, very little, and/or only at the end

  • User-centred design

  • Participatory design

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

USER-CENTERED DESIGN

  • Involvement of users in all parts of the design process

  • Focus groups for ideation

  • Evaluation of low-fidelity prototypes

  • Evaluation of new features through AB testing and interviews

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

PARTICIPATORY DESIGN

  • More radical approach to user involvement than user-centred design

  • Users as direct design partners and active first-class members of the product design team

  • Developed in Scandinavia in the 70s and 80s (Aarhus University was a key player)

  • Methodology developed laid the foundation for user-centred design

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY UTOPIA PROJECT

Early participatory design project

  • Alliance between typesetters union and IT researchers

  • How to empower instead of replace typesetters with computers

  • Design of computer systems based on the people on the shop floor rather than the management

  • Introduced low-fi prototyping in systems design

==> picture [47 x 40] intentionally omitted <==

==> picture [220 x 99] intentionally omitted <==

==> picture [220 x 149] intentionally omitted <==

ITPDP 2026

Morten Kyng & Susanne Bødker

AARHUS UNIVERSITY

PARTICIPATORY DESIGN TECHNIQUES

  • › Ethnographic field studies

  • › Observations, interview and video analysis

› "Fictional inquiries”

  • › Playful analysis in a fictional setting

  • › Structured brainstorming

  • › Future Workshop, Metaphorical Design, Inspiration Cars, Organizational Games

  • › Scenarios

› Descriptions, tableau, video

› Mock-ups

  • › Physical models, paper windows

==> picture [155 x 114] intentionally omitted <==

==> picture [155 x 110] intentionally omitted <==

==> picture [155 x 100] intentionally omitted <==

› Video prototyping

› Stop-motion, blue studio techniques

  • › Prototyping

  • › Exploratory, experimental, evolutionary, cooperative

==> picture [23 x 8] intentionally omitted <==

----- Start of picture text -----
2026
----- End of picture text -----

ITPDP

AARHUS UNIVERSITY

INTERNATIONAL BOOKS AND ARTICLES ON SCANDINAVIAN PARTICIPATORY DESIGN

  • › Bødker, S., Grønbæk, K., & Kyng, M. (1995). Cooperative Design: Techniques and Experiences from the Scandinavian Scene. In R. M. Baecker, J. Grudin, & W. A. S. Buxton (Eds.), Readings in Human-Computer Interaction: Toward the Year 2000 . San Francisco: Morgan Kaufmann Publishers, Inc., 215-224.

  • › G. Bjerknes, P. Ehn, & M. Kyng (Eds.) (1987) Computers and Democracy . Aldershot: Avebury. › Greenbaum, J., & Kyng, M. (1991). Design at Work: Cooperative Design of Computer Systems . Hillsdale, NJ: Lawrence Erlbaum Associates.

  • › D. Schuler & A. Namioka (Eds.) (1993) Participatory Design: Principles and Practices . Hillsdale, New Jersey: Lawrence Erlbaum Associates, 157-175.

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

==> picture [471 x 266] intentionally omitted <==

==> picture [214 x 282] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

36

AARHUS

UNIVERSITY

==> picture [47 x 40] intentionally omitted <==

ITPDP

2026

37

PROJECT MANAGEMENT

AARHUS UNIVERSITY

UNCERTAINTY ABOUT THE PRODUCT SHOULD BE REDUCED

==> picture [449 x 178] intentionally omitted <==

----- Start of picture text -----
Now Deadline Exam
----- End of picture text -----

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

PROJECT MANAGEMENT: SYSTEMATIC APPROACH

==> picture [14 x 6] intentionally omitted <==

----- Start of picture text -----
Now
----- End of picture text -----

==> picture [113 x 6] intentionally omitted <==

----- Start of picture text -----
Deadline Exam
----- End of picture text -----

==> picture [465 x 39] intentionally omitted <==

==> picture [436 x 77] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

PROJECT MANAGEMENT

Project management

› Focus on the project, starting point, purpose, budget etc.

› Focus on deadlines, deliveries, quality etc.

› Focus on progress, evaluation, success/failure Leadership

› Focus on competencies and roles

› Focus on performance and well-being

  • › Focus on the team over time (and more projects)

  • Self-management

  • › Focus on your own tasks, satisfaction, prioritization, progression!

2026

ITPDP

AARHUS UNIVERSITY

PITFALLS

› Technical Rationality (Gedenryd 1998)

› Believe that you can follow a linear process

  • › Optimistic estimation (Brooks 1975)

› Software is highly malleable compared to other materials

  • › Brooks Law (Brooks 1975)

  • › Believe that you can finish faster by putting more people on a project

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY ILLUSION OF TECHNICAL RATIONALITY

• Most straightforward model of a project • Most projects to some degree or the other follows this model • Pitfall • Paralysis by fear of wrong requirements can halt the process • Mistakes are expensive too fix late in the process

==> picture [47 x 40] intentionally omitted <==

Schön 1987; Gedenryd 1998

2026

ITPDP

AARHUS UNIVERSITY

AGILE INTERACTION DESIGN / AGILE DEVELOPMENT

  • Break design process down in small iterations each involving all phases

  • Iteratively develop software in working (and deployable) increments

  • The software is never finished (for good … and for ill)

  • Affords extensible software architectures that enables rapid prototyping of new features

==> picture [47 x 40] intentionally omitted <==

==> picture [520 x 146] intentionally omitted <==

----- Start of picture text -----
ITPDP
----- End of picture text -----

2026

AARHUS UNIVERSITY

MAKE A GOOD PLAN WITH ROOM FOR ERRORS AND ITERATIONS

==> picture [14 x 6] intentionally omitted <==

----- Start of picture text -----
Now
----- End of picture text -----

==> picture [113 x 6] intentionally omitted <==

----- Start of picture text -----
Deadline Exam
----- End of picture text -----

==> picture [465 x 39] intentionally omitted <==

==> picture [436 x 77] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

ETHICS

AARHUS UNIVERSITY

WHY DO WE EVEN TALK ABOUT ETHICS

› We build things

› … that affects people’s lives

  • › … potentially a lot of people

  • › ... that change their perspectives on things

  • › … even their possibilities of action, self-understanding and daily life

==> picture [145 x 217] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

UNETHICAL TECHNOLOGY?

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

AARHUS UNIVERSITY

UNETHICAL TECHNOLOGY?

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

52

AARHUS UNIVERSITY

THREE SCHOOLS OF ETHICS

› Consequentialism (da: nytteetik )

› Cares for consequences: “The truth can hurt”

› Deontology (da: pligtetik )

  • › Cares for rules: “You must not lie”

› Virtue ethics (da: dydsetik )

› Cares for principles: “I always tell the truth”

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

ETHICS

Verbeek’s Materializing Morality

AARHUS UNIVERSITY

VEERBEEK’S CLAIM

› ‘If technology mediates how we perceive and act in the world, it can also be designed to mediate perception and action in ethical or unethical ways.’

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

55

AARHUS UNIVERSITY

MEDIATION OF PERCEPTION

  • Simple : Me -> World

Mediated : Me -> Technology -> World

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

56

AARHUS UNIVERSITY

==> picture [279 x 241] intentionally omitted <==

==> picture [314 x 241] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

57

AARHUS UNIVERSITY

MEDIATION OF ACTION

  • Inscription

› ‘The designer, who can be seen as the inscriber of scripts.’ › When we design

  • Scripts

› The influence of artifacts on human actions is a “script”

› Typical patterns of action

  • Translation

  • › To new (or less) action possibilities (e.g., citizen+gun)

› Typical(/possible) outcomes

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

58

AARHUS UNIVERSITY

MEDIATION OF ACTION - EXAMPLES

==> picture [47 x 40] intentionally omitted <==

==> picture [216 x 295] intentionally omitted <==

2026

ITPDP

59

AARHUS UNIVERSITY

MEDIATION OF ACTION - EXAMPLES

==> picture [612 x 156] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

60

ETHICS

Dark Patterns

AARHUS UNIVERSITY

DARK PATTERNS

  • › Basic assumption that UX features can be linked to similar user behavior

  • › (Dark) patterns as a way to describe design → ‘scripts’ (cf Verbeek)

  • › Pattern use suggests a causal relationship between intention → feature → behavior

  • › Gray et al paper

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

62

AARHUS UNIVERSITY

DARK PATTERNS

==> picture [660 x 160] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

63

AARHUS UNIVERSITY

DARK PATTERNS

==> picture [331 x 261] intentionally omitted <==

==> picture [234 x 175] intentionally omitted <==

==> picture [276 x 129] intentionally omitted <==

2026

ITPDP

64

AARHUS UNIVERSITY

DARK PATTERNS & SOCIAL MUSIC THEME?

==> picture [306 x 305] intentionally omitted <==

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

65

GDPR

AARHUS UNIVERSITY

GDPR

  • › General Data Protection Regulation is an EU regulation aimed at strengthening and harmonising the protection of personal data in the European Union.

  • › Must protect the individual's rights and processing of personal data – consent, security, the right of access and the right to be forgotten, etc.

  • › It is something we must relate to when we involve others than ourselves in the design

  • process

  • › Until now, you have mostly been the 'data subject' – now you will potentially also be data responsible!

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

67

AARHUS UNIVERSITY

GDPR RULES

  • › Consent must be clearly obtained independently of other requests.

› Consent must be obtained with clear information about scope, purpose, responsibility and contact persons

  • › In case of security breach, participants must be informed no later than 72 hours after discovery

  • › The right to be forgotten must be implemented as a procedure in the process

  • › A responsibility to be taken seriously ( but no need for further concern )

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

68

AARHUS UNIVERSITY

GDPR IN STUDENT PROJECTS

  • › https://studerende.au.dk/en/it-support/information-security/data-protectiongdpr/projects

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

69

AARHUS UNIVERSITY

DOCUMENTS

  • Consent statement is used to obtain consent from participants – customize template as needed

  • The register of purposes is used to explain the purpose of the data collection

  • Data responsibility is used, as a group, to enter into an internal agreement on joint data responsibility

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

70

AARHUS UNIVERSITY

DOCUMENTS

You are responsible for the preparation of the documents

You are responsible for storing the documents

You are responsible for the storage of data and GDPR

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

71

AARHUS UNIVERSITY

TIPS

  • › Just get it done and learn that it is part of the study and our practice

  • › Don't collect data you don't know what you need for (sensor data?)

  • › Try to anonymize and 'get away from' data as early as possible (Clemens → Respondent M1)

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

72

AARHUS UNIVERSITY

WHAT CAN WE HELP WITH?

› Read through the documents when they are finished (to help)

› Answer questions

› Not so much more – it's agreements and your responsibility

TA session where you’ll look at it!

==> picture [47 x 40] intentionally omitted <==

2026

ITPDP

73