Gating Status: P0
I fetched the live URL. The server returns HTTP 200 with the complete case study HTML before the client-side JavaScript redirect fires. The gate checks localStorage for a pf_access_v1 key and redirects unauthenticated visitors to /login.html. But the redirect happens after the server has already delivered your most sensitive positioning content to the browser. Hero, mockups, six design decisions, metrics, the 2026 agentic redesign section.
Same vulnerability pattern I flagged on the "What Do You Count" essay. Same severity.
The login page compounds it: the password hash is hard-coded in client-delivered JavaScript using crypto.subtle.digest('SHA-256', ...) and compared against a CORRECT_HASH constant visible in the page source. Anyone with a browser inspector can read it.
Move the gate server-side. Return a 401 or 403 for unauthenticated requests. Use an HttpOnly session cookie. Do not ship the case HTML until authorization is established. If your host doesn't support server-side auth, use one that does, or gate via Cloudflare Access.
You are sending this page to hiring managers at companies where you want to demonstrate that you understand system-level trust architecture. The page itself contradicts that claim.
What the Page Currently Contains
The hero opens with "Designing for the worst day of someone's life." Role line: "Product Design Director / GM · 0→1 Build." Team: one designer, one researcher, one PM, two engineers, two BAs. Hero metrics: six months to national deployment, $847K disbursed during active events, six legacy systems consolidated into one, 1,689+ cases in the first two weeks.
Below the hero, the page frames the operating environment: federal disaster declarations, mass displacement, surge volunteers, federal audit pressure, six disconnected tools. Then six design decisions organized by role: Field Volunteer intake, Caseworker case detail, Caseworker outreach, Supervisor eligibility, Finance Officer payments, Program Director command. A closing 2026 section reframes the same problems as agentic-system design challenges.
The page is strong. Several sections are genuinely excellent. And it reads, on first pass, as a brilliantly executed design project led by a senior IC with unusual operational awareness.
It does not yet read as a GM-level build.
GM scope means you owned the product mandate, the delivery path, and the organizational tradeoffs. The design decisions lived inside that accountability. The evidence that you operated as a GM is on this page. The frame around the evidence still presents you as a designer who happened to touch GM-shaped problems. That gap is what this audit is about.
Criterion 1 — GM Scope in the Opening
Present but weak.
The GM claim exists in the role metadata line. The hero says you "led design and delivery." Both are true signals. Both are in the wrong place.
A hiring manager scanning this page forms their first impression from the headline and the first narrative paragraph. The role metadata line comes too late. "Designing for the worst day of someone's life" is a compelling emotional frame. It tells the buyer this is high-stakes, mission-critical work. It doesn't tell them you owned the mandate. By the time they reach the role line, they've already filed this as "strong designer, important project." You're fighting to upgrade that impression rather than setting it correctly from the start.
Keep the emotional headline. Move GM scope into the first narrative sentence so it lands before the buyer's mental model solidifies.
"I owned the product mandate, design strategy, and delivery path for a national disaster-relief platform: six legacy systems into one operational record, shipped in six months with a seven-person team, deployed nationally, and processing 1,689 cases in its first two weeks live."
Three things the current opening doesn't do that this sentence does: it puts "owned" before "designed," it names the team size to signal operating accountability, and it sequences the outcome as proof of the mandate rather than proof of the craft. The craft evidence follows, but the frame has to land first.
Criterion 2 — Constraints as the Design Problem
Present and effective. One upgrade available.
Strongest section on the page. The framing that the design problem was the operating environment, full stop, is exactly right. Federal disaster declarations, mass displacement, untrained volunteers, slow networks, six incompatible tools, federal audit pressure. The line "Every process bottleneck was a system failure" successfully reframes constraints from background into the core design challenge. This section works. Don't restructure it.
The upgrade: the section describes the constraint environment vividly but doesn't name the GM-level tradeoff you had to manage inside it. One sentence would close that gap.
"The product problem was deciding which complexity to remove from the interface, which to automate into the system, and which had to remain visible because federal accountability required it."
That sentence turns a vivid situation description into a decision framework. It tells the buyer you were making allocation decisions about where complexity lives inside a difficult environment. A small addition to an already-strong section.
Criterion 3 — Complexity in the System, Simplicity in the Interface
Present and effective.
The principle appears explicitly in the approach grid. Decision 01 (Field Volunteer intake) illustrates it concretely through a specific design decision the reader can evaluate: three fields instead of eight, auto-selection of program type, progressive disclosure, FEMA address verification, duplicate detection, rule-locking around Grey Sky versus Blue Sky assistance logic. Specific enough that a buyer can see the judgment. You show what was hidden, what was automated, and what error cascade the design prevented.
One of the few places on the page where the systems-design thinking is fully visible through a specific artifact decision. Protect it.
Strengthen the caption by making the operational cost of the alternative explicit:
"I removed five intake decisions from the volunteer path and moved them into event logic, FEMA feed matching, duplicate detection, and eligibility rules. One wrong program-type selection at intake would cascade into the wrong hardship code, the wrong assistance cap, and the wrong eligibility tier. Errors that surface during federal audit, not during the interaction."
That last line matters because it tells the buyer you designed for a failure mode the user would never see but the organization would pay for. And it directly enables the surge-readiness claim I'll address in Criterion 5: this is also why untrained volunteers could use the platform without training. Three fields and auto-selection didn't reduce complexity. They made training unnecessary by making wrong choices structurally impossible.
Criterion 4 — Three-Role Architecture Resolution
Present but weak. And there's a positioning inconsistency to resolve.
The page shows five role-specific surfaces: Field Volunteer, Caseworker, Supervisor, Finance Officer, Program Director. It says "Every role sees the same record." The six decisions walk through each role's view. But the architecture itself, the model that unifies these roles around a shared case record with permissioned decisions and audit events, is never named as a design problem or shown as a resolved system.
The buyer sees six well-designed screens. Without the architecture, the systems judgment that produced those screens stays invisible.
Second problem. Your published metrics say "3 roles unified." The walkthrough shows five distinct role surfaces. A buyer who notices will wonder whether you're simplifying for narrative convenience or whether the role model is genuinely more complex than the summary suggests. Either answer is fine, but the mismatch needs to be resolved on the page. If Field Volunteer, Caseworker, and Supervisor are the three core operating roles and Finance Officer and Program Director are permissioned extensions of the admin layer, say that. If the architecture actually unified five distinct roles, update the metric. The buyer who catches the discrepancy will read it as either imprecision or inflation, and neither serves you.
Add a short architecture section before the six decisions. Give the buyer the model before the screens:
"The architecture had to unify three operating modes: volunteers opening cases under surge conditions, caseworkers resolving family needs across multiple assistance types, and supervisors controlling eligibility, funds, and federal compliance. The resolution was one case record with role-specific surfaces, permissioned decision points, and audit events captured at the point of work. Finance and program-director views extended the supervisor layer with disbursement controls and command visibility."
Criterion 5 — Surge-Ready Design
Present but weak.
The claim is clear: "10× normal volume from day one," "No degradation," "No retraining required." Strong outcomes. The enabling decisions are scattered across the six role sections: progressive disclosure, one record, embedded FEMA documentation, urgency bars, batch approval, queue routing, command visibility. They're never gathered into a causal argument. The buyer sees the claim and the decisions separately. They have to do the synthesis themselves.
At this level, the buyer won't do that work.
Add a "What made 10× possible" block after Decision 06 or before the outcome metrics. Six bullets, each connecting a design decision to a surge-absorption mechanism:
- Three-field intake with auto-selected program type meant untrained surge volunteers could open cases without training, because the interface eliminated the decisions that required expertise. This is the "zero retraining" claim made auditable.
- Pre-selected disaster context reduced volunteer decisions at intake, removing the error cascade described in Decision 01.
- One case record eliminated cross-tool reconciliation during handoffs.
- Queue-based routing replaced supervisor case hunting under load.
- Audit fields captured during transactions, not in a separate compliance step.
- Director dashboards exposed cases, staff, funds, and compliance in one view, eliminating the reporting lag that creates decision delay during surge.
The first bullet matters most. The 10× claim has two legs: system architecture that absorbed volume, and interface learnability that absorbed untrained users. The architecture leg is impressive. The learnability leg is the one that proves GM-level design judgment, because it means you designed the intake to be structurally impossible to misuse rather than relying on training that wouldn't exist during a disaster surge. A design decision with organizational consequences. Name it.
Criterion 6 — Outcome Metrics and Timeline Context
Present but weak.
The metrics are strong and prominently placed: six months, $847K, six systems to one, 1,689+ cases, 98.7% FEMA compliance. The problem is that "six months" sits as a number without context. A buyer who has never shipped a federally constrained national platform doesn't know whether six months is fast, normal, or miraculous.
It's miraculous. You need them to know that.
Add a compact delivery-context line near the hero stats. One sentence that names what had to happen inside those six months:
"Six months compressed product definition, role architecture, Salesforce SLDS implementation, FEMA documentation logic, volunteer-ready intake, supervisor queues, payment audit trails, and national rollout into a single disaster-response cycle, with the platform processing live cases before the build was formally complete."
That last clause, if true, is the detail that makes six months land. If the platform was handling real disaster cases before the end of the six-month build, say so. You shipped incrementally into a live operating environment under federal oversight. Speed under consequence. The number needs the scope to land.
Priority Stack
Ordered by impact on your regulated-platform and mission-critical tier positioning:
- Fix the gate. The page delivers your most sensitive case content to unauthenticated requests. Every other recommendation is secondary until the page is actually protected. Server-side auth. This week.
- Opening sequence. Move GM scope into the first narrative sentence. The buyer's mental model forms in the first five seconds. Right now those five seconds say "important project, strong designer." They should say "owned the mandate, built the system, shipped nationally in six months."
- Architecture bridge. Add the role-architecture model before the six decisions. Resolve the three-role vs. five-role discrepancy. Without the bridge, the buyer sees six good screens. With it, they see the systems-design judgment that produced them.
- Surge causality. Connect the 10× claim to the enabling decisions, including the learnability argument that makes "zero retraining" credible. The evidence is already on the page. Gather it into one scannable block that makes the mechanism visible.
- Timeline context. One sentence that names what "six months" contained. The number needs the scope.
- Constraints tradeoff sentence. One addition to an already-strong section. Low effort, meaningful upgrade to the GM read.
The Agentic Section — Placement and Versioning
The 2026 "If I were building this today" section reframes the disaster-response problems as agentic-system challenges: surge load, eligibility complexity, multi-role coordination, federal compliance, client portal gaps, call-center errors, recovery after disbursement. Smart positioning for the AI-native tier.
It sits at the bottom of the page. After the buyer has already formed their impression.
Since this page is already gated (or will be, once you fix the gate), you have a practical decision to make. Two options:
Option A: Two versions. One for regulated-platform buyers (Maven, Abridge, Mercury) where the agentic section stays at the bottom as a forward-looking bonus. One for AI-native buyers where a condensed version of the agentic reframe surfaces as a callout after the architecture bridge, before the six decisions. The buyer who cares about agentic design will scan past six role-specific UI walkthroughs to find it at the bottom. Don't make them.
Option B: One version, different placement. Move a short agentic callout up after the architecture bridge in the single version, with a link to the full section at the bottom. This works if you don't want to maintain two pages, but it slightly dilutes the constraint-dissolution narrative for regulated-platform buyers who don't care about the agentic angle yet.
My recommendation: Option A. You're already sending this page selectively to specific buyers. Two versions costs you an hour. Sending the wrong frame costs you the read.
The page is close. The evidence is there. The craft is there. The frame that tells the buyer, before they start evaluating the work, that the person who did this owned the mandate — that's the missing piece. A sequencing fix, a role-model clarification, and a causal-argument upgrade. The hardest part is already done.
- Headway's clinical AI stakes: Headway's Design Director, Provider Experience posting names EHR strategy, clinical documentation, and AI-centered workflows, making the Red Cross constraint-dissolution narrative a natural lead for that room.
- Ramp's agentic design vocabulary: Ramp's Director, Product Design role says design is now building tools and agents, designing memory, and defining how design works in an AI-native world, which maps directly to the CS-03 agentic redesign section if it gets moved up for AI-native buyers.
- NIST's trust infrastructure language: NIST released a concept note for Trustworthy AI in Critical Infrastructure in April 2026, and the Red Cross case's federal-accountability framing could borrow that vocabulary for enterprise AI cover letters.
- Client-side gating across all cases: The same
localStorageaccess-control pattern confirmed on CS-03 was also detected on all five full case URLs, meaning the server-side fix needs to cover the entire gated portfolio, not just this page.