Use this for confusing screens, unclear wording, bugs, mobile friction, or what felt useful.
Choose feedback path.
Pick the closest path before typing so private writing, account requests, privacy questions, and safety concerns do not land in the wrong place.
The path chooser changes the form guidance only. It does not start live support, prove legal review, verify an account, send an emergency alert, or review private journal content.
Choose the right support path.
UYB separates product feedback, safety resources, account help, and privacy questions so people do not have to guess where sensitive notes belong.
Use support when sign-in, exports, deletion, shared links, or finding your journals feels unclear.
Use real-world help right away if someone may be unsafe. UYB is not emergency support.
Use privacy, terms, cookies, and notifications pages for data, consent, and product boundary questions.
Use this when feedback came from a real test session and needs triage before it becomes product work.
Do not send private journal answers, drafts, reveal text, or another person's writing through support or feedback.
Send feedback without sending private writing.
Useful product feedback names the moment, the friction, and the next thing you expected, without copying private journal text.
- RemoveLeave out private words
Do not paste journal answers, drafts, reveals, solo notes, invite links, or another person's writing.
- NameName the screen or step
Tell us where you were, what button you tapped, or what you expected to happen.
- ImpactSay how it felt
Confusing, too much scrolling, unclear status, safer than texting, or not ready yet are all useful signals.
- RouteUse the right path
Product feedback, account requests, privacy questions, and safety concerns need different handling.
Feedback is not emergency support, live chat, therapy, or account verification. If someone may be unsafe, use real help first.
Try: I was on [screen], I expected [action], but [result] happened on [device].
Make a tester report useful.
When a tester says the app felt unclear, the strongest report names the screen, expected action, actual result, and device context.
Name the page or step, such as Journal home, Start a question, Reveal, Profile, or Updates.
Say the action you expected after tapping, saving, signing in, sharing, or returning.
Describe the visible result, missing status, scroll problem, lost draft, confusing wording, or dead end.
Include phone model if known, browser, screen size feeling, and whether you were signed in.
Do not include journal answers, drafts, reveal text, invite links, screenshots with private writing, or another person's words.
Run a mobile tester pass without collecting private writing.
Give testers a small set of flows and ask for safe observations. The goal is to learn where the app loses clarity, trust, or momentum on a phone.
/start-here, /sign-up, /profileTester can explain what UYB is for, what stays private, and what to do first.
/pair/new, /dashboard, /pair/[inviteCode]Tester understands that the link invites the other person and the answer stays private until reveal.
/dashboard, /journeys, /updatesTester can return without founder help and without losing trust in saved writing.
/solo, /vent, /safety, /supportTester knows private writing is not sent, scored, monitored, or copied into support.
- route or screen name
- device and browser
- expected next action
- actual visible result
- safe screenshot description
- severity: blocked, confused, or polish
- journal answers
- draft text
- solo notes
- vent text
- reveal text
- invite links
- passwords or one-time codes
- real names or private family details
Mobile tester notes are product evidence, not customer support records. Store safe observations only, and turn accepted issues into bounded work after triage.
Retest the fixes that used to confuse people.
These checks turn the original tester confusion into simple mobile tasks. A pass means the tester can explain the screen without founder help.
/dashboardTester can find the invite path, knows no answer opened, and knows the next step is a shared question.
/pair/[inviteCode]Tester understands that the invite link comes first and the question appears after the journal is ready.
/pair/[inviteCode]/question/newTester knows their writing is private, the reveal is locked, and waiting does not mean they did anything wrong.
/pair/[inviteCode]/question/[sessionId]Tester can see the restored draft or saved state and does not have to scroll around to understand the next action.
- tester found the right screen
- tester named the next action
- tester understood what stayed private
- tester could pause without pressure
- real journal answers
- draft text
- invite links
- reveal text
- names of the other person
- screenshots with private writing
A retest note should describe product clarity only. It should not store private writing, invite links, real relationship details, screenshots with private text, or customer account secrets.