Treating my AI writing tool as a UX experiment first, product second
Over the last months I’ve been building a small AI-powered writing helper called Rephrazo, but I’ve been trying to treat it as a UX experiment first and a “product” second.
The core idea is simple:
- you highlight text
- press a hotkey
- a small popup appears with an AI paraphrase
- you can insert it back with one click
The goal: remove the “copy → open ChatGPT → paste → rewrite → paste back” loop when all you want is to clean up one sentence.
Instead of obsessing over features, I’ve been obsessing over how it feels in the flow. A few lessons so far:
1. People don’t want “more AI”, they want fewer decisions
I started with:
- options for tone (formal, casual, punchy)
- options for intent (shorter, longer, more persuasive)
- a visible prompt box
Almost nobody used them.
What people did want:
- one default behavior that’s “good enough” most of the time
- to keep their own voice
- to not think about settings every time they edit a sentence
So I killed a bunch of options and biased the default toward:
“Make this clearer and smoother, but keep my tone/voice as much as possible.”
Usage went up after I removed the configurability, not after I added it.
2. Latency and friction matter more than “output quality”
Some early testers told me:
- “If it spins for more than ~1–2 seconds, I already regret pressing the hotkey.”
- “If the popup appears in a weird place, I ignore it even if the rewrite is good.”
I’ve found that:
- decent output + low friction > great output + annoying UX
- people will forgive a slightly imperfect sentence more than they’ll forgive broken flow
- latency is an emotional problem as much as a technical one
A lot of my time goes into tiny things like:
- making the popup appear instantly (even in a loading state)
- failing fast with a clear message if the request breaks
- avoiding stealing the clipboard or messing with user shortcuts
3. “Cool idea” feedback ≠ consistent usage
Publicly, lots of people said they liked the idea.
In reality, only a subset:
- installed it
- came back multiple times
- started using it in their daily writing
Patterns among people who actually use it:
- they write a lot of their own copy (landing pages, emails, social posts)
- they care about tone/voice but don’t want to overthink every sentence
- they use the tool as a quick “nudge”, not as a full writing replacement
This has been a good reminder that the only real signal is behavior, not compliments.
4. Where it actually fits (so far)
Right now it seems to work best for:
- polishing landing page sections
- rewriting outreach / sales emails
- simplifying social posts or threads
- making English more natural for non-native speakers
It’s much weaker for:
- first-draft ideation
- big structural edits on long-form content
So I’ve stopped thinking of it as “an AI writing assistant” and more as a micro-tool for rewrites when you already know what you want to say.
5. Questions for the Indie Hackers crowd
For anyone building AI tools or “inline helpers”:
- How do you decide when a UX pattern is good enough to double down vs. pivot?
- Where do you draw the line between “magic defaults” and user control?
- What metrics (other than raw signups) actually helped you make product decisions?
If you’re curious about the context, the current version of Rephrazo is here:
https://rephrazo-ai.app/
But I’m mainly interested in comparing notes with others building small, flow-focused tools.
This approach makes a lot of sense — especially for AI-driven tools where what users actually do often surprises what you think they’ll do. Treating it as a UX experiment first forces you to observe real user behavior and refine what value actually sticks before worrying about polish or scale.
One practical pattern I’ve seen work well is defining micro-outcomes — small, observable actions that show users are adopting the core value (e.g., how often someone uses the tool to rewrite, extend, or iterate on a piece vs just poking it once). That kind of signal usually tells you early whether you’re solving real pain vs just curiosity.
Curious — in your early tests, what user action has been the most revealing about whether people find this actually useful versus just interesting to try?
The "usage went up after I removed configurability" insight is gold. It's counterintuitive but makes total sense - every option you add is a micro-decision that pulls someone out of flow state.
Your framing of latency as an "emotional problem" is spot on. There's a psychological contract when someone presses a hotkey: they're expecting near-instantaneous feedback. Even 2 seconds feels like a broken promise, regardless of output quality.
To your questions:
On UX patterns: I've found the signal is in the second use, not the first. First use tells you if the onboarding worked. Second use tells you if the product actually fits their workflow. If someone comes back unprompted within 48 hours, that's stronger signal than 100 "cool idea" comments.
On magic defaults vs control: The sweet spot seems to be: magic defaults for 80% of use cases, with one escape hatch for power users who know exactly what they want. Not a settings menu - just one alternative action (like a modifier key). Most won't use it, but the ones who need it will find it.
On metrics: Beyond raw signups, the metric that's helped me most is "completed actions per session." It captures both engagement AND whether the tool is actually solving the problem fast enough to be worth using repeatedly.
The "micro-tool for rewrites" positioning is smart. Narrow and specific beats broad and vague for early traction. Once you own that wedge, you can expand.
What's the current breakdown between native English speakers vs non-native in your user base? Curious if the use cases diverge.