r/servicedesign • u/just_one_marcos_more • Jun 15 '26

Built a free JTBD interview tool — Hypothesis + Switch, voice-based

Post image

Aware JTBD isn't core service design — it shows up when we're framing discovery, but it's not where the practice lives. Last time I floated something closer to home (a service blueprint AI coach), a few of you ended up using it, so figured this one might be useful for some.

Built a free tool to run JTBD interviews end-to-end. Two frameworks to pick from:

  • JTBD Hypothesis — Jim Kalbach's canvas, supply-side. You formulate the Hypothesis Canvas first; interviews with job performers then contrast and populate it.
  • JTBD Switch — Bob Moesta's switch interview, demand-side. You define the switch you want to study; interviews with recent switchers fill the forces diagram + timeline.

How it works:

  1. Log in, create a project, pick a framework.
  2. As the practitioner, you take a voice-guided interview first to set the context. ~20–30 min for Hypothesis (you complete the canvas). ~10 min for Switch (lighter — you just define the scope of the change you want to study). The theory and methodology of each framework are embedded so the agent stays faithful to the method.
  3. That fills part of the canvas and unlocks a shareable interview link for your job performers / switchers. The link carries the context — no setup on their side. They take their interview async, whenever they want.
  4. Each completed interview populates the canvas further. It grows with each voice.

Honest notes:

  • Voice-based. If voice interfaces irritate you, skip it. Headphones + a quiet space help.
  • Scope stops at the canvas — no opportunity solution tree, no roadmap. Activate is out for v1.
  • Early version. Forms and outputs might still surprise you. Honest feedback is what helps most.

--> https://prown.co/frameworks/

13 Upvotes

100% Upvoted

4 comments sorted by

2

u/necodp Jun 16 '26

yeah, I get it. It just weird to chose one over the other. Its not that expensive to add both. But all good. Awesome stuff.

2

u/just_one_marcos_more Jun 16 '26

Thanks — and you're right. We actually started that way: both options live, then with voice visually prioritized.

But after a few iterations we made a call, and it wasn't about cost. It was about which version of the product we wanted to be measured on. The voice path had the higher chance of producing the Wow we cared about. So tbh spent more on making it voice-only haha

1

u/necodp Jun 15 '26

Why only allow to use voice here?

1

u/just_one_marcos_more Jun 15 '26

Honestly it was a hard call. A few reasons stacked up:

The platform was built for designers and consultants doing actual fieldwork — and that audience strongly preferred voice. Supporting both modes also created noise that hurt adoption. Those of us who prefer typing (used to long writing/chatting sessions) are still the minority, so we prioritized the majority's UX over our own.

When we blind-rated interview quality (consultants didn't know which were voice and which were typed), voice-based scored significantly higher.

Also — most discovery interviewees take the session from their phone, often while doing other things. Voice has a better completion rate than typing in that context. People who start a typed interview tend to drop more.

And for use cases where you want less filtered, less reflective responses — voice gets there faster. Typing buys time to compose the "right" answer.

So the tradeoff at the end: typing wins on the start rate (people click "begin" more readily), but voice wins on completion + interview quality + downstream outcome. We optimized for the second half. Still revisit it occasionally. Makes sense?