Chapter 25 — Design studio I | Engineering Digital forensics and malware analysis

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 Studio format"]
  N2["25.2 Option A: form-first"]
  N3["25.3 Option B: step-wise"]
  N4["25.4 Option C: label-driven"]
  N5["25.5 Critique"]
  N6["25.6 Prototype"]
  N7["25.7 Decision record"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 Studio format"]
  N2["25.2 Option A: form-first"]
  N3["25.3 Option B: step-wise"]
  N4["25.4 Option C: label-driven"]
  N5["25.5 Critique"]
  N6["25.6 Prototype"]
  N7["25.7 Decision record"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 Studio format]
    |
    v
[25.2 Option A: form-first]
    |
    v
[25.3 Option B: step-wise]
    |
    v
[25.4 Option C: label-driven]
    |
    v
[25.5 Critique]
    |
    v
[25.6 Prototype]
    |
    v
[25.7 Decision record]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) produce and critique design options for EvidenceDesk; (2) prototype the intake workflow; (3) run a design critique; (4) record design decisions.

25.1 Studio format

Studio is iterative: sketch, present, critique, revise. Priya's team presents three intake designs to Hugo and two classmates acting as examiners.

Each round is short: ten minutes to present, fifteen for critique and a week to revise. The classmates playing examiners are told to be blunt about anything that would slow them at a busy intake desk. Priya records each critique point with who raised it and whether the next version addresses it, so the studio leaves a trail of decisions rather than a collection of opinions.

25.2 Option A: form-first

A single long form records everything at intake. Complete but slow; examiners skipped fields in paper versions.

The paper form Northfield used had twenty-two fields on one page, and audits found the same five usually blank: seal number, packaging condition, seizure address, officer badge number and storage shelf. A digital copy of that form would inherit the same habit. Priya brings the audit counts to the studio, so the critique starts from evidence about real behaviour rather than preference. Missing seal numbers had caused the most trouble at court.

25.3 Option B: step-wise

Short screens guide each step — register, seal check, photograph reference, storage location. Fewer skipped fields; more clicks.

Each screen asks only for what that step needs, and it cannot be completed with a required field empty. The seal-check screen, for example, asks whether the seal is intact, its number and a photograph reference. More clicks cost time, so Priya measures it: step-wise intake takes about ninety seconds longer per item than the single form, and the examiners judge that acceptable.

25.4 Option C: label-driven

Scan a pre-printed label to create the item, then fill the minimum fields; details added later. Fast, but risks incomplete records if "later" never comes.

Scanning a pre-printed label removes typing errors in the identifier and makes registration almost instant, which helps when a car boot full of items arrives at once. The danger is that 'later' slips during busy weeks. In the critique, examiners admit that half-completed records would pile up, and a system that allows them would soon be full of items nobody could fully account for.

25.5 Critique

Examiners prefer B with C's label scan. Hugo stresses that nothing should mark an item "ready" until all required fields exist.

The combined design uses the label scan to create the item and pre-fill its identifier, then leads straight into the step-wise screens. An item with missing fields stays in a 'registration incomplete' state that blocks storage and acquisition, and the dashboard lists such items in red. Hugo's rule becomes a state-model constraint rather than a training reminder. Examiners agree to trial it for a month.

25.6 Prototype

Priya builds a text-based prototype in Python that walks through B's steps and refuses to complete without required fields.

The prototype runs in a terminal and prompts for each field in order, validating formats such as the identifier check digit and the date. If the user tries to finish early, it lists the missing fields and refuses. It writes records in the same JSON-lines format as the planned system, so the studio's test data can later be loaded straight into the real build.

25.7 Decision record

Decision: step-wise intake with label scanning; reason: completeness and speed; rejected: A (skipped fields), pure C (incomplete records). Date and participants recorded.

The record also notes the evidence behind the decision: the audit counts of blank paper fields, the timing measurements for each option and the examiners' critique. Recording rejected options with reasons means that when someone later proposes going back to a single form, the team can show why it was dropped and what would need to change. The record is filed beside the prototype code.

25.8 Usability check

Two classmates complete intake for five synthetic items each while Priya times them and notes confusion.

Timings show the first item takes about four minutes and the fifth about two, as users learn the screens. Confusion clusters at one point: both testers hesitate over whether 'packaging condition' means the evidence bag or the item inside. Priya relabels the field 'condition of evidence bag' and adds a separate optional field for the item, then reruns the check with two different classmates.

Accessibility

Screens use clear labels, keyboard navigation and sufficient contrast, so examiners with different needs can work efficiently. Error messages say what is missing and how to fix it, rather than showing codes. Priya checks each screen against a short accessibility checklist before the next studio session.

Worked example

The usability check shows both users missed the seal-number field, which appeared after the photograph step. Priya moves it to the first screen, next to the label scan, and both complete it on retest.

Synthetic case. The usability sessions are invented.

Errors and limits

Classmates are not examiners; repeat the check with real staff on synthetic items.

Exercises

EX073 — Option weakness. Name one weakness each of options A and C. Rubric: 3 = A skipped fields/slow; C incomplete records; 2 = one; 1 = vague; 0 = none.
EX074 — Seal field. What did the usability check find, and how was it fixed? Rubric: 3 = seal field missed; moved to first screen; 2 = partial; 1 = vague; 0 = none.
EX075 — Decision record. List four elements of the decision record. Rubric: 3 = decision, reason, rejected options, date/participants; 2 = three; 1 = one; 0 = none.

Synthesis

Studio iteration with real critique and recorded decisions turns ideas into a usable intake workflow.

Continue studying — chapter 25 of 50

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