CS-01 Alibaba.com — Full Case Audit for Interview-Panel Readiness

Access state

The page delivers full HTML before the client-side localStorage gate fires. Same pattern diagnosed in the July 4 proof-gates analysis: the content is public, the gate is cosmetic, and the dissonance between "PRIVATE ACCESS" framing and actual delivery creates a credibility problem for a candidate whose positioning rests on trust architecture. Fix the gate or remove it. Both are better than the current state. On to the case.

How a panel reads this

A Director+ interview panel does not read a case study the way a design peer does. A peer evaluates craft. A panel evaluates six things craft alone cannot prove:

1. Did she find the problem or inherit it?
2. Did she use research to build organizational permission?
3. Did she sequence work strategically?
4. Did she lead people?
5. Did she make hard calls with visible reasoning?
6. Does she have a point of view on where this goes next?

The Alibaba case is strong raw material. The 25%/80% diagnostic insight is genuinely good. The metrics are specific and credible. The sprint structure is clean. But as currently written, the case reads closer to a senior IC's best work than a design leader's. The gap is narrow, and closing it means shifting what carries weight in sentences that already exist.

Each criterion, in reading order.

1. Problem diagnosis ownership

Verdict: partially met

What's there. The hero section states the diagnostic insight up front. Desktop was 25% of traffic but 80% of transaction value. The platform was designed for consumer browsers while the actual users were company procurement buyers. The page includes the phrase "I named it" in reference to the gap. The 37-point sign-in deficit below app appears in the first-impression discovery section.

What a panel needs. "I named it" is a claim. A panel member who has interviewed eight candidates this quarter has heard some version of "I identified the real problem" from all of them. What separates a claim from a demonstration is the before-state. What did the organization believe before Juno's diagnosis? Was the prevailing explanation "desktop is dying, invest in mobile"? Was it "the desktop UI needs a visual refresh"? The distance between the organization's prior frame and Juno's reframe is where ownership becomes visible to a reader who wasn't in the room.

Direction. Add one or two sentences before the diagnosis that establish what the company believed the problem was. "The prevailing assumption was X. The data said something different." This lets the reader reach the conclusion that Juno named the problem, rather than being told she did.

Pull the 37-point sign-in gap up into the diagnostic frame. Right now it sits in the first-impression discovery section, where it does inventory work rather than argument work. That number is the sharpest single proof that the platform was failing its own users in a way the organization hadn't articulated. It belongs where the argument is being made.

2. Research as mandate-building

Verdict: partially met

What's there. 32 cross-functional interviews. A Baymard audit. Gaze tracking on $500+ order sessions. A buyer quote comparing the homepage to a flea market.

What a panel needs. The research currently reads as a methods inventory: we did these things, we found these things. At Director+ level, a panel needs to see research as an organizational tool. Who commissioned the 32 interviews? If Juno initiated them, that's a leadership signal. If they were already planned, it's execution. Did gaze tracking exist before she arrived, or did she argue for it? The Baymard audit is a specific, credible external benchmark. Did she bring it in to create shared language with stakeholders who didn't trust internal research?

The page answers none of these questions.

Direction. For each research input, add one clause establishing whether Juno initiated or leveraged it, and what organizational function it served. The difference in practice:

versus

The second version shows the same research activity doing organizational work. Three words change the sentence from a methods line into leadership evidence.

The flea market buyer quote is excellent. Consider whether it belongs earlier, positioned as the moment that crystallized the diagnosis for stakeholders. A single buyer quote that lands in a leadership meeting can do more organizational work than a 40-page research deck. If that's how it functioned, say so.

3. Sprint rationale

Verdict: missed

What's there. Three diagnostic failures became three sprints: first impression, search, transaction. The organizing line is "Research signal → design bet → measured outcome."

What a panel needs. Clean structure. Incomplete for a panel audience. Why this sequence? Homepage first seems intuitive, but a reasonable alternative exists: fix the PDP first because that's where transaction confidence breaks and revenue impact is most direct. Another reasonable path: fix search first because 73% session abandonment means most users never reach the PDP.

The fact that Juno chose homepage → search → PDP suggests strategic logic. Maybe dependency-based: if the homepage doesn't signal B2B credibility, improving search is irrelevant because users bounce before they get there. Maybe organizational: the homepage sprint was the fastest win to build internal confidence for harder work downstream. Maybe data-driven: the 37-point sign-in gap represented the largest recoverable audience.

A senior IC runs the sprints. A design leader decides which sprint runs first and can explain why. That reasoning is absent.

Direction. Add a single paragraph between the diagnostic section and Sprint 01. Two to three sentences. "We started with first impression because [reason]. Search before PDP because [reason]." This is one of the highest-leverage additions in the entire case. It's where a panel sees strategic sequencing rather than project execution.

4. IC+manager proof

Verdict: missed

What's there. The case metadata says Head of Design & Research, North America. The team line names Design, Research, PM, and Engineering. Sprint 01 includes a PM concern that sign-in would drop when the EIN wall changed.

That PM concern is the single moment in the entire case where another human being appears with a point of view that differs from Juno's. One moment, across three major sprints on a $50B+ GMV platform.

What a panel needs. How large was the team? Did she hire anyone? Did she set the research agenda or delegate it? When the PM raised the sign-in concern in Sprint 01, what happened next? Did Juno run a test to resolve it? Make the call over the PM's objection? Negotiate a compromise metric? Each answer reveals a different leadership pattern. The panel currently gets none of them.

Sprint 02 reports that 34% of sessions sorted by Response Rate in the first month. Strong adoption metric. But who decided Response Rate belonged in primary sort rather than a sidebar filter? Did engineering push back on the data pipeline work required? Did the PM want to prioritize a different metric?

The design decisions are visible throughout the case. The organizational decision-making that surrounded them is almost entirely absent.

Direction. One cross-functional moment per sprint. A sentence or two that names a role, a disagreement or dependency, and how it resolved.

• Sprint 01: The PM concern is already there. Extend it. "PM flagged sign-in risk. We agreed to [specific resolution]. Result: sign-up rose 4%."
• Sprint 02: Who decided Response Rate belonged in primary sort? What did that require from engineering?
• Sprint 03: Putting tier pricing inline meant removing the inquiry wall. Who owned that decision? What was the business objection?

These additions are small but their effect on panel perception is disproportionate. The case needs to read as "I led the team that shipped this, and here's one moment per sprint that proves it."

5. Tradeoffs

Verdict: missed

What's there. The PM sign-in concern in Sprint 01 is the closest thing to a visible tradeoff. Removing the EIN gate risked sign-in drop. The outcome was sign-up rose 4%. But the structure is concern → outcome, skipping the middle: concern → alternative considered → decision rationale → outcome.

Sprints 02 and 03 have no visible tradeoffs.

A tradeoff requires a fork in the road where the reader can see both paths and understand why one was chosen. Right now the reader sees the path taken and the result. The path not taken is absent.

Direction. Pick Sprint 03, where the stakes are highest. Show the alternative. The fork: surface tier pricing inline or keep it behind inquiry to protect supplier negotiation leverage. The rationale should connect to specific evidence (gaze tracking data, buyer interview findings, the tab-switching behavior that showed buyers leaving the platform to check prices externally). The mitigation should name how the supplier-side concern was addressed.

One fully rendered tradeoff does more for panel credibility than three partially rendered ones. And note: when you write the Sprint 01 cross-functional moment (priority 1 below), you're already building tradeoff material. The PM sign-in concern is both an IC+manager moment and a tradeoff seed. Extend it rather than creating a separate tradeoff section. That keeps the case tight and avoids the feeling of bolted-on leadership theater.

6. Agentic sourcing vision

Verdict: partially met

What's there. The forward-looking section extends the three case surfaces into an AI agent loop: natural language brief → structured sourcing query → supplier qualification → price math → order completion. The mockups use specific parameters (500 custom water bottles, ≤$10/unit, ≤20-day lead time, Trade Assurance required) and show the agent traversing the same trust signals Juno designed in the manual experience.

Better than most vision sections. The trust signals from Sprint 02 (Trade Assurance, Response Rate, OTD) become the agent's evaluation criteria. The inline pricing from Sprint 03 becomes the agent's math layer. The structural connection to the case evidence is real, not decorative.

What's missing is the design-leadership position. The section shows what an agentic sourcing experience could look like. It does not say what Juno believes the hard design problems are in building it. A panel evaluating someone for a company working on AI-mediated transactions wants to hear: Where does automation break trust? When should the agent defer to the human? What happens when the agent's supplier recommendation is wrong and the buyer placed a $50,000 order?

The trust architecture Juno built for the manual experience becomes the governance architecture for the agentic one. That argument is implicit in the mockups. It needs to be explicit in words.

Direction. Add a closing paragraph after the mockups that names the design problem the vision creates. The argument to make: trust signals designed for human scanning now need to function as machine-readable decision criteria, and the design problem becomes reliability and failure handling at scale. Connect it backward to the sprint evidence (the specific signals she designed) and forward to the problem automation introduces (what happens when the agent evaluates those signals incorrectly at scale). Two to three sentences. That's what turns a vision mockup into a design-leadership position. Let the specifics come from the case evidence she already has.

Priority stack for one editing session

1. IC+manager proof across all three sprints. One cross-functional moment per sprint, two sentences each. This is the single change that most shifts how a panel categorizes the case. When writing the Sprint 01 moment around the PM sign-in concern, extend it into a full tradeoff rather than stopping at the concern. That one addition does double duty across criteria 4 and 5. Thirty minutes.

2. Sprint sequencing rationale. One paragraph between diagnostic and Sprint 01. Why this order. Fifteen minutes.

3. One fully rendered tradeoff, Sprint 03. Alternative considered, decision rationale, mitigation. If the Sprint 01 cross-functional moment already produced a complete tradeoff, this becomes the second. Twenty minutes.

4. Agentic vision closing argument. Two to three sentences naming the design problem automation creates, connected backward to sprint evidence. Fifteen minutes.

5. Problem diagnosis before-state. What the organization believed before Juno's reframe. Pull the 37-point sign-in gap into the diagnostic frame. Ten minutes.

6. Research mandate signals. One clause per research method establishing initiation and organizational function. If time remains.

The case has strong bones. The metrics are specific. The diagnostic insight is differentiated. The agentic vision is structurally grounded rather than bolted on. The layer it still needs is organizational leadership — the kind that separates a well-designed case from a strategically led one. That layer requires a series of small additions, most of them one or two sentences, that change what the existing evidence proves about who Juno is in a room.