Chapter 25 — Design studio I | Engineering Human factors and cyber policy

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 25 — Design studio I

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 The studio brief"]
  N2["25.2 Studio critique"]
  N3["25.3 Iterating"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 The studio brief"]
  N2["25.2 Studio critique"]
  N3["25.3 Iterating"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The studio brief]
    |
    v
[25.2 Studio critique]
    |
    v
[25.3 Iterating]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) design a reporting and feedback service in a team; (2) critique designs in a studio setting; (3) iterate based on feedback.

25.1 The studio brief

Prof. Kerr runs a design studio. Aiko's team of four must design a reporting and feedback service for a fictional regional transport operator with drivers, depot staff and office teams. Requirements include one-tap reporting, fast feedback and no individual blame. The team includes a computer science student, a psychology student and a design student. Working across disciplines brings different ideas: the psychology student suggests framing reports as helping colleagues rather than as security duty. The team agrees roles and a schedule in the first meeting, with each member leading one part of the design.

25.2 Studio critique

In the midpoint critique, other teams and two practitioners review the designs. A practitioner points out that drivers cannot use phones while driving, so reporting must also work from depot terminals and by a simple phone call to a hotline. Another reviewer questions whether the monthly summary will be read. Aiko's team listens without defending and records each comment. Critique works when designers treat it as information rather than as attack. They sort the comments into must-fix and could-improve groups before the next session, and agree who will address each one.

25.3 Iterating

The team revises. They add depot terminal reporting and a hotline, shorten the monthly summary to three items with a picture, and test the new framing with five depot staff, who prefer it. They document what changed and why. At the final critique, practitioners note the design now fits drivers' working day. Aiko learns that iteration based on real constraints produces designs people actually use. They also keep a short change log listing every revision, the comment that prompted it and the result of the small test with depot staff, which the final reviewers use to see how the design evolved.

Worked example

Aiko's team designs a reporting service for a transport operator, takes studio critique about drivers and iterates with terminals, a hotline and a shorter summary.

Synthetic case. The transport operator and team are synthetic.

Errors and limits

Studio projects lack real deployment pressures. Small tests may favour novelty.

Exercises

EX073 — Psychology framing. What framing did the psychology student suggest? Rubric: 3 = reporting as helping colleagues;; 2 = helping;; 1 = duty;; 0 = none.
EX074 — Driver constraint. What constraint did the practitioner raise? Rubric: 3 = drivers cannot use phones while driving;; 2 = driving;; 1 = vague;; 0 = none.
EX075 — Design changes. Name two changes after critique. Rubric: 3 = depot terminal reporting, hotline, shorter summary;; 2 = two;; 1 = vague;; 0 = none.

Synthesis

Studio critique from people who know real constraints drives designs that fit actual work.

Continue studying — chapter 25 of 50

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →