Current state: July 19, 2026
No prior full-case audit exists for CS-03. The teaser audit from July 9 flagged three issues on the teaser page: the emotional hero headline, empty alt attributes, and the role-based architecture not surfaced early enough as a leadership decision. The boundary piece from July 10 flagged that the full case returns HTTP 200 with complete HTML before the client-side localStorage redirect fires. Content you consider password-protected is not.
On the live full case today:
- The emotional headline persists. "Designing for the worst day of someone's life" still leads.
- The client-side auth gap persists. Full case content is in the HTML response. A buyer who views source, or any crawler, sees everything.
- "Product Design Director / GM · 0→1 Build" now appears in the hero brief row. Good.
- "Complexity lives in the system, not the interface" appears once, under the Caseworker-first claim. It is not illustrated through a specific decision.
- The agentic redesign section is new and structurally significant. It contains the clearest human-system boundary thinking on the entire page. It is positioned as a hypothetical.
The sidebar labels this page "04" while the URL and subject are CS-03. A numbering error in a case about systems thinking undermines the signal.
Everything below evaluates what the full case does and does not accomplish for a Director+ buyer reading it before or during an interview loop.
What this page gets wrong
A buyer scanning this case will take away one thing: Juno consolidated six legacy tools into one platform for the Red Cross. That is a platform-consolidation story. Platform consolidation does not get you hired at the companies you are pursuing.
What gets you hired: you designed the boundary between human judgment and system automation in a federally regulated, zero-training, surge-load environment. Untrained volunteers making high-stakes decisions about displaced families. FEMA audit requirements at the point of every transaction. A disaster timeline that does not wait for your sprint cycle. The system had to absorb complexity so the human could make better decisions at the moment that mattered.
"Complexity in the system, not the interface" is a design philosophy for human-agent coherence. It answers the question every AI-native product company is currently trying to answer: where does the human decide, and where does the system decide? That answer is already in this case. The page just doesn't surface it.
Every checkpoint below identifies a specific place where the page defaults to the consolidation frame when it should be telling the coherence story.
1. GM scope in the opening section
The brief row works. The intro paragraph undoes it.
"Product Design Director / GM · 0→1 Build" in the hero brief is the right label. Then the intro says you "led design and delivery of the replacement platform." That's a design-lead frame. A GM built the operating model while building the product. A GM made scope decisions. A GM owned the outcome. Say so.
Rewrite the intro's first sentence to lead with GM scope:
"As Product Design Director and GM of a 0→1 build, I stood up a seven-person cross-functional team and owned the full delivery: information architecture, workflow design, compliance integration, and national deployment inside a single disaster-response cycle. The operating environment: a federal disaster declaration was active, caseworkers were toggling between six disconnected tools, and displaced families were waiting in shelters."
The emotional weight still lands. But the first sentence has already told the buyer who owned the boundary decisions.
2. Constraints as the design problem itself
Section 01 / Stakes treats constraints as scene-setting. They are the design problem.
A federal disaster timeline you don't control. FEMA compliance requiring audit-ready documentation at the point of every transaction, not after. A workforce that has never seen the system and won't be trained. Six incompatible data models never designed to share a record. The page separates these from the design work. Don't.
Merge Stakes and Design into a single section. Open with the constraints as a problem statement:
"The design problem was the operating environment itself. A federal disaster declaration sets a timeline the product team doesn't control. FEMA requires audit-grade documentation at the point of every transaction, not after. The primary users are surge volunteers who will never be trained. And the data lived in six systems that were never designed to share a record. Every design decision had to resolve for all four constraints simultaneously."
Then move directly into the four approach claims as the resolution. The buyer should never feel a gap between "here's the situation" and "here's the design thinking." That gap is where the consolidation read takes hold.
3. "Complexity in the system, not the interface" — illustrated or stated?
Stated. Not illustrated. This is the biggest gap on the page.
The phrase appears once, under the Caseworker-first claim, alongside three other claims of equal visual weight. A buyer reads it, nods, keeps scrolling. Nothing on the page makes them feel what the phrase means in practice.
Based on decisions already on this page: when a volunteer selects Grey Sky instead of Blue Sky in Decision 01, the system locks in different hardship codes, assistance caps, and eligibility tiers. The volunteer doesn't know that. The volunteer sees two choices. The system absorbed the complexity of FEMA's program-type taxonomy so the volunteer could make one choice instead of eight. A design decision with federal consequences, currently buried in a paragraph a scanning buyer will skip.
Elevate this as a named pattern, not a tagline. After the merged Stakes/Design section and before the six decisions, add a short bridge:
"The governing principle: complexity in the system, not the interface. Every decision below applies it differently. In intake, a volunteer choosing between two disaster types triggers eligibility logic they never see. In payments, FEMA audit documentation assembles itself at the point of transaction. In the supervisor queue, urgency encoding replaces manual case-by-case triage. The human makes the decision that requires human judgment. The system handles everything that can be determined from data already in the record."
Then, in each of the six decision sections, bold the specific moment where the system absorbs complexity so the human doesn't have to. The buyer should scan the page and see the pattern repeating six times, each time in a different role context. That repetition is what makes a philosophy feel earned.
4. Three-role architecture challenge
The roles show up through the six decisions. The architecture challenge is invisible.
A buyer can see that different roles use the platform differently. What they cannot see: why building one system for all three was hard, and why "one record, three views" is itself a human-system boundary decision. The system unifies the data model. Each role sees only the view shaped to their judgment context. That's a design choice with structural alternatives you rejected.
The legacy tools were six systems built around six functions, none designed to share data. Most platform consolidation projects get this wrong. They either build three separate interfaces on a shared database (solves the data problem, breaks the workflow) or build one interface that forces all roles through the same flow (solves the workflow for one role, breaks it for the other two). Name the options you didn't choose. The buyer needs to see that you understood the structural landscape and picked deliberately.
Add a short section between the Design claims and Decision 01:
"The legacy tools weren't six versions of the same system. They were six systems built around six functions that were never designed to share data. Consolidation meant building a single case record that three roles — caseworker, supervisor, finance officer — could each see through a view shaped to their workflow. Not three interfaces on a shared database. Not one interface that forces all roles through the same flow. One record, three views, zero redundant entry."
Thirty seconds to read. Tells the buyer exactly what you chose and what you didn't.
5. Surge-ready design through specific decisions
Claimed as an outcome. Not shown through the decisions that produced it.
The connection is already in Decision 04: under 10× volume, a supervisor who has to open every case to find priority will drown. Urgency bars that encode wait time visually mean the supervisor moves to the highest-priority case without discovering priority manually. Batch-approve for low-risk cases means the supervisor spends time only on cases that require judgment. These are the decisions that made "no retraining at 10× surge" true. The page doesn't frame them that way.
In Decision 04, add one sentence after the urgency-bars description:
"This is what made 10× surge survivable without retraining: the system encodes priority so the supervisor doesn't have to discover it."
In Decision 01, name the same connection:
"A first-time volunteer sees two choices, not eight fields. That's the decision that made zero-training intake possible at 10× volume."
Surge readiness shaped specific interface decisions. The page has the decisions. It needs the connective tissue that tells the buyer these were load-bearing choices with operational consequences.
6. Outcome contextualization
The numbers are present. What they mean is not.
The stats row: 6 months, $847K disbursed, 6→1 systems, 1,689+ cases in two weeks. Decision 06 adds 98.7% FEMA compliance. A buyer who doesn't know what normal looks like reads these as decoration.
Six months for a national deployment replacing six legacy systems in a federally regulated environment is extremely fast. It means compliance validation ran parallel to build. That's a GM decision, and the page should say so. $847K disbursed with 98.7% FEMA compliance means the platform handled real money under real federal audit pressure and passed. 1,689 cases in two weeks means the platform survived its first surge deployment with users who had never touched it.
Add a brief outcomes section after Decision 06:
"The platform deployed nationally six months after the first wireframe — compliance validation running parallel to build, not sequenced after it. The first live deployment processed 1,689 cases across three simultaneous disaster events with 23 caseworkers, disbursed $847K in direct assistance, and achieved 98.7% FEMA compliance. The surge volunteers who used it on day one had never seen it before."
That last sentence closes the loop on the entire case. Complexity in the system, not the interface, validated under the exact conditions it was designed for.
Your strongest signal, buried as a hypothetical
The "If I were building this today" section contains the clearest articulation of human-system boundary thinking anywhere in your portfolio. The comparison table showing what gets automated (FEMA feed matching, fraud flagging, duplicate detection) versus what stays human (eligibility approval, federal audit sign-off, family-critical decisions) is exactly the decision architecture Director+ buyers at AI companies need to see you make.
It's framed as a thought experiment. A buyer reads it as interesting but speculative. That's a positioning failure.
Reframe it. The original build already made human-system boundary decisions. Every one of the six decisions above is a decision about where the human decides and where the system decides. The agentic section extends those same decisions with new technical capability. That continuity should be visible.
Retitle it: "The boundary decisions I made in 2021 are the same ones agentic systems require now."
Now the section becomes evidence of a design philosophy with years of consistency. The buyer hiring for an AI-native design leadership role needs to see that you've been thinking about human-system boundaries since before anyone called it agentic design. The principle strip already says it: automate what can be verified, keep humans where the consequence is federal, irreversible, or family-critical. That's what the 2021 build did with 2021 tools.
The case this page should make: I designed the boundary between human judgment and system automation in a federally regulated, zero-training, surge-load environment, and the philosophy I used then is the philosophy your AI product needs now.
Every recommendation above serves that single reframe.
- Amplitude's human-agent workflow language: The live Head of Product Design posting explicitly asks the hire to define how agents and humans work together in the same workflows, which is the exact framing this audit says the Red Cross case should lead with.
- Vanta's AI-native quality systems: Vanta's Head of Design role asks for launch review frameworks, definitions of done, and agentic UX patterns across a ~40-person org, making it a strong match for the "complexity in the system" philosophy once the case reframe lands.
- EU AI Act Article 14 on human oversight: The regulation requires high-risk AI systems to let humans understand capacities, detect anomalies, interpret outputs, and intervene or stop the system, which maps almost exactly to the human-system boundary decisions in the Red Cross agentic redesign section.
- Gusto's AI wrongness framing: Gusto's Senior Staff Service Designer posting names AI wrongness, escalation ownership, and exception movement between systems and teams as the core design problem, which is the same failure-mode vocabulary the Red Cross case should be speaking.