Skip to main content

Documentation Index

Fetch the complete documentation index at: https://userstory.zeroemdashes.com/llms.txt

Use this file to discover all available pages before exploring further.

Most prototyping advice presents a binary choice: lo-fi wireframes or hi-fi mockups. In practice, the most useful prototypes are often neither - they’re hybrids that combine real, working parts of your product with mocked or simulated elements that don’t exist yet 🔧 Hybrid prototyping is exactly that. You stitch together what’s real with what’s fake to create something testable without building everything from scratch.

​
What it looks like

A few common patterns: Real UI, fake data - You use your actual product interface but populate it with carefully crafted fake data that simulates a scenario you want to test. Useful for testing how users respond to a new type of content or information without building the data pipeline first. Real flow, mocked steps - The user navigates through your real product until they hit the feature being tested - at which point they’re handed off to a static mockup or Figma prototype. Seamless enough to feel real, cheap enough to throw away. Wizard of Oz - The user thinks they’re interacting with an automated system, but a human is operating it behind the scenes in real time. A step up from the concierge test - the experience feels like a product, but the intelligence is human.

​
Why bother with hybrid?

Pure lo-fi prototypes are fast but often fail to create the context needed for realistic reactions. “Imagine this is your actual dashboard” is asking a lot of users, especially for complex workflows. Pure hi-fi prototypes create realistic context but take too long to build for early-stage testing. Hybrid hits the middle ground: enough realism to get genuine reactions, enough speed to test before you’ve committed to building 🎯

​
When to use it

Hybrid prototyping is particularly useful when:
  • You’re testing a new feature inside an existing product, where real context matters
  • The value of the feature depends on real user data (which you can fake selectively)
  • You want to test a complete end-to-end journey but only one step is new
It’s less useful for brand new products with no existing components to pull from - start with lo-fi there. Lesson learned: users are remarkably good at suspending disbelief when the core context feels real. The seams matter less than you think - what breaks immersion is confusion, not imperfection 👀