I am currently taking CS 147 as well, which is the Introduction to HCI class here at Stanford. These past two weeks we have explored a design process that follows these 4 parts: Discovery, Design Exploration, Design Refinement, and Exploration, where the first two form the Design Thinking process with its phases: Empathize, Define, Ideate, Prototype, and Test. We have spent considerable time learning about Needfinding—discovering opportunities by recognizing gaps within a system.
This process differs from the article’s approach in three key ways. First, the focus of CS 147’s design process has been on discovery and creation: finding the right problem, ideating solutions, and prototyping. The article, however, emphasizes shared understanding and outcomes—ensuring everyone remembers the “why” behind what we build. Second, the success measures differ. In CS 147, we ask: “Did we build a validated prototype that solves a real need?” The article reframes this: “Did we minimize output while maximizing outcome and impact?” This distinction is crucial—validation doesn’t guarantee value creation. The last difference is in collaboration. Design Thinking can become designer-centric, with phases producing deliverables that get handed off to developers. The article warns this creates a “telephone game” where meaning gets lost in translation. As Patton emphasizes, “shared documents are not shared understanding.” Story mapping prevents this by having designers, developers, and PMs build the map together. This collaborative process creates shared understanding that survives beyond any document.
However, these approaches complement each other powerfully. Design Thinking excels at early-stage discovery—the deep immersion and observation needed to uncover genuine user needs. Story mapping then bridges design into development, preventing information loss during handoffs. While Design Thinking helps us discover “what” users need, story mapping ensures we build the “minimum” necessary to create maximum impact while keeping the team aligned on “who” and “why”.
The article’s most provocative insight challenges a core Design Thinking assumption: just because we’ve empathized, defined, ideated, prototyped, and validated doesn’t mean we should build everything. Output—what we build—isn’t the goal; outcome—the behavior change and value created—is what matters. Story mapping forces ruthless prioritization even after validation, asking: “What’s the minimal slice that delivers real outcome?”
Integrating these approaches means using Design Thinking for discovery and validation, then transitioning to collaborative story mapping before development. The map becomes a living artifact the team references throughout development, measuring success not by shipping features but by creating impact. As Patton notes, good story conversations focus on “who and why, not just what”—keeping the user’s story alive prevents it from degrading into a checklist of features. This integration transforms design from a phase that ends at handoff into shared understanding that persists through delivery and beyond.
