Design for the human loop

Task. Find a good and bad everyday design and argue using course concepts.

Solution

Good: a kettle with a handle-shaped grip, MAX line, one distinct switch, and illuminated state. The handle and switch signify actions; water scale constrains fill; light provides feedback; the model “switch closes heater until boil” predicts behavior.

Bad: a glass door with identical vertical bars on both sides. Bars signify pulling even on the push side, so stage 3 selects the wrong action. Add a flat push plate on the push side, a graspable handle only on pull, and visible PUSH/PULL labels.

Selected object: four identical stove knobs in a horizontal row controlling a 2×2 burner layout.

1. Why poor: arbitrary mapping forces recall; no immediate burner-state feedback at the control; identical knobs weaken selection.
2. Improvement: arrange controls in a 2×2 spatial map, place a status light beside each burner, use an off detent and heat scale.
3. Verification: ask five first-time users to activate a named burner; record wrong-burner selections and time.

Selected software: a photo app whose Delete icon immediately removes an image with no confirmation or undo.

1. Goal: remove one bad photo.
2. Intention: delete the currently selected photo.
3. Specify: choose trash icon; ambiguity if selection is unclear.
4. Execute: tap; target may be too small.
5. Perceive: image disappears, but no message.
6. Interpret: unclear whether deleted, archived, or hidden.
7. Compare: cannot know whether the intended file alone was removed.

Redesign: visible selection count, descriptive action “Delete 1 photo,” reversible trash/Undo snackbar, and persistent state feedback.

Requirements: search by specialty/name/availability/reviews; choose a free slot; day/week/month calendar.

Annotations. Proximity binds each doctor to rating/action; common region creates the doctor card; similarity makes all filter chips behave alike; contrast marks the selected slot; alignment supports scanning. The labeled buttons are signifiers, unavailable slots are disabled constraints, and confirmation supplies feedback.

Setup (a–c). System: rail-booking app. Task: book Berlin→Rome, 15 May, for one adult with one change maximum. Participant completes without coaching; observer records time/errors, then raw TLX: MD 70, PD 5, TD 65, Performance 40, Effort 75, Frustration 60.

Evaluation (a). Mean=(70+5+65+40+75+60)/6=315/6=52.5. Highest: effort 75, mental 70, temporal 65.

(b). Physical demand is negligible; the workload is cognitive/time-related, consistent with comparing many fares and constraints.

(c). Persist filter state, show change count and total travel time together, and compare fares in aligned rows.

Bonus (a). Useful for aviation, healthcare, driving, complex monitoring, and comparing prototypes after standardized tasks. (b). Self-report/recall bias, contextual scores, endpoint ambiguity, and no causal diagnosis.

Chosen topic: programming-language prevalence. Data assumption: a tidy table of yearly percentages from one consistently sampled survey; because no dataset is supplied, values below are illustrative: Python 30→45%, JavaScript 40→42%, Java 35→25% from 2020→2025.

1. Position on a common y-scale encodes ratio values.
2. Direct labels remove legend lookup.
3. Distinct line styles preserve grayscale access.
4. Zero baseline and units prevent exaggeration.
5. Title must name population/survey; annotations flag method changes.

User stories (5). As a student, I want today’s room changes so I avoid the wrong room; imminent deadlines so I can prioritize; next timetable item and travel time; unread instructor announcements; and current cafeteria/library status.

Design reasoning. Safety/time-critical change receives SEEV value+salience; common region groups time blocks; proximity binds labels/values; contrast is reserved for exception state; normal states stay quiet.

Chosen domain: healthcare analysis. Overview: occupancy, waiting time, critical bed shortage, medication availability, patient flow. The default shows current state and 24-hour trend; selecting a ward reveals detail.

• Directly label values and units; show update time/source.
• Use aligned small multiples for wards instead of 3D charts.
• Reserve red for actionable threshold breaches, not branding.
• Show denominator and confidence/coverage for outcomes.
• Do not follow the prompt’s “more detail” literally when it harms monitoring; provide detail on demand.

1. Stakeholders

Students (timely personal schedule/navigation); lecturers (accurate changes); registrar (authoritative course data); facilities (room/map data); library/cafeteria staff (service status); IT/privacy staff (reliability, security, compliance).

2. Functional requirements

1. The system must show a student’s lecture schedule and changes.
2. The system must route from current/selected location to a room.
3. The system must show library availability/opening hours, cafeteria menu, and opt-in push notifications.

3. Non-functional usability requirements

1. 95% of first-time students find the next room without help.
2. Median next-lecture lookup ≤5 s on a 390 px phone.
3. Schedule changes are visually distinguishable without color alone.
4. All functions support keyboard/screen-reader operation.
5. A notification links to the changed event and supports undo of dismissal.

4. Use case: View lecture schedule

Chosen option 1: alarm-clock app. Users: shift worker, student, hearing-impaired sleeper. Goals: set a trustworthy alarm quickly, distinguish weekday/weekend, recover after missed/dismissed alarms. Context: dark room, sleepy, one-handed, phone muted/offline.

Functional: create/edit/repeat alarm; preview sound/vibration; snooze/dismiss; show next trigger. Quality: next trigger visible within 1 s; set a one-off alarm within 20 s; controls meet touch-size/accessibility; alarm survives app closure; destructive “delete all” reversible.

Risk: 12-hour ambiguity and silent-volume state. Mitigate with absolute next-trigger text (“Tomorrow, 07:30 · 8 h 12 min”) and preflight warning.

Persona: Mina, 24, rotating nursing shifts; goal is a dependable alarm after variable sleep; often configures one-handed in low light; constraint: cannot risk an inaudible alarm.

Context scenario: After an evening shift Mina learns tomorrow starts at 06:30. On the bus she schedules a 05:15 alarm for one day, checks that vibration and volume are adequate, then later verifies the next trigger from the lock screen.

Key-path scenario: Open → Add → time 05:15 → One time → label Early shift → preview → Save → confirmation “Tomorrow 05:15.”

Prototype: clickable mid-fidelity phone prototype. It is sufficient to test flow, labels, visibility, and error recovery; actual background alarm reliability is simulated and cannot be concluded.

Evaluated app: the alarm prototype above.

CW trace: goal “weekday alarm” is plausible; Add is visible; time field maps to goal; Repeat is initially ambiguous; confirmation after Save is insufficient.

Domain 1: Further Education

Scenario: a working engineer wants the next part-time AI certificate, admission requirements, schedule, price, and application route. Tasks: find an eligible offering; compare two; locate application deadline; begin application.

Domain 2: Business

Scenario: an SME manager wants a university collaboration contact and funding/technology-transfer information. Tasks: find collaboration options; identify the right contact; locate one relevant project/service.

Test plan and justification

Five participants per domain matching role, moderated remote or in-person, one at a time. Metrics: completion, critical errors, time, confidence, and observed breakdowns. Think aloud, neutral prompts, no coaching. Consent and no sensitive form submission. Counterbalance task order; use the same browser/device class.

Example report

Illustrative finding: 3/5 further-education users confuse degree study with short courses; 4/5 business users search for “cooperation” but navigation says “Transfer.” Severity 3. Fix labels/landing-page signposts; retest.

Missing input. The referenced iLearn files are not in the course folder. To solve every requested operation without inventing course results, use this labeled illustrative dataset.

1–2. Mapping and preprocessing

Check missing values, permitted ranges, item polarity, participant IDs, and version. SUS contributions must be 0–4; reverse negative AttrakDiff items before dimension means.

3. Overall/dimensional scores

4. Descriptive measures and boxplots

Sample standard deviation uses $s=\sqrt{\frac{\sum {(x_i-\overline{x})}^2}{n-1}}$. Results: SUS s≈6.75; PSSUQ s≈0.30; pragmatic s≈0.27; hedonic s≈0.26. A boxplot shows median, quartiles, whiskers, and outliers; preserve the instrument direction in labels.

Usability is specified users achieving specified goals effectively, efficiently, and satisfactorily in a specified context. The three phases are analysis → design → evaluation, repeated iteratively.

1. Rule-based / mainly System 1: nurse follows displayed dosage instructions, a known rule/procedure; deliberate verification may engage System 2.
2. Knowledge-based / System 2: novel erratic machine requires hypotheses.
3. Skill-based / System 1: practiced cruise-control routine is automatic.
4. Skill-based / System 1: routine Linux status commands are fluent learned sequences; if command choice required a runbook diagnosis, it would be rule-based.

1. No visual response after Post: missing feedback / visibility of system status.
2. Plain tappable tasks: missing signifiers (poor discoverability).
3. Unlabeled minimalist + upload button: ambiguous/weak signifier; the perceived affordance does not communicate upload.

1. Parallel feature extraction—red color pops out.
2. Pattern/structure organization—red circle and number are grouped as a badge.
3. Sequential goal-directed interpretation—the badge is read as “three unread messages.”

1. Salience: loud alarm + blinking red is perceptually conspicuous.
2. Effort: value is on the main screen, so access/eye movement effort is low.
3. Value: reactor temperature is safety-critical despite weak salience.
4. Expectancy: repeated 08:00 calibration is temporally expected.

Two dimensions: mental demand = cognitive processing required; effort = how hard the participant worked to reach performance. Context: after a standardized task when comparing workload across systems/prototypes, especially complex monitoring, driving, healthcare, or aviation. Two limitations: retrospective self-report/response bias; dimension scores do not identify which interface feature caused workload. Context and scale-direction differences also limit comparison.

Gestalt: common region groups each tour; proximity binds facts; similarity makes cards/buttons predictable. Other principles: labeled buttons signify actions, aligned fields give mapping, disabled full sessions constrain, booking confirmation gives feedback, cards support a tour conceptual model.

(a) Context scenario

After work, Lea—an experienced backend engineer seeking a remote role—has ten minutes on the train. She wants a small set of relevant openings without re-entering her skills. She reviews why each match was suggested, dismisses an irrelevant seniority/location, saves two roles, and expects future recommendations to reflect that feedback. She avoids applying until home because her connection is unreliable.

(b) Two user stories

1. As a job seeker, I want each recommendation to show matched/missing criteria so that I can judge relevance.
2. As a job seeker, I want to dismiss a role with a reason so that future recommendations improve.

1. Clock, pencils, hand, and fragments are decorative ink unrelated to a common quantitative scale.
2. Irregular wedges use angle/area/perspective, so 70%, 67%, etc. cannot be compared accurately.
3. Scattered labels, many colors, overlap, and no ordered baseline create visual search and imply parts of a whole even though percentages need not sum to 100.

• Contrast: red Search/price badge and dark text create action/hierarchy.
• Repetition: navigation typography and form-control styles repeat.
• Alignment: origin, destination, swap, and Search share a row/grid.
• Proximity: date, return, passenger, and class controls are grouped below the connection fields; offer copy sits in one card.

The designer’s conceptual model is the intended structure/operation. The user’s conceptual model is what the person believes. They interact only through the system image—visible UI, behavior, labels, feedback, documentation. If that image faithfully expresses the design, the user’s model predicts outcomes; if not, errors follow.

1. Test early and on a regular schedule.
2. Recruit sufficiently representative people without blocking progress.
3. Observe realistic tasks one participant at a time; do not coach.
4. Make observation shared, identify a few critical issues, fix the minimum effective change, and retest.

Improve 1: remove 3D/shadows; they add chart junk and distort length. Improve 2: one hue is enough; labels already identify food, so rainbow colors/legend are redundant—highlight Pizza alone if it is the query. Improve 3: sort bars or isolate the queried food and directly label “300 kcal per 100 g”; shorten axes (“Calories, kcal/100 g”) and remove heavy borders. Good: bar baseline begins at zero and the quantitative unit/food categories are present, enabling length comparison.

Type: directional alternative hypothesis. IV: interface modality, voice vs text (nominal). DV: task completion. Operationalize as proportion of assigned smart-home tasks completed correctly (ratio, 0–1 or 0–100%) and optionally time in seconds for successful trials (ratio). Hold tasks, device, environment, and experience constant or counterbalance.

Visibility of system status: timely feedback keeps users informed; use it to flag a missing upload/progress confirmation. Error prevention: remove dangerous conditions or check before commitment; use it to disable illegal filenames and add reversible deletion. During HE, evaluators independently inspect screens/tasks, record concrete violations, assign severity, consolidate, then redesign and validate.

(a) Calculation

Marked responses: 4,2,5,3,4,2,4,2,3,1. Odd contributions (x−1): 3+4+3+3+2=15. Even contributions (5−x): 3+2+3+3+4=15. Sum=30; SUS=30×2.5=75.

(b) Interpretation

On the supplied curve, 75 lies around the upper-middle range (roughly the 70th percentile) and in grade B. It indicates above-average perceived usability, not “75% usable,” and does not prove absence of critical task failures.

Analyze users, goals, tasks, and context → derive testable requirements → design/prototype → evaluate with inspection/users/measures → feed findings into the next analysis/design cycle until acceptance criteria and risk are satisfied.

1. Rule/System 1: known reset procedure for familiar error.
2. Skill/System 1: practiced login sequence; selecting/recovering credentials could become rule/knowledge behavior.
3. Knowledge/System 2: developing reusable prompts requires exploration and reasoning (after routinization it may become rule-based).
4. Knowledge/System 2: unknown crash requires diagnosis.

1. Flat decorative-looking touchscreen: missing signifier/discoverability.
2. Left button opens right window: poor mapping.
3. Unhinted swipe: missing signifier.
4. Illegal filename characters accepted: missing logical constraint/error prevention.

1. Extract primitive color/edge/orientation features in parallel.
2. Group them into the icon’s shapes/object using similarity, closure, figure–ground.
3. Attend and interpret the icon’s learned meaning in the current task.

1. Effort: small icon + long popup increases access/reading cost.
2. Salience: bright yellow draws bottom-up attention.
3. Expectancy: experience predicts jargon errors, guiding checking.
4. Value: SEO headline may substantially improve readership.

SUS: quick 10-item alternating questionnaire, transformed to a global 0–100 perceived-usability score suitable for comparisons/benchmarks. AttrakDiff: semantic-differential pairs measuring pragmatic quality, hedonic quality (identity/stimulation), and attractiveness; it captures experience beyond task usability. Both efficiently standardize subjective feedback but remain self-report and must be interpreted with context/sample.

Gestalt: proximity/common region per session; similarity for filter chips/cards. Interaction: button labels signify; selected filters give feedback; full status constrains; filter layout maps to requested attributes; card model matches a session.

(a) Context scenario

During a noisy night shift, operator Sam monitors two production lines. The inspector detects a high-confidence crack and shows the affected camera, part ID, severity, and image region. Sam pauses the line, compares the live part, confirms the defect, and routes it to rework; uncertain detections enter review without stopping production.

(b) Stories

1. As a line operator, I want critical defects ranked with part/camera evidence so I can stop the correct line quickly.
2. As a quality engineer, I want confirmed/overridden detections logged with reasons so I can audit and improve the model.

1. Overlapping translucent 3D mountain areas cause occlusion and perspective distortion.
2. No shared readable baseline/axis; triangle height/area does not support exact comparison.
3. Seven saturated hues, leader lines, icons, and two measures produce visual clutter and difficult lookup.

• Contrast: large white headline and blue Search button stand out on dark background.
• Repetition: news tiles repeat date/category/title style.
• Alignment: navigation, news columns, headline, and search controls sit on shared grids.
• Proximity: each story’s metadata/title are grouped; search topic/input/button form one unit.

Execution gulf: gap between goal and knowing/performing an available action. Example: user wants to share but cannot find whether the unlabeled arrow means Share. Evaluation gulf: gap between system state and perceiving/interpreting whether the goal was achieved. Example: after upload, no progress or confirmation appears. Signifiers/mapping bridge execution; feedback/conceptual model bridge evaluation.

HE: several evaluators independently compare the interface with broad heuristics, record violations/severity, consolidate. CW: analysts walk a specified novice through a task and ask at each step whether the right goal/action/association/feedback will be formed. HE finds broad consistency/status/error issues; CW finds step-specific learnability failures. Neither replaces user testing.

Improve 1: identify user/decision and remove unrelated stocks/news/map placeholders; the dashboard mixes incompatible goals. Improve 2: enlarge critical transport/air-quality exceptions and reduce tiny text; use salience only for actionable states. Improve 3: add consistent units, timestamps, thresholds, and trend context; align comparable metrics and reduce cyan boxes. Good: it is a single-screen overview with modular grouping and visible city/time context.

Type: directional alternative. IV: assessment method, AI versus dermatologist (nominal). DV: diagnostic accuracy. Measure correct classifications / cases against histopathology/reference standard (ratio proportion, 0–1); also report sensitivity/specificity because class imbalance can hide harm. Use the same blinded cases; account for repeated measures and dermatologist/model versions.

1. Suitability for the user’s tasks
2. Self-descriptiveness
3. Conformity with user expectations
4. Learnability
5. Controllability
6. Use error robustness
7. User engagement

Each asks whether the dialogue supports goal work, makes itself understandable, behaves as expected, teaches, remains under user control, handles error, and appropriately engages.

A mean: (55+15+70+70+55+45)/6=51.67. B mean: (60+20+50+70+55+50)/6=50.83. B reduces temporal demand by 20 points but increases mental and physical demand by 5 and frustration by 5; performance and effort are equal.

If forced, prefer B for marginally lower raw mean and much lower temporal pressure. But the 0.84-point overall difference is negligible without participant variance/significance, and safety/accessibility may make dimensional tradeoffs decisive.