A Physical Computing Studio Brief That Actually Works: A Template for Industrial Design Instructors

A complete, pressure-tested studio brief for teaching physical computing to second-year industrial design students, with weekly structure, deliverables, assessment guidance and adaptation notes.

Every ID department has had the same conversation. Someone at a faculty meeting says "we should really be teaching physical computing in the second-year studio." Heads nod. A pilot gets penciled in for next semester. Next semester arrives and the pilot quietly becomes the semester after that, because nobody has time to write the brief.

The brief is the bottleneck. Not the budget, not the hardware, not the students. It is the twelve-page document that has to balance design rigor with realistic technical scope, predict where students will get stuck, lay out deliverables that can actually be assessed and survive the specific chaos of your program. Writing one from scratch takes forty hours of thinking you do not have.

So here is one you can take. It is the brief most instructors wish someone had handed them the first time they ran an interactive product studio. It is opinionated, it will not fit every program perfectly and it is designed to be modified. Everything in it has been pressure-tested in real studios with real students who had never touched a microcontroller before.

The commentary in the margins of this post explains why each section is written the way it is, so you can make informed decisions when you change things.

The brief

Course: Interactive Product Studio (second-year ID) Duration: 6 weeks (of a 15-week semester) Cohort size: 12 to 20 students Prerequisites: one previous studio, basic CAD, no programming experience assumed

Overview

Design and build a small interactive object that responds to a single human action through a single sensed input. The object should demonstrate a deliberate relationship between form, material and behavior. It must work as a physical prototype during a final critique and be documented as a portfolio-ready artifact.

This is not a course in electronics. It is a course in designing objects that behave. The electronics are the means. The behavior is the subject.

Margin note. That second paragraph is the single most important sentence in the brief. Read it aloud on day one. Read it again in week three. Every time a student starts optimizing their C++ code instead of their form, point at this paragraph. It reframes the whole course and it protects design students from turning into bad engineers.

Learning outcomes

By the end of this studio a student should be able to:

1. Translate a human action into a sensor choice and justify that choice.
2. Design physical form that accommodates real components (PCBs, batteries, cables) without hiding them apologetically.
3. Build a working single-sensor, single-output prototype that is stable enough to survive a critique.
4. Document the interaction as a short video and a written rationale that explains what the object is for and why it exists.
5. Reflect on the gap between the intended behavior and the observed behavior.

Margin note. Five outcomes is the ceiling. Briefs with eleven outcomes mean eleven rubric items, which means six hours of grading per student. You do not have that. Pick five that matter and let the rest be implicit.

The constraint set

Every student works within the following constraints:

• One input: one sensor. Not two, not a sensor plus a button, not "a sensor and also a timer." One.
• One output: one way the object responds. Light, sound, motion or haptic. Pick one.
• One microcontroller: the studio will use the Seeed XIAO ESP32-S3 for everyone. No exceptions in week one. Exceptions allowed in week four if justified.
• Power: the object must run for at least five minutes untethered. USB power banks are the expected solution.
• Size: the object must fit inside a 150mm cube. Larger objects become logistical disasters.
• No screens: no LCDs, no e-paper, no phones. If information needs to be communicated, it must be communicated through the physical object itself.

Margin note. The "one input, one output" constraint is the most unpopular rule in this brief and the most important. Students will beg to add a second sensor. Do not let them. Every second sensor doubles the debugging surface and halves the attention paid to form. Students who follow the constraint finish the project. Students who break it finish seventy percent of two projects.

Margin note on the no-screens rule. Screens are how design students escape from the hard problem. As soon as a screen is allowed, the object becomes a small tablet in a nice enclosure and the studio becomes an exercise in interface design. That is a different course. This one is about objects that behave without pretending to be computers.

Weekly structure

Week 1: Action and sensing Students pick a human action (exhaling, leaning, placing, touching, approaching, grasping) and research which sensor families can detect it. Deliverable: a short written case with three candidate sensors and a recommendation. No building yet.

Week 2: Sensor behavior studies Each student gets a XIAO and their chosen sensor. The only deliverable is a thirty-second video of the sensor producing data in response to the action, with a short written reflection on what surprised them. This is not a form exercise yet. Form is explicitly forbidden this week.

Week 3: Output and mapping Students decide how the sensor data becomes an output. This is where the design thinking lives: what does the object do when the human does the thing? Mapping is the hardest intellectual work in the course. Deliverable: three mapping sketches (rough wireframes of behavior over time) and one chosen direction.

Week 4: Form and integration CAD work begins. The sensor, the board, the battery and the output element are all positioned inside a physical envelope. Draft prints start. Electronics move from breadboard to perfboard or soldered protoboard. Deliverable: a draft printed enclosure with everything physically fitting inside, even if the cables are ugly.

Week 5: Refinement and failure The object should work in week 5. It will not. This is the week students discover that wires come loose, batteries die mid-demo and their mapping feels wrong when experienced in real time. The deliverable is a written list of five things that broke and how they were fixed. This list is graded.

Week 6: Critique and documentation Final critique. Each student brings the working object, a ninety-second demo video shot the day before and a two-page written rationale. Twenty-minute crit slots.

Margin note on the week 5 "list of five things that broke." This is the most valuable deliverable in the whole course and the one that will feel weirdest the first time you assign it. You are literally grading students on their ability to identify and document failure. Students who cannot list five failures either did not build enough or did not pay attention. Both are problems worth surfacing.

Required deliverables for the final crit

1. The physical object, working.
2. A ninety-second demo video, filmed in daylight or good artificial light, showing the interaction from start to finish with no narration.
3. A two-page PDF rationale: one page on the human action and why it matters, one page on the design decisions (form, material, mapping).
4. A parts list and a simple block diagram (sensor to microcontroller to output).
5. The week 5 failure list.

That is it. No long presentations. No slide decks. No "process books" unless your program requires them at the department level.

Margin note. Long process books in interactive studios tend to become a separate deliverable that eats a week of studio time and mostly contains screenshots. If your program mandates one, push back. If you cannot push back, make it count as a separate assignment in a separate course.

Assessment

Grading is based on the five-dimension rubric in the companion post How to Grade a Physical Computing Project Without Becoming an Engineer. The five dimensions are concept, interaction, form and function integration, craft and documentation. Code quality is explicitly not graded.

Parts kit

Each student receives the same base kit on day one:

• 1 x Seeed XIAO ESP32-S3
• 1 x USB-C cable (1m)
• 1 x breadboard (half-size)
• 20 x jumper wires
• 1 x 10000 mAh USB-C power bank
• Perfboard, header pins, hookup wire
• Solder, flux, shrink tubing

Students pick their sensor from a shared cabinet in week 1. The cabinet contains roughly 30 units each of: VL53L0X ToF, MPU-6050 IMU, MPR121 capacitive touch, INMP441 mic, HC-SR501 PIR, BME280, HX711 with load cell, MAX30102 pulse, APDS-9960 gesture and a small pile of force-sensitive resistors.

Students pick their output element in week 3 from a separate cabinet: WS2812B strips, small servos, vibration motors, coin speakers, 5V DC motors.

Margin note on the cabinet model. The cabinet model is critical. The alternative is buying a full kit per student, which means every student gets every component whether or not they use it and the cohort ends the semester with 240 unused ultrasonic sensors in a drawer. Cabinet distribution also forces students to commit to a sensor choice, which is a useful constraint. Keep a signout sheet.

Faculty preparation

Before the semester starts:

• Build every example project yourself. Not to be an expert, just so you have felt the debugging loop once.
• Write a one-page FAQ for the top ten errors you hit. You will reuse this for three years.
• Invite the lab technician (if you have one) to the first two studio sessions. Students will have hardware questions that cannot be answered on week one, and that is expected.
• Pre-flash every XIAO with a known-good "blink" sketch so students can verify their board works before they think they broke it.

Margin note. The pre-flashed blink sketch saves approximately forty hours over the course of the semester. That is not an exaggeration. Half of the first-week anxiety is students who cannot tell whether their board is dead or their code is broken. A board that blinks when you plug it in eliminates that question.

Adapting the brief for your context

This brief assumes a specific set of conditions. Yours will be different. Here are the most common modifications and how to think about them.

Shorter studios (4 weeks): compress weeks 2 and 3. Give students a smaller menu of pre-chosen sensor-output pairs (four options, not open-ended). Skip week 5 as a separate phase and fold it into week 4.

Longer studios (full semester): do not add more features. Add depth. Second prototype iteration, user testing with non-studio participants, a comparison of three sensing approaches for the same action. Resist the urge to add a second sensor.

First-year cohorts: drop the soldering requirement. Stay on perfboard with soldered header pins for connections, not for the whole circuit. Use only the VL53L0X, the MPR121 and the HC-SR501, which are the three sensors with the most forgiving debugging experience.

Graduate cohorts: the brief stays mostly the same, but the rationale becomes five pages, the mapping study becomes a formal user observation exercise and the critique becomes a one-hour defense.

No soldering facility: switch entirely to JST-terminated sensor modules and screw terminals. Slightly more expensive, no smoke.

One thing not to do

Do not use this brief as a way to sneak Arduino programming into the curriculum. Students will smell it immediately. If the real goal is teaching code, teach code in a different course with an honest title. This brief works because it keeps the design question in the center. The moment the grading starts rewarding clever code, the form work collapses and you are running a bad engineering studio.

If you want to run an engineering-forward version, fine, but write a different brief. Do not pretend this one is it.

If you adopt this brief and it breaks in some predictable way not warned about here, get in touch. The brief is on version four. Version five will incorporate what you found.

If you are trying to figure out how to grade the projects this brief produces, the companion post How to Grade a Physical Computing Project Without Becoming an Engineer is the next thing to read. If you are earlier in the curriculum planning process and wondering whether to teach electronics and programming at the same time at all, The Cognitive Load Problem argues that you should not.