Chapter 25 — Design studio I
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 Studio brief"]
N2["25.2 Presenting choices"]
N3["25.3 Revising from critique"]
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 Studio brief"]
N2["25.2 Presenting choices"]
N3["25.3 Revising from critique"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 Studio brief]
|
v
[25.2 Presenting choices]
|
v
[25.3 Revising from critique]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) develop an architecture design in a studio setting; (2) present and defend design choices; (3) incorporate critique into revisions.
25.1 Studio brief
In Design Studio I, Sofia's team of four receives a brief: design the secure architecture for Corvia's new depot charging management system, which schedules electric bus charging and connects to the energy supplier's portal. They have four weeks. They start with context, stakeholders and protection needs, then draw a component model and data flows. The studio format mirrors professional practice: designs are developed iteratively, reviewed by peers and practitioners and revised. Daniel acts as client, answering questions about constraints and refusing to make design decisions for them.
25.2 Presenting choices
At the midpoint review the team presents three options: charging control in the cloud with remote commands to depots; control at each depot with cloud reporting only; and a hybrid. They argue for depot-local control because buses must charge even when the internet link fails, with signed schedules from the cloud and local fallback rules. A reviewer challenges how they will stop a compromised depot controller from damaging chargers. They have no answer yet and say so honestly, recording the question as an open issue rather than inventing a response under pressure.
25.3 Revising from critique
In the following week the team researches the open issue with the charger vendor's documentation and safety engineers. They add hardware limits in chargers that cannot be overridden by the controller, separate the controller network from corporate systems and require two-person approval for changes to fallback rules. At the final review they show how each change answers the critique and what risk remains. Sofia learns that a design studio rewards honest uncertainty followed by research, and that critique is most useful when recorded and answered explicitly in the next version.
Worked example
Sofia's team compares three charging-control options, chooses depot-local control with signed schedules, records an open issue on compromised controllers and answers it with hardware limits and segmentation.
Synthetic case. The charging system, vendor and reviews are synthetic.
Errors and limits
Studio designs lack production detail; real constraints may change choices. Hardware limits depend on vendor implementation quality.
Exercises
- EX073 — Local control reason. Why did the team choose depot-local charging control? Rubric: 3 = buses must charge even when internet links fail;; 2 = resilience;; 1 = cost;; 0 = none.
- EX074 — Unanswered challenge. How did the team handle the challenge they could not answer? Rubric: 3 = said so honestly and recorded it as an open issue;; 2 = open issue;; 1 = invented answer;; 0 = none.
- EX075 — Final mitigations. Name two mitigations added after critique. Rubric: 3 = non-overridable charger hardware limits, network separation, two-person approval for fallback rules (two);; 2 = one;; 1 = vague;; 0 = none.
Synthesis
A design studio teaches architecture through options, honest open issues and revisions that answer critique explicitly.
Continue studying — chapter 25 of 50
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →