Current State
Three things are true about this page as of July 3rd.
Resolved. The full case page now puts GM framing above the fold. Role is named Product Design Director / GM. Team composition, six-month national deployment, four outcome metrics all visible before the first scroll. The hero does real work.
Still open. The P0 client-side gating vulnerability is live. Full case content ships in the HTTP 200 response. The localStorage check is cosmetic. Same finding, same severity as the "What Do You Count" essay.
New. Two consistency issues between the teaser and full page. The teaser labels this case 03; the full page labels it 04. The teaser sequences verification as its third block; the full page's third decision block is outreach, with verification logic distributed across intake, finance, supervisor, and agentic sections. Small discrepancies. Disproportionate doubt. A panel member who notices the mismatch won't ask about it. They'll just trust the case slightly less.
H2 headcount unlocks in the next two weeks. Most of the country is offline this weekend. You are not. Fix what follows before Monday.
P0 — Access Control Is Cosmetic
Full case content ships in the HTTP response before any JavaScript executes. The password gate is cosmetic. View-source, curl, and any bot crawling without JS execution gets the complete case.
The full Red Cross case page returns HTTP/2 200 with 248,966 bytes of complete HTML before any JavaScript executes. The localStorage.getItem("pf_access_v1") redirect fires client-side, after the browser has already received every decision narrative, every UI mockup, every metric, and the entire agentic redesign section.
You password-protect this page because you believe the content warrants selective sharing with interview panels. The protection is cosmetic. Act on the belief or drop the gate.
Fix: Server-side authentication or a static-site approach that withholds content from the initial response. This is an implementation problem.
Six-Criterion Evaluation
1. GM Scope in the Opening Section
Assessment: Meets. High confidence.
The hero names the role, identifies a six-person delivery team, states six-month national deployment, shows four outcome metrics. A panel member scanning the first screen gets the signal: this person owned the problem end-to-end.
One gap. The hero says Juno "led design and delivery." At this level, that phrase spans a range from running sprints to owning scope tradeoffs, stakeholder alignment, launch governance, and national rollout sequencing. The difference between those readings is the difference between a design director and a GM.
Recommendation: Add one sentence to the hero brief naming the operational scope. Close to:
"Owned research, scope decisions, stakeholder alignment across Red Cross national leadership, delivery sequencing, and launch readiness for national deployment."
One sentence. It converts "led design and delivery" from a claim into a job description a panel can evaluate.
2. Constraints as the Design Problem
Assessment: Partially meets. High confidence.
The page names the right constraints: federal disaster declaration, mass displacement, surge volunteers, audit pressure, six disconnected tools, poor network conditions, untrained volunteers, federal oversight, 10× surge absorption. All present. But the strongest constraint language lives below the hero, in the stakes section, where it reads as background context preceding the design work.
The teaser does this better. Its first screen compresses the federal clock, untrained volunteers, surge conditions, federal oversight, and national deployment into one problem statement. The full page dilutes that compression by spreading constraints across two sections before the first decision.
This matters because constraint dissolution is the specific capability that separates this case from every other "we redesigned a legacy system" story. Embedding FEMA compliance into the transaction workflow so it never becomes a review gate. Designing intake so that three fields trigger five backend operations. The constraints are the design material. They belong in the problem statement, up front, where they frame every decision that follows.
Recommendation: Import the teaser's constraint density into the full page's opening. The actual design problem: build a system that untrained volunteers can operate under surge conditions, on unreliable networks, under federal audit requirements, in six months, replacing six tools that had never shared data. That sentence should appear before the panel member reaches the approach block.
3. Complexity in the System, Not the Interface
Assessment: Partially meets. Moderate confidence on placement; high confidence on content quality.
The content itself is the strongest material on the page. Three-field intake triggering eligibility, identity, FEMA verification, duplicate detection, and program-rule logic behind the scenes. Progressive disclosure throughout. FEMA compliance documentation embedded at the point of transaction rather than added as a review gate. Supervisor queue prioritization replacing manual case-by-case scanning with urgency bars, wait-time indicators, batch approval.
The problem is placement. The canonical proof point, the intake flow where a volunteer sees three fields while the system executes five operations, lives in Decision 01. A panel member has to scroll past the stakes section and the approach block to reach it. The principle is stated as philosophy before it is illustrated with a specific decision. That ordering inverts what the criterion requires. Show the decision first, then name the principle it demonstrates.
Recommendation: Pull a compressed version of the three-field/five-operation pattern into the approach section as the concrete illustration of the principle. State the principle, then immediately prove it with the intake ratio. A panel member who reads nothing else should leave with that ratio in their head. The full treatment stays in Decision 01. The proof point arrives early.
4. Three-Role Architecture Challenge
Assessment: Partially meets. High confidence.
The teaser states the architecture cleanly: one record for three roles that had never shared a system. The full page broadens the role model to five (field volunteer, caseworker, supervisor, finance officer, program director) without pausing to explain the shared-record architecture that makes this possible.
Each decision section shows a role-specific view. But the structural insight, that these are permission-aware views of a single record rather than five separate interfaces, is implied through accumulation rather than stated as an architectural decision. A panel member reading Decision 01 through Decision 06 will see different screens. They will not necessarily understand that these screens share a data model.
This is the most transferable pattern in the case. One record, multiple role-appropriate views, permission-aware visibility. It maps directly to Headway (provider/patient/insurer), Gusto (employer/employee/admin), Ramp (spender/manager/finance). If the panel can't retell the architecture, they can't map it to their own problem.
Recommendation: Add a short architecture block before Decision 01. Three elements: the old state (each role had its own tool, data didn't flow), the new model (one shared record with role-specific views and permission-aware visibility), and a simple diagram or list showing which role sees what. Sixty seconds to read. Gives the panel the sentence they'll use in the debrief:
"She built one record that five roles access through different views."
Lead with three in the architecture statement. Caseworker, supervisor, volunteer: the roles that had never shared a system. That's the retellable number. Then expand to five in the decision sections, where the full operational reality lives. The teaser says three. The full page shows five. Both are true at different altitudes. Make the relationship explicit so the panel doesn't read it as inconsistency.
5. Surge-Ready Design Through Specific Decisions
Assessment: Meets. Moderate confidence on validation evidence; high confidence on design-decision coverage.
The full page shows surge readiness through concrete design decisions: reduced intake fields for speed under volume, progressive disclosure for zero training, duplicate detection for data integrity under pressure, urgency-bar supervisor queueing for triage at scale, batch approval for throughput, program-director command views for oversight without bottleneck, module configuration for deployment flexibility, embedded compliance to prevent audit backlog. The decisions are specific. The chain from design choice to surge capacity is traceable.
The gap is validation. The page claims 10× volume absorption and zero retraining but does not show how those claims were tested or verified. At Director+ level, the panel will ask: is 10× observed load or architectural capacity? Did you watch untrained volunteers complete intake without assistance, or is that a design intent? What broke?
Recommendation: Add one compact proof chain. Even a three-row table works:
| Claim | Decision | Evidence |
|---|---|---|
| 10× volume absorption | Reduced intake fields, batch approval, urgency-bar triage | [Observed load? Architectural capacity? State which.] |
| Zero retraining | Progressive disclosure, three-field intake | [Observed during deployment? Usability test? State which.] |
| 98.7% FEMA compliance | Compliance embedded at point of transaction | [Audit result? Internal metric? State which.] |
If the evidence is observational (watched volunteers complete intake unassisted during a specific deployment), say so. If the 10× claim is architectural capacity rather than observed load, say that too. Panels respect precision about what you know versus what you projected. A GM draws that distinction without being asked.
6. Outcome and Six-Month Timeline in Context
Assessment: Partially meets. High confidence.
The metrics are strong: $847K disbursed, 1,689 cases in two weeks, six-to-one system consolidation, six-month national deployment, 98.7% FEMA compliance. They appear above the fold and repeat in the program-director section.
What's missing is the timeline story. Six months to national deployment of a platform replacing six legacy systems under federal oversight is extraordinary. The page treats it as a fact. A GM would present it as a series of decisions: what was cut, what was sequenced for post-launch, what was negotiated with stakeholders, what technical tradeoffs were accepted to hit the window.
This is the single largest gap between the current page and the GM reading you need the panel to walk away with. The panel currently reads "designer who shipped fast." Visible scope and sequencing decisions give them the GM version of that story.
Recommendation: Add a timeline-context module after the hero or before Decision 01. Keep it under 150 words. Name two or three scope decisions that made the six-month window possible. What did you cut? What did you sequence for post-launch? What stakeholder alignment was required to hold the timeline? The metrics say what happened. The timeline module says what you decided.
Artifact Hygiene
Four items. Prevent panel doubt before the content has a chance to earn panel trust.
Case numbering. Teaser says 03. Full page says 04. Fix one. Both artifacts may be in front of the same evaluator, and numbering mismatches register as carelessness before the content registers as competence.
Decision sequencing. Teaser's third block is verification. Full page's third decision is outreach. If a panel member reads the teaser first, the mismatch creates a low-grade credibility drag. Align the sequences or note the structural difference.
Social metadata on the full page. The full page's <head> contains no meta description, no Open Graph tags, no Twitter card metadata. The teaser has all of these, well-written. If the full page is ever shared via link preview, it renders as a blank card. Copy the teaser's social metadata to the full page. Adjust the title. Five minutes.
Decision-section role expansion. The teaser closes with "six systems, three roles, one source of truth." The full page expands to five roles without bridging the gap. See Criterion 4 recommendation above.
Priority Stack
You have the long weekend. Here is the order.
- Add one-sentence operational scope to the hero. Ten minutes. Converts the GM claim from title to job description. Changes how the panel reads every section that follows.
- Fix the case numbering mismatch. Five minutes. Cheapest credibility leak to close, and you're already in the file.
- Import teaser constraint density into the full page's opening. Twenty minutes. Makes the design problem legible before the first decision section.
- Add the architecture block before Decision 01. Thirty minutes. Gives the panel the retellable sentence about one record, role-specific views.
- Add the timeline-context module. Thirty minutes. The GM differentiator the page currently lacks.
- Copy social metadata from teaser to full page. Five minutes. Prevents blank link previews.
The P0 gating fix requires implementation work beyond a single editing session. Flag it, schedule it, don't let it block the content fixes. The content fixes change how the panel reads you. The gating fix changes who can read you without permission. Both matter. The content fixes matter this week.
- Multi-role architecture transferability: The one-record, role-specific-view pattern in this case maps directly to Headway's Provider Experience posting, where the EHR touches scheduling, telehealth, clinical documentation, insurance verification, and billing across provider and patient roles.
- Agentic section as interview bridge: The Red Cross case's 2026 agentic redesign section names human approval gates and agent confidence levels, which aligns with the autonomy-threshold framing in the Trust essay and should be rehearsed as a verbal bridge for AI-native rooms.
- Capital One's org-transformation lens: The Director, Product Design — AI in Experience Design posting tests operating-model change rather than product-case depth, which means Red Cross should be cited for governance and constraint-dissolution judgment, not walked through as a portfolio case.
- Constraint dissolution under regulation: Gusto's Senior Product Design Manager, Payroll posting explicitly names automation and AI initiatives that reduce manual work without compromising accuracy or trust, making the FEMA-compliance-embedded-in-transaction pattern from this case the strongest proof point for that room.