Juno, I fetched the full case and the public teaser on August 9. Both returned HTTP 200. The full case delivers its complete HTML before the client-side access check runs — the access problem I covered in "Build the Control That Says No" still applies, which means the "private" case is functionally public to anyone who views source.
I'm reading this the way a VP Design reads it at 9 PM on a Tuesday, forty portfolios into the quarter, already skeptical.
GM Scope
Your role line says "Product Design Director / GM." The hero block says you led design and delivery. The team listing names one designer, one researcher, one PM, two engineers, two business analysts.
The GM title appears. The authority behind it never does.
A GM title earns its weight in a portfolio case only when the case shows a decision that required GM authority — budget reallocation, roadmap prioritization against a competing program, a scope call that a design director without operational ownership couldn't have made. Your case shows breadth of design scope across six operational surfaces. That's real work, but breadth of design scope and GM authority are different things, and the case treats them as equivalent. A panel won't.
The team listing actually raises a question it never answers: with a PM on the team, what was the division of authority between you and the PM? Who owned the roadmap? Who made the call when design priorities and delivery timelines conflicted? Any VP evaluator who has managed that tension will notice the gap.
Causal level: The GM claim needs level (a) evidence — a specific decision Juno made that produced a specific outcome. The case provides level (c): Juno held this title within a system that produced results. The case shows the title, implies the authority, and never demonstrates its exercise.
The evaluator's next question: "You say GM. What decision did you make in that capacity that changed the outcome of the program?"
I flagged this in "The Title Is Fixed. Nothing Else Shipped." The GM title remains the case's most distinctive positioning claim and still has zero supporting evidence on the page.
Constraints as Design Problem
This is the dimension where the case is strongest.
The constraint inventory is substantial: slow networks, untrained volunteers, federal oversight, FEMA documentation requirements, mass displacement, surge volume, six disconnected tools, eligibility rules, assistance caps, identity verification, fraud risk, audit chains. The design section presents four governing principles: caseworker-first simplicity, one shared record, compliance embedded in transactions, readiness for ten times normal volume.
Three design decisions respond to specific constraints in ways an evaluator can trace. The intake progressive disclosure reduces initial fields to the minimum while hiding downstream eligibility logic — that's the untrained-volunteer problem handled through information architecture. The disbursement ledger captures method, amount, authorization chain, audit reference, and fraud alerts at transaction time rather than reconstructing them later — that's the audit requirement built into the interaction model. The urgency-ranked supervisor queue replaces manual case-by-case priority discovery with automated routing — that's the surge problem addressed through workflow design.
These are specific mechanisms responding to specific operational realities. An evaluator can follow the logic from constraint to decision.
Where the case falls short: it never shows a rejected alternative. A design direction that failed against a constraint and was revised. A test protocol. A network-performance result. A FEMA rule that forced a specific field or flow change. The six user quotations are unattributed — no role, no interview date, no participant count, no research method. They read as texture rather than evidence.
Causal level: The design decisions themselves are level (a). The claims about how well they handled the constraints are level (b) — plausible given the mechanisms shown, but unvalidated by any external measure on the page.
The evaluator's next question: "Show me a constraint that changed your design after you tested it. What did you try first, and why did it fail?"
Complexity in the System
The case claims six disconnected tools consolidated into one platform with a single shared record. The mockups show a shared case record moving through intake, household context, outreach, eligibility approval, disbursement, and program oversight. Common identifiers and data objects appear across role-specific views. The architecture is visible in the interfaces.
What's missing: the case never names the six legacy systems. There's no migration diagram, no data-object mapping from old to new, no governance model for when source systems disagreed. The teaser is actually more explicit about information architecture than the full case — it mentions "a new information model" and "data architecture before interface design." That language doesn't appear in the detailed version. This is backwards. The deeper architectural work should live in the full case, where an evaluator goes to verify the summary's claims.
Causal level: The consolidation claim is level (b) — Juno led this, the outcome reflects her direction plus team execution. But the evidence presented is level (c): the platform exists, six systems were replaced, Juno was there. The architectural decisions that made consolidation possible are implied by the interfaces but never narrated.
The evaluator's next question: "What were the six systems? What was the hardest integration problem, and how did you solve it?"
Multi-Role Architecture
The case presents two professional titles — Product Design Director and GM — but never separates what each contributed. Every design decision on the page reads as design-director work: information architecture, interaction models, workflow design, interface specification. The GM authority is claimed in the hero and then disappears.
If the consolidation of design authority and operational authority in one person was necessary for this program to ship in six months at national scale, the case needs to show why. Where did design priorities and program-delivery priorities conflict? What decision required both hats, and what would have happened if they'd been split across two people? A program with FEMA compliance requirements, a six-month timeline, and six legacy systems to consolidate almost certainly generated those conflicts. The case doesn't surface any of them.
The positioning cost here is real. "Designer who held GM authority on a national disaster-relief program" is a claim most candidates at this level cannot make. But a claim without a supporting story is a credential line on a résumé, not an argument in a case study. The evaluator reads the title, waits for the evidence, and when it doesn't arrive, mentally reclassifies you as "design director on a consulting engagement." That's a defensible reading of the current page, and it's the wrong one.
The evaluator's next question: "What did GM mean on this program? What could you do that a design director without that title couldn't?"
Surge-Ready Decisions
The case claims the platform was designed for ten times normal volume from day one with no degradation and no retraining. The teaser adds that an untrained volunteer had to use the platform successfully on day one and that it deployed within one disaster-response cycle.
Three mechanisms are explicitly linked to surge conditions: progressive disclosure at intake, urgency-ranked queues for supervisors, shared records eliminating cross-role data reconstruction. These are defensible architectural responses to surge.
What's absent: the normal-volume baseline behind "ten times." Load-test methodology. Response times under load. Error rates. Training-time comparison. Queue-throughput data. Any before/after time-to-assistance measure. The claim is architectural — "we designed for surge" — rather than empirical.
Causal level: The surge-ready mechanisms are level (a) design decisions. The "ten times normal volume" performance assertion is level (c) — a system-level claim with no visible measurement methodology.
The evaluator's next question: "Ten times what baseline? How did you measure it?"
Outcome in Context
Four hero metrics. Six months from zero to national deployment. $847,000 disbursed across active events. Six systems reduced to one. 1,689 cases in the first two weeks. Deeper in the page, the Program Director section adds context: 1,689 cases across three active events, 23 caseworkers, $847,000 disbursed, 98.7% FEMA compliance.
The case lists four metrics but provides no context to evaluate any of them.
$847,000: over what period? Across how many disaster events? What was the previous disbursement rate or timeline? Without a baseline, an evaluator cannot tell whether this number represents success, adequacy, or underperformance.
1,689 cases: opened, processed, resolved, or total active? What share of national disaster-relief volume did this represent? The hero says "1,689+" while the body text says exactly 1,689 — a minor inconsistency that signals the number hasn't been carefully reconciled.
98.7% FEMA compliance: against which rule set? Over what audit period? What was the previous compliance rate? Unevaluable without a denominator or a baseline.
Six-month national deployment is the most self-evident metric because it has a clear unit and a clear scope. It still lacks context — was six months fast or expected? — but it's the one number an evaluator can place without additional information.
Causal level: All four hero metrics are system-level results produced by Red Cross operations, disaster events, caseworker behavior, technology infrastructure, and factors well beyond design decisions. The case presents them in the hero block, adjacent to Juno's name and title, without any mechanism connecting a specific design decision to a specific metric. An evaluator reads proximity as attribution. The page layout makes a causal claim the page content doesn't support.
The standard I proposed in "The Confidence Rule" applies here: state the observable basis for a claim, its operating boundaries, and the evidence that would test it. The hero metrics meet none of those criteria.
The Mockup Problem
Secondary finding, but one that will erode trust with a careful evaluator: the case is dated 2021, but the Program Director mockup contains March–June 2024 dates and a "Hurricane Diana" event. Other mockups mix Hurricane Harvey with 2021 transaction dates and Houston Housefire sample data. The HTML class names identify these as mockups, but no visible caption says so.
An evaluator who notices the date mismatch will wonder what else on the page is reconstructed. Label the mockups. A single line removes the ambiguity before it becomes a credibility question.
Add a visible caption — "Screens reconstructed with anonymized data" — before any evaluator notices the 2021/2024 date mismatch and starts questioning what else is reconstructed.
Trust Essay Connection
The live Trust essay refers to the Red Cross case once, in its conclusion: "a disaster-relief platform where the wrong caseworker decision was not a UX error." It doesn't name Red Cross, doesn't link to the case, and doesn't use any of the case's specific evidence — the eligibility approval queue, the embedded audit chain, the disbursement authorization flow.
The cost of this disconnection is concrete. An evaluator who reads the essay gets the conceptual argument for human-gate design but no portfolio evidence to verify it. An evaluator who reads the case gets the evidence but no framework that explains why these design patterns matter beyond this one program. The essay and the case are making the same argument — that consequential human decisions require different design architectures than preference-based ones — but they make it in isolation, so neither gets the reinforcement.
Name Red Cross in the essay. Link to the case. Use the eligibility gate or the disbursement authorization chain as a named example of human-gate design. The essay already references the case obliquely; making it explicit costs one sentence and connects your strongest conceptual argument to your strongest operational evidence.
Prioritized Edits
Ranked by which fix would most change how an interview panel evaluates this case.
1. Add a GM mandate narrative. One paragraph showing a decision you made that required GM authority. Budget reallocation, a scope call that overrode a stakeholder request, a prioritization decision the PM couldn't have made alone. The GM title is the case's most distinctive claim and currently has zero evidence behind it. Highest-impact single addition.
2. Connect at least one hero metric to a specific design decision. Pick one metric and show the causal chain: this design decision changed this workflow, which produced this measurable effect. One connected metric is worth more than four floating ones.
3. Add denominators and baselines to outcomes. The $847K over what period? The 98.7% against what prior rate? The 1,689 as a share of what volume? Even partial context — "the previous system required X days to disburse; this one required Y" — transforms the evaluator's ability to assess weight.
4. Reconcile the role taxonomy. The teaser says three roles. The case shows five. Pick one number and make both pages consistent.
5. Label the mockups. One line explaining that screens are reconstructed with anonymized data. Removes the date-mismatch ambiguity before it becomes a trust problem.
6. Name and link Red Cross in the Trust essay. The essay's conclusion already references the case obliquely. Make it explicit. Use the eligibility gate or the disbursement authorization chain as a named example of human-gate design.
7. Fix the numbering. The page says Case Study 04. The URL says cs-03. The teaser says Case Study 03. Chapter 02 is missing between Chapters 01 and 03. Small errors that signal incomplete revision — exactly the kind of detail a careful evaluator notices and files as a quality signal about the candidate.
The case has strong material. The constraint logic is visible, the six design decisions are specific, and the operational breadth across five role-specific views is genuinely impressive for a six-month build. What's missing is the connection between the design work and the outcomes it claims. The case shows the work and then, separately, lists the numbers. The evaluator is left to infer the relationship, and at Director+ level, you do not want the panel filling gaps with their own inference. They will be less generous than you expect. Make the connection explicit.
- Gusto's send/review/never-send language: The Head of Design, Unified Service Platform posting asks candidates to define when AI output is ready to ship, needs human review, or should not be sent — the Red Cross eligibility gate and disbursement authorization chain are the closest existing evidence you have for that question.
- The assurance-case structure: NIST and NASA define an assurance case as claim, argument, evidence, and assumptions in one auditable artifact — a structure that would solve the Red Cross case's central problem of floating metrics disconnected from design decisions.
- Progressive transparency research: A CHI 2026 study found that eight of twelve participants preferred contextually sufficient transparency over maximal process visibility, which directly challenges the Trust essay's emphasis on showing work — and the Red Cross case's Chapter 03 agent hypothetical would need to account for that tension.
- OpenAI Engineering Acceleration's evaluation loop: The new posting names instrument, observe, evaluate, decide, iterate, and rollback as the product loop — almost exactly the longitudinal control record the Red Cross Chapter 03 hypothetical gestures toward but never specifies.