Hypothesis-Driven DesignStructured Design Activities That Bring Ambiguity into Focus

Our library is maxing out Figma’s load times. High-fidelity prototypes are piling up without real-world input. We keep documenting components that never see production. But we’re following a six-month-old plan—so by the time we finally learn something’s off, it’s also painfully expensive.
These charts illustrate a design team operating “two sprints ahead” of engineering. Over six months, we tracked developer commits linked to UI assets and prototypes. While assets and prototypes multiplied early, linked commits spiked only near the deadline—revealing a last-minute scramble and ballooning design debt.
Tracked assets represent UI elements slated for production; untracked items are extras that piled up without developer buy-in. Their rapid growth shows how “working ahead” can inflate the backlog with unused designs.
Tested prototypes remained static, while untested versions grew exponentially. This indicates minimal real-world validation, with the team continuously creating new designs without user or stakeholder feedback.
Background

Turn Trash into Treasure with a Framework for Educated Guessing

Overstuffed Figma libraries and untested prototypes aren’t just a Design System dysfunction; they’re symptoms of a larger misalignment between user needs, business goals, and development realities. Simply tidying up components or documenting styles won’t fix the root cause. To truly reduce waste—and turn ‘trash’ into treasure—teams need a structured way to validate assumptions, tackle high-risk ideas first, and align on what matters. Sometimes, it’s about reining in egos before pouring millions into a billionaire’s vanity project.
What follows is a deep dive into two real-world enterprise design workshops, each demonstrating how specific design activities can help product teams build the right tools for their users—dignifying the human in the labor loop, rather than treating them as an afterthought. This workshop helped Allstate realized they needed deeper ML expertise before coding anything and PG&E integrated the methodology into their daily work to the delight of their users. In both cases, we relied on a standardized workshop model (inspired by Lean UX) to reorient teams around real user needs, yet the contexts, participants, and room coaches varied.

Allstate

Our sponsors had already decided to build custom software powered by a so-called AI sales coach named “Winston.” Despite labeling it “AI data readiness,” the push for high-fidelity UI prototypes suggested a premature commitment to a solution, lacking thorough validation of underlying data and user needs. This stood out as a significant risk to the engagement, potentially derailing the workshop’s focus on hypothesis-driven design.

Workshop

Product: Realtime Sales Performance Dashboards with a Coaching AI
Format: A week-long series of interactive sessions conducted via live remote videoconferences
Participants: 2 Sponsor Product Owners, 2 Technical Stakeholders, 2 Operational Stakeholders, 2 Sales Coaches, 2 Sales Agents
Design Facilitation: 1 Facilitator + 2 Room Coaches

My Role

I facilitated this workshop, authored a facilitation script and structured the core design activities. These materials guided live discussions, kept the group focused on user needs and managed each session’s timeframe. My facilitation and our activities were evaluated both by participants and room coaches at the end of each session.

Pacific Gas & Electric

PG&E oversees a complex mix of physical and virtual network assets through custom tools. A prior product owner’s disregard for user experience resulted in a disjointed system that lacked adoption. The new sponsors recognized a metrics-first reinvention was crucial—perfectly aligned with our hypothesis-driven approach, ensuring real user needs were validated.

Workshop

Product: Inventory tracking physical hardware and virtual power grid and networked assets.
Format: A week-long series of interactive sessions conducted via live remote videoconferences
Participants: 1 Sponsor Product Owners, 1 Technical Director, 2 Network Ops Stakeholders, 4 Network Engineers
Design Facilitation: 1 Facilitator + 2 Room Coaches

My Role

I coached this workshop, observing the delivery of my facilitation script and more directly guiding design activities I'd structured. I rated the performance of the facilitator and the workshop activities, while mine was evaluated both by participants and the other room coach at the end of each session.

The Situation

Designing In-House Tools for the Enterprise of the Future

Many large enterprises have the resources—and often the conviction—to insist on building their own in-house tools, believing these custom solutions will perfectly solve their unique challenges. Yet in practice, most rely on specialized consultants to produce expensive, technical recommendations and high-fidelity and mockups. These "solutions" often serve more to appease project sponsors than to validate real user needs.‍

Over time, these high-fidelity assets can balloon into weeks of stakeholder presentations and precise Gantt manufacturing schedules—with each milestone increasingly disconnected from the project’s true user outcomes. In the end, these teams wind up with a highly organized, unvalidated backlog that reflects little more than assumptions from the project’s inception.

MacBook mockup
Our  Hypothesis

"We believe we can reorient enterprise teams around real user value through a series of guided design workshops."

TASKS

Guide workshop participants to:

  • Systematically identify, discuss and prioritize assumptions to test
  • Build empathy for and work directly with real users  of a tool or as part of a business process
  • Build a process map that identifies key opportunties to influence outcomes of the process
  • Formulate testable hypothesis statements
  • Design the least expensive prototype required
  • Test their experiments and present findings
Colorful gradient
Prework

Aligning Participants

Before each workshop, we help unify sponsors and stakeholders around a single definition of the problem they intend to solve. We guide them in discussing product goals and crafting an unambiguous core problem statement via a low-barrier, fill-in-the-blank approach. We then use this problem statement to focus a survey aimed at learning and establishing a baseline for stakeholder beliefs.
Mockup

Problem Statement Framework

A collaborative problem-framing session aimed at aligning project sponsors and the workshop facilitation team on the project’s direction and scope. We used those insights to shape the assumptions survey, both reflecting and validating the focus areas defined in the initial problem-framing session.

UI Mockup

Assumptions Survey

Our survey falls under exploratory, generative research—specifically a form of stakeholder assumption mapping (or assumption-based research) intended to discover stakeholder beliefs and gauge how risky or impactful those beliefs might be.

The chart visualizes real survey responses (hover over the bubbles), where mean (μ) and standard deviation (σ) for "Value" and "Risk" ratings were used to calculate Z-scores, normalizing the data. Duplicate responses were averaged, and an "agreement" factor, calculated using the Intraclass Correlation Coefficient (ICC), affecting their relative size in the chart.

Expert-Guided Affinity Mapping

Under the guidance of our design research specialists, we took a quantitative approach to mapping each stakeholder’s assumptions. This method goes beyond “gut-feel” prioritization by effectively normalizing every data point on a shared scale. We also factored in a standard measure of agreement among respondents—to emphasize which assumptions had widespread consensus.

How it works

  • Duplicate Responses: Averaged into a single data point, ensuring we don’t artificially inflate certain assumptions.
  • Bubble Size: Driven by the ICC, so highly agreed-upon assumptions appear larger.
  • Risk vs. Value: The chart’s X-axis represents urgency (Risk), while the Y-axis captures importance (Value).
The Workshop

Activities & Outputs

Before we dive into each phase of the workshop, let’s take a high-level look at how we structured the work. Our goal was to ensure that every activity (or “action”) led to a meaningful output, something that would directly inform the next phase. Rather than creating deliverables for their own sake, we focused on tangible artifacts that documented team agreement, clarified user needs, and drove the future product strategy.
Empathy map divided into four quadrants labeled Says, Thinks, Does, and Feels. Each quadrant contains sticky notes with different insights about the user named Jason, who is in the center of the map. Jason is shown as a person looking at computer screens. The Says quadrant includes questions and statements Jason might verbalize. The Thinks quadrant contains internal thoughts and concerns. The Does quadrant lists actions and tasks Jason performs. The Feels quadrant describes Jason's emotions and feelings related to his tasks.

Discovery & Empathy

We began by establishing the project’s real context: who uses the tool, why they rely on it, and which tasks matter most. Stakeholders collaborated with real (or proxy) end-users to map out key pain points, culminating in a proto-persona and journey map centered on a representative user role.

We gauged success by confirming that sponsors, engineers, and design leads were aligned on the user’s primary concerns and goals. By the end of this phase, each team had identified at least two “moments that matter,” creating clear opportunities to reduce friction and validate assumptions in later workshop steps.

Hypothesis Framework Objective: We believe we can decrease resolution time by thirty minutes. - Should contain a measurable goal you want to achieve. Persona: If users like Jason (image of Jason, a network engineer, working on a computer with code on the screen) can have... - Key user archetypes for whom the solution is being designed. Outcome: A complete understanding of outage impact on assets. - Specific change in user behavior or experience that you aim to achieve. Solution: With a network connectivity diagram. - Feature that you believe will achieve the desired outcome. Test Framework Conditions: We’re good if within five minutes during a usability test... - Specify the parameters within which the experiment will be conducted. Proof: This happens if participants can identify the cause of an incident. - The observation that will indicate objective success.

Hypothesis Generation & Prioritization

We took the moments that matter most and used them to write testable hypotheses—structured statements like, "We believe we can achieve [business outcome] if users like [proto-persona] can get [user outcome] from [feature]." This forced sponsors, engineers, and designers to align on which assumptions truly mattered. Rather than letting a wish list dictate the backlog, we prioritized the highest-risk, highest-value ideas first.

We guaged success by confirming each hypothesis was written in an unambiguous manner, ensuring it tied directly to user needs and delivered a measurable business outcome. Each team selected at least one hypothesis to focus on, producing a concrete backlog of top-priority features to explore.

Empathy map divided into four quadrants labeled Says, Thinks, Does, and Feels. Each quadrant contains sticky notes with different insights about the user named Jason, who is in the center of the map. Jason is shown as a person looking at computer screens. The Says quadrant includes questions and statements Jason might verbalize. The Thinks quadrant contains internal thoughts and concerns. The Does quadrant lists actions and tasks Jason performs. The Feels quadrant describes Jason's emotions and feelings related to his tasks.

RAPID PROTOTYPING & TESTING

As each team homed in on one critical user flow or key interaction to validate, a product deign lead (me) worked directly with them to develop streamlined, interactive prototypes.

Before investing in a full-scale research program, we used hallway testing—recruiting representative users from within the organization—to gather timely, targeted feedback on each concept. In Lean UX terms, this is where we transform our riskiest, most valuable assumptions into a testable hypothesis and specify success criteria that clarify exactly what we need users to do to prove we’re on the right or wrong track.

The Results

From Assumptions to Evidence with a Fractional Investment into Best Practices

Success of each workshop was determined by each team’s ability to learn quickly: they balanced speed and rigor by creating a concise test plan and defining a measurable outcome tied to their hypothesis (e.g., “Users must complete the task in under 2 minutes” or “80% of testers must find the AI recommendations intuitive”). At the end of the workshop, each team presented actionable insights based on real user reactions, along with concrete next steps—ensuring that every decision moving forward was grounded in evidence, not guesswork.

Prioritized Assumptions

Every participant team produced an assumption backlog, ranking each belief by risk and value. This ensured resources went to testing the highest-impact concerns first.

Real User Engagement

Both organizations involved actual or proxy end-users early and often—through empathy mapping, journey discussions, or targeted prototype testing.

ClearER Documentation

In mapping user flows, each team pinpointed at least two “moments that matter” where the tool or AI solution could significantly reduce friction

Hypothesis Framework

Teams translated assumptions into We believe we can achieve [Business Outcome] if users like [Proto-Persona] can [User Outcome] with [Feature].—aligning design, engineering, and business around measurable outcomes.

SCALABILITY

Originally a two-week workshop, we compressed our Lean UX format into a five-day remote model with pre-work and daily outcomes. This let cross-functional teams engage without stepping out of delivery.

Integration

At Allstate, the product Waterfall ran ahead of dev with scenarios and synthetic data. PG&E extended the model, deepening hypothesis development alongside test-driven development and their Agile practices.

While the workshop’s primary aim was to de-risk design by validating assumptions early, the final deliverables went beyond sticky notes and user maps. Each team received polished UI artifacts derived directly from the highest-priority hypotheses. These interactive screens, which aligned to actual data availability by delivery phase (as illustrated in our milestone-based rollout), gave clients something concrete to share internally—sharpening executive conversations and helping win support for follow-on investment.