CS-01 Alibaba Full Case Audit — Strong Work, Wrong Frame

Current-State Verification

Three issues flagged in prior audits. Status as of July 19, 2026:

Title gap: still open. The teaser says "Redesigning B2B Trust at $50B+ GMV." The full case says "Alibaba.com Site Refresh — Signal View." A panel member who opens this after you've left the room sees "Site Refresh" and mentally files it as execution work. Flagged July 10. Not fixed.

Teaser density: Still 16 component-atlas rows, the Section III-to-V numbering gap, CTA placed before proof rows. Prior finding stands: the first half earns the click, the second half loses it. No visible structural changes.

Metadata: The og:description still omits "−47% buyer-reported security concerns." When someone drops this link in Slack, your strongest trust-design metric is invisible.

Client-Side Gating Check

Flagged P1 in the site-gating audit. The redirect is better than the overlay used on the private essay (that was P0), but the underlying problem is the same: protected content ships in the initial response. You share this case selectively, after an interview is booked, with a specific evaluator. It is supposed to be private until that moment. It is not private. Move content behind a server-side check or accept that everything in this case is effectively public. That decision should shape what you include.

Six-Point Audit

1. Problem Diagnosis

What's there. The hero opens with "desktop was 25% of traffic and 80% of transaction value." The platform was designed for consumer browsers while procurement buyers were the actual revenue users. You state you "named the gap, built the research case, secured the mandate, and redesigned it." Chapter 01 breaks the diagnosis into three discovery cards, each linked to a sprint.

Assessment. The 25%/80% split is a business-logic gap, not a design observation. Good. The first-person mandate language is what a panel needs. The three discovery cards are well-structured.

But the diagnosis reads as context-setting. Not as an argument you had to win. "Named the gap" is a claim. The panel wants proof that this gap wasn't already sitting on a roadmap somewhere. Was desktop deprioritized because mobile was the growth bet? Did you have to convince someone that 80% of transaction value justified a redesign when three-quarters of traffic pointed the other direction? The section implies a mandate fight without showing one.

And it misses the real stakes. This diagnosis is actually about a specific kind of human-judgment failure: procurement buyers committing real inventory spend through a platform built for consumers browsing products. That framing positions you as someone who recognized a mismatch between the decision stakes and the decision environment. It's absent. You're describing a traffic/revenue gap when you should be describing a trust-architecture gap.

Recommendation. Add one sentence after the 25%/80% line naming the organizational resistance and one naming the human-judgment problem. Structure: here's what the org believed, here's what I showed them, here's what changed.

First sentence proves you won a mandate. Second tells the panel why the mandate mattered.

2. Research Methodology

What's there. 32 cross-functional interviews, a Baymard audit, gaze tracking on $500+ order sessions. Each discovery card cites a specific finding: 37-point sign-in gap, 73% session non-engagement, 47% security fears at payment.

Assessment. Methods named. Findings quantified. You're ahead of most Director-level cases I've reviewed. But the section reads as "here is the research we did" rather than "here is how research changed a decision." At Director+, the panel already knows you can run research. They're evaluating whether you know how to use it as leverage.

"32 cross-functional interviews" is a number without a story. Who did you interview? If those interviews included executives who controlled the roadmap, say so. If they included procurement buyers across different spend tiers, say so. The number 32 is process documentation. "32 interviews including the VP of Product, three enterprise procurement leads spending $200K+ annually, and the payments team lead who owned the inquiry-to-order funnel" is mandate-building evidence. It tells the panel you knew which stakeholders had to be in the room before you could move.

Recommendation. Replace "32 cross-functional interviews" with a one-line stakeholder map. Who, at what level, what it unlocked that wasn't known before. The Baymard audit and gaze tracking are fine as named methods. The interviews need to show political intelligence, not sample size.

3. Design Decisions

What's there. Three sprints, each structured as diagnostic failure → design bet → measured outcome. Before/after screenshots with callouts. Sprint 01: B2B positioning above the fold, browse-first entry, personalized returning-buyer state. Sprint 02: card-level trust signals, Response Rate and OTD as primary sort controls. Sprint 03: tier pricing, live order calculator, Trade Assurance in the primary scan zone.

Assessment. Sprint structure is sound. The diagnostic-to-bet-to-outcome arc is right. The problem: screenshots and callouts are doing the work that rationale sentences should be doing. "Response Rate and OTD became first-class controls" tells the panel what you built. It does not tell them why you chose this over the alternatives.

Sprint 02 is the clearest gap. Making Response Rate a primary sort control is a significant bet. It privileges supplier responsiveness over price. That is a hypothesis about what procurement buyers actually optimize for when they're spending company money on cross-border inventory. The fact that 34% of sessions sorted by Response Rate in the first month is powerful validation. But the case presents this as a feature addition rather than a design hypothesis about buyer decision-making under information overload.

Say what you actually did. You designed the heuristic that procurement buyers use to narrow 200K+ suppliers to a shortlist. You bet they would optimize for supplier reliability over price. You were right within a month. That is a design decision about how humans make fast-and-frugal judgments when the option set is too large to evaluate comprehensively. Name it.

Recommendation. Add one sentence before each sprint's screenshots stating the design hypothesis in decision terms. Sprint 02: "We hypothesized that procurement buyers, unlike consumers, would sort by supplier reliability signals over price. We made Response Rate and OTD first-class sort controls to test this." Then the 34% stat lands as validation of a bet, not a usage metric.

4. IC+Manager Proof

What's there. Role stated as Head of Design & Research, North America. Team listed as Design · Research · PM · Engineering. The hero says you named the gap, built the research case, secured the mandate, and redesigned it. No named collaborators, no org chart, no specific account of cross-functional leadership.

Assessment. Weakest point in the case. A Director+ panel evaluates two things simultaneously: can you do the work, and can you lead the organization that does the work? This case proves the first. It barely gestures at the second.

"Design · Research · PM · Engineering" is a list of functions. Every design leader at a company with more than fifty people works with those functions. The panel needs specifics. How large was the team you led directly? Who did you influence without authority? Was the PM in Sprint 01 who worried about sign-in drop someone you managed or someone you had to persuade?

That Sprint 01 tradeoff ("The PM worried sign-in would drop") is actually the closest thing to IC+manager proof in the entire case. It shows you navigating a stakeholder objection. But it's a single sentence buried in a sprint section. It's doing no structural work.

Recommendation. Add a leadership-context block before the sprints. Three lines:

1. Team composition and size. "Led a team of X designers and Y researchers; partnered with PM and engineering leads across three workstreams."
2. Who you influenced without authority and on what decision. "Secured executive buy-in from [role] to reprioritize desktop after presenting the 80% transaction-value finding."
3. What the outcome tells the panel about how you operate. "The sprint structure itself was a mandate artifact: three parallel bets required cross-functional alignment I built, not inherited."

That's the difference between listing partner functions and proving you led through them.

5. Tradeoffs

What's there. Sprint 01 includes one explicit tradeoff: the PM worried sign-in would drop after removing the EIN wall; sign-up went up 4%. Sprints 02 and 03 have no visible tradeoff, no alternatives-considered pattern.

Assessment. One tradeoff across three sprints tells the panel that either you didn't face hard decisions at Alibaba's scale (unlikely) or you aren't showing them. Neither reading helps you. Director+ panels look specifically for evidence that you can make decisions under constraint. A case with no tradeoffs reads as a case where everything went right. That reads as sanitized.

Sprint 03 is the obvious gap. You moved tier pricing above the fold and put a live order calculator in the primary scan zone. You designed the evidence layer a buyer uses to commit $50K+ of inventory spend to a supplier they've never met, in a cross-border transaction, based on platform-mediated trust signals. Did transparent pricing conflict with the sales team's inquiry-based model? Did suppliers resist having response rates and on-time delivery exposed as sortable metrics? There is a tradeoff story here. The case hides it.

Recommendation. Add one explicit tradeoff to Sprint 02 and one to Sprint 03. Two sentences each: "We considered [alternative]. We chose [decision] because [reasoning]." Four sentences total will shift this from output showcase to decision showcase.

6. Agentic Sourcing Vision

What's there. Chapter 03, "If I were building this today," extends the same three surfaces into an agentic sourcing loop. Natural-language chat becomes a structured brief. The agent traverses Search and PDP, evaluates trust signals, completes the transaction autonomously. A human decision gate shows three options: Place order, Request sample first, Compare more suppliers.

Assessment. The human decision gate is the single strongest design artifact in the entire case. Three buttons representing three different confidence levels a buyer might have after an AI-mediated sourcing loop. That is a design decision about human judgment under uncertainty. It is the kind of thinking that separates a Director candidate from a senior IC.

But there's a contradiction that undermines it. The lead paragraph says "the AI decides what, when, and how to pay" once buying signals clear. The human decision gate shows the buyer deciding. If the AI decides, the gate is theater. If the buyer decides, the AI is an advisor. The distinction matters because it is the core design question in agentic systems: where does the human stay in the loop, and why?

As written, the contradiction makes this read as speculative appendix. The vision isn't internally coherent enough to land as a design POV. Resolve the contradiction and it becomes the strongest section in the case.

Recommendation. Cut "the AI decides what, when, and how to pay." Replace with language that centers the human decision gate as the design problem: "The agent does the traversal. The buyer makes the commitment. The design question is what the buyer needs to see at the moment of commitment to trust the agent's work." That positions you as someone who has thought about the hardest problem in agentic design, not someone who defaulted to "AI does everything" because it sounds forward-looking.

The Frame That Ties All Six Points

Three moments in this case are design decisions about human judgment under uncertainty. All three are currently framed as UX improvements.

Sprint 03 is a layout decision until you name it as designing for high-stakes commitment under uncertainty. Sprint 02 is a filter addition until you name it as designing the decision heuristic for narrowing 200K+ suppliers under information overload. The human decision gate is a wireframe until you name it as the question every agentic system has to answer: what evidence does a human need to trust an agent's recommendation enough to commit real money?

Thread this language through all three moments and the case stops reading as a project description. It reads as a design leadership philosophy.

That sentence transfers to any company building AI-mediated decision systems. That transfer is what a panel remembers after they've closed the tab.

Prioritized Action List

Fix before the next panel opens this case:

• Retitle the full case. Kill "Alibaba.com Site Refresh — Signal View." Use "Redesigning B2B Trust at $50B+ GMV." The teaser already uses it. Match it.
• Add one tradeoff each to Sprint 02 and Sprint 03. Two sentences per sprint. Alternatives considered, reasoning shown. Fastest path from output showcase to decision showcase.
• Resolve the agentic contradiction. Cut "the AI decides what, when, and how to pay." Center the human decision gate as the design problem. This is the line between speculative appendix and forward-looking POV.

Fix within the week:

• Add a leadership-context block. Three lines: team composition and size, who you influenced without authority and on what decision, what the outcome reveals about how you operate at the IC-manager intersection.
• Reframe the three human-judgment moments. One sentence per sprint naming the decision the buyer is making, not the interface change you shipped.
• Break down the 32 interviews. Replace the number with a stakeholder map. Who, at what level, what it unlocked.

Fix when you can:

• Fix the client-side gate or accept that this content is public. Server-side content withholding is the only real solution.
• Update og:description on the teaser to include the −47% security-concerns metric.
• Add a meta description to the full case. It currently has none.

This case has strong bones. The 25%/80% diagnosis, the three-sprint structure, the agentic vision with a human decision gate. What's missing is the framing that tells a Director+ panel why these decisions required a design leader and not just a designer. The work proves you can do it. The framing needs to prove you understood what you were doing while you did it.