The full case page delivers complete HTML before a client-side script redirects to /login.html. This audit is based on the delivered source content. Confidence in structural and copy findings: high. Confidence in visual presentation: moderate. The teaser page renders fully without gating.
Prior recommendations: This is the first full-case audit of CS-03. No prior recommendations to track against. Teaser-level observations informed the consistency checks below but were not issued as formal recommendations.
One immediate problem: the full case displays case number 04 in the hero and sidebar. The teaser uses 03. Fix this before any Headway conversation. A numbering mismatch on a case about data integrity is the kind of detail a clinical-ops panelist notices and silently downgrades you for.
The hero has thirty seconds. It's spending them wrong.
A Headway panelist opens this case with a question they will never say out loud: Can this person own a build, or do they need someone else to own it for them?
Your hero almost answers it. The role line reads Product Design Director / GM · 0→1 Build. The team line lists seven people. The intro says you "led design and delivery of the platform that replaced all six." These are correct signals. A seven-person team replacing six national systems in six months with you as GM is a scope statement that a VP Product at a healthcare platform will respect immediately.
Where it breaks: the hero intro leads with the humanitarian frame. "A federal disaster declaration. Caseworkers toggling between six disconnected tools while displaced families waited." That sentence is trying to establish the constraint, the system failure, and the human stakes simultaneously. None of them land hard enough because they're sharing a single sentence.
A Headway panelist lives inside HIPAA timelines and multi-payer complexity. They'll recognize operational pressure instantly if you put it first. The emotional stakes can follow. They cannot lead.
Rewrite the hero intro. Draft:
"Six disconnected systems. A federal disaster declaration running the clock. Untrained surge volunteers who needed to be productive on day one. I owned the build — design, engineering coordination, and delivery — of the platform that replaced all six. One unified record for three roles that had never shared a system, deployed nationally in six months. 1,689 cases processed in the first two weeks it was live."
Three changes worth calling out. "I owned the build" instead of "I led design and delivery" shifts the read from design leadership to GM accountability. A design lead says "design and delivery." A GM says "the build." The team line and scope line already do the work of showing what that build contained. Second, "three roles that had never shared a system" moves up from where it's currently buried in a design subsection. The teaser already uses this phrase in its hero. The full case should match. Third, constraints lead because that's what a healthcare buyer scans for first.
Constraints are sitting in the background section. They belong in the problem statement.
Your Stakes section opens with the right ingredients: mass displacement, surge volunteers, federal audit pressure, six tools that didn't communicate. The design subsection adds slow networks, untrained users, federal oversight, and the requirement to absorb 10× surge without workflow changes.
All of this appears as context for the design work. A Headway panelist needs to read it as the design problem itself. When constraints sit in the background, the reader processes them as scene-setting and moves on. When constraints sit in the problem statement, the reader processes them as the thing you solved. Same information, different placement, different read.
Your four approach cards (Caseworker-first, One record, Compliance built in, Built for surge) are the right strategic pillars. Right now they summarize what you built. They should map the tradeoffs you navigated.
Add one sentence to each approach card naming the alternative you rejected. Example for "Compliance built in":
"We could have handled FEMA documentation as a post-transaction step, the way the legacy systems did. That meant every audit cycle required manual reconstruction of the authorization chain. Instead, every disbursement self-documents at the point of transaction. The compliance cost is zero additional caseworker steps."
A healthcare-platform buyer who has watched teams bolt compliance onto workflows as an afterthought will read that sentence and think: she understands what we deal with.
Decision 01 is your best proof point. It's not proving hard enough.
The Caseworker-first card states the principle: "Complexity lives in the system, not the interface." Decision 01, Three fields, not eight, is where that principle becomes real. A first-time volunteer sees three fields. Behind those three fields, selecting "Grey Sky" versus "Blue Sky" locks in different hardship codes, assistance caps, and eligibility tiers. One wrong tap cascades incorrect rules across the entire case.
That is a genuinely difficult design problem. How do you make a high-consequence selection feel simple without hiding the consequence? The decision module shows the progressive disclosure pattern and names the cascading-rules risk. What it doesn't do is make the tradeoff legible as a tradeoff. The reader needs to understand that you chose to accept the risk of a single-tap error cascading through the case because the alternative produced worse outcomes.
Add a tradeoff line. Draft:
"The risk of progressive disclosure is that a wrong selection at the top cascades silently. We accepted that risk because the alternative — eight fields visible to an untrained volunteer during surge intake — produced more errors in testing, not fewer. The system validates downstream; the interface stays simple."
A Headway panelist evaluating your ability to handle multi-step clinical workflows will read that and see someone who makes hard calls with evidence.
The three-role architecture is demonstrated but never named as the hard problem
Your six decision modules are tagged by role: Field Volunteer, Caseworker (twice), Supervisor, Finance Officer, Program Director. Each module shows a different user seeing the same underlying record through a role-appropriate view. This is exactly the kind of multi-role architecture a healthcare platform builds constantly. Therapists, clients, billing coordinators, and clinical reviewers all touching the same session record with different permissions, different views, different workflow needs.
You never pause to name the architectural challenge. A reader who works in healthcare will recognize the pattern. But recognition and attribution are different things. They need to see that you understood the difficulty of what you were doing while you were doing it.
Add a bridging paragraph before the decision modules begin. Draft:
"The six legacy systems failed because each one was built for a single role. Intake was a volunteer tool. Case management was a caseworker tool. Payments were a finance tool. None shared data. The architectural challenge was designing one platform where three roles with fundamentally different mental models — a volunteer processing their first case, a caseworker managing forty, a supervisor reviewing five hundred — could work from the same record without any role seeing complexity that belonged to another role."
That paragraph reframes the legacy problem as an architecture problem, which is transferable. Modernization stories aren't. It gives the Headway panelist the exact mapping they need. Your three roles map to their multi-role clinical workflows. You don't need to make the analogy explicit. They'll make it themselves, and that's always more persuasive.
Surge-readiness is claimed. It needs to be traced.
Your approach card claims the platform handled 10× normal volume from day one with no degradation and no retraining required. Decision 01's three-field intake is a surge decision. Decision 04's queue with urgency bars and batch approval is a surge decision. Neither module explicitly connects its design choice to surge performance.
Healthcare platforms face their own version of surge: open enrollment periods, insurance panel changes, sudden provider-network shifts. A panelist who has lived through a surge failure wants to know which specific decisions made your system survivable.
Tag the surge-critical decisions explicitly. Three additions:
Decision 01:
"This is a surge decision. Three fields means a volunteer processes intake in under ninety seconds. At 10× volume, that's the difference between clearing the queue and losing families to walkaway."
Decision 04:
"Batch approval of low-risk cases is a surge multiplier. During the first deployment, supervisors cleared 247 approvals in a single session. Without batch, that's 247 individual case opens."
Decision 06: The mockup shows 1,689 cases across three active events with 23 caseworkers. Do the math for the reader:
"1,689 cases. 23 caseworkers. That's 73 cases per caseworker across three simultaneous disaster events. That ratio is only survivable because intake, case detail, eligibility, and payment all live in one record. Every screen switch the legacy system required would have cut that capacity in half."
That's the most concrete proof that design decisions produced surge capacity. Don't leave it as implicit arithmetic.
The outcome metrics need a constraint frame and a timeline breakdown
Your hero metric row (6 mo, $847K, 6→1, 1,689+) is clean and scannable. The numbers are strong. They sit without enough context for a reader to feel what six months actually required.
Six months from zero to national deployment. Seven people. Six legacy systems with years of accumulated role-specific workflow logic. A Salesforce SLDS stack constraining your design vocabulary. A federal timeline that doesn't flex. A system going live into an active disaster, not a controlled rollout.
Most of that context exists somewhere in the case. None of it is concentrated around the outcome metrics where a panelist's eyes will land when they're deciding whether to advance you.
Add a contextualizing line below the metric row. Draft:
"National deployment in six months, from first commit to live cases, on a seven-person team replacing six legacy systems — during an active federal disaster declaration. There was no staged rollout. The platform went live into surge."
One gap I can't resolve from the published case: there's no phase breakdown. A healthcare panelist who has run 0→1 builds will want to understand how much of six months was discovery versus design versus build versus deployment. That compression is part of the story. If you spent two weeks on discovery because the federal timeline forced it, say so. If design and build ran in parallel because they had to, say so. The absence of that breakdown makes the six months feel like a number rather than a narrative of operational decisions about where to compress and what to protect. [Confidence: high that this gap matters to the Headway buyer. Speculative on what the actual phase split was.]
The agentic section earns its place. The transition doesn't.
"If I were building this today" is a differentiator. Most case studies end at ship. Yours ends at what you'd do differently with current capabilities, which signals that you think about systems as evolving architectures. The agentic redesign, with its four agents, human gates for federal and family-critical decisions, and the principle "Automate everything you can verify. Keep humans where consequence is federal, irreversible, or family-critical," maps directly to where healthcare platforms are heading.
The transition into this section reads as an addendum. A Headway panelist should read it as the reason you're still thinking about this problem.
Rewrite the section transition. Draft:
"The platform shipped. It worked. But it shipped with three gaps I knew would matter: no client portal, cascading call center errors we couldn't resolve in the timeline, and a recovery plan that ended at disbursement instead of following the family through actual recovery. Those gaps are solvable now in ways they weren't in 2021."
That makes the section evidence of operational maturity. A panelist who has inherited a shipped product with known gaps will recognize that honesty.
Teaser-to-full consistency: three fixes
-
Case numbering. Teaser says 03. Full case says 04. Five-minute fix. Do it tonight.
-
Missing module. The teaser preview gallery includes "Caseworker · Verification" with the headline "Every check before a dollar moves." The full case replaces this with "Caseworker · Outreach" and "Contact log as the case log." This is more than a minor consistency error. A panelist who saw the teaser first and then reads the full case will notice the swap, and what it signals is worse than the swap itself: it suggests the case was restructured after the teaser was published. For a clinical-ops reviewer, structural inconsistency between a summary document and the full record raises the question of what else shifted. You cannot afford that doubt in a process where trust is the product. Add the verification module to the full case, or update the teaser gallery to match the current full-case structure.
-
Three-roles language. The teaser hero says "one record for three roles that had never shared a system." The full case hero says "one unified record" without the three-roles phrase. The teaser got this right. Match it.
What to do before the holiday weekend
This Friday, while the rest of the country is off for the Fourth, Red Cross teams will be running disaster operations. That's the organization you built for. The case is strong. The work is real. Every gap here is positioning.
Priority sequence:
- Fix the 03/04 numbering mismatch. Tonight.
- Rewrite the hero intro to lead with constraints, use "I owned the build," and include "three roles." Tomorrow morning.
- Add the tradeoff line to Decision 01, surge tags to Decisions 01 and 04, and the 73-cases-per-caseworker line to Decision 06. Tomorrow afternoon.
- Add the bridging paragraph before the decision modules. Wednesday.
- Add the contextualizing line below the metric row. Consider adding a phase-breakdown sentence if you have the data. Wednesday.
- Rewrite the agentic section transition. Thursday.
- Reconcile the teaser gallery with the full case modules. Thursday.
After those changes, a Headway panelist reading this case will see a designer who owned a mission-critical build end-to-end, made hard tradeoff decisions under federal constraints, designed for three roles on one record, and shipped into surge on a timeline most organizations would call impossible. The work already proves all of that. The copy just needs to stop making the panelist dig for it.
- Headway has two openings: The Design Director, Provider Experience role names AI-powered session notes and co-pilot features alongside the multi-role provider workflows that map directly to your Red Cross three-role architecture.
- Headway's insurance role matches differently: The Core Insurance & Design Systems posting combines regulated-workflow complexity with design systems ownership, which means Thermo Fisher and Allē may be stronger leads than Red Cross for that specific panel.
- Gusto's payroll role echoes this case: Their Senior Product Design Manager, Payroll posting centers correctness, compliance, and reducing operational complexity without making customers carry it, which is the same constraint logic your Red Cross "compliance built in" approach card demonstrates.
- Full-case gating is still client-side only: Every full case page, including this one, delivers complete HTML before the browser redirect fires, which means a panelist who inspects source will see your content and your access model simultaneously.