drafty

How to get feedback on a mobile app

Quick answer

To get feedback on a mobile app design, share a link your client can open on their phone and annotate directly — no developer account, no TestFlight invite required. For a built app, you can combine TestFlight with a structured question list. The most common failure mode is getting screenshots back with circles drawn on them in WhatsApp: the feedback is real, but it's detached from the actual screen, so you spend the next exchange locating what they meant.

Step 1

Screenshot markup — what most designers default to, and why it breaks down

Export screens from Figma or your design tool, share them over email or iMessage, and ask the client to circle or annotate what they want changed. This feels fast but creates a reconciliation problem: the client marks up a flat image, sends it back, and you're now reading a JPEG with red circles and arrows that refer to layers you can't select. When you push a revised screen, they're commenting on a new screenshot — and the old one is already stale. The round-trip compounds: two revision cycles in, you have five annotated JPEGs from three email threads. Designers who work this way typically spend more time locating feedback than implementing it.

Step 2

Record a walkthrough of the app and ask specific questions

Use Loom or QuickTime (File → New Screen Recording) to record yourself navigating through the app's screens. For a Figma prototype, use the Figma presentation mode and record that. Narrate what you're trying to communicate at each screen: 'On this onboarding step, I'm not sure the skip button is obvious enough — does it read as optional or required?' Send the recording with three to five specific questions written below it. Specific questions get specific answers: 'Does the skip button read as optional?' will get a direct yes/no back. 'What do you think of the onboarding?' gets 'looks good' back. Loom's comment feature lets clients reply timestamped to exact moments in the recording.

Step 3

Use TestFlight (iOS) or Google Play's internal testing track (Android) for a built app

If you have a working build and need feedback on real interactions — not just the design — TestFlight is the right tool for iOS. Add the client's Apple ID as an external tester, upload a build to App Store Connect, and they get an invitation email to install the beta via the TestFlight app. Android's equivalent is a Google Play internal testing track: upload an APK or AAB to the Play Console, add tester emails, and share the opt-in link. Both require a paid developer account ($99/year for Apple, one-time $25 for Google) and a working build. They're the right tool for usability testing and QA, but overkill if the client only needs to approve a visual design or navigation structure — the upload and review process can take 30 to 60 minutes per build, and Apple's automated review adds another layer of latency.

Step 4

Share a doc with app screens your client annotates directly

For design sign-off — not beta testing a built app — the lowest-friction method is a shared document containing your app screens (exported from Figma, Sketch, or any design tool) with a link the client opens in any browser. They click the exact element they mean — the navigation tab, the CTA button, the error message — and leave a note pinned right there. No developer account, no TestFlight invite, no install on their end. Purpose-built review tools let clients annotate directly on the uploaded screens. This approach works whether the client is reviewing on their laptop or opening the link on their phone, and every note arrives in one place, anchored to the specific screen and element. Most clients who would balk at 'install the TestFlight app and accept the invite' will annotate a doc link inside a minute.

The faster way

If your client keeps sending you screenshots with circles drawn on them over WhatsApp — export your app screens from Figma and drop them into a Drafty doc canvas. Share the link. They open it on their phone, tap the element they mean — the button, the label, the tab bar — and leave a note pinned right there. No account, no install. Every comment lands in one threaded place. When you update the screens, replace the file on the same link — no re-sending, no new URL.

Open a live demo

Questions

How do I get feedback on a mobile app design without a developer account?
Export your app screens as images from Figma or your design tool and share them in a doc or review link. Your client can annotate the exact screen element without needing a developer account, TestFlight access, or the app installed. This covers the design sign-off phase — if you need feedback on the built, interactive app, that's where TestFlight or Google Play's internal testing track become relevant.
How do I share a mobile app design with a client for review?
The two most common approaches are a Figma share link (prototype mode, 'Anyone with the link can view') or an exported set of screens in a shared doc or review tool. Figma is right if the client already has a Figma account; a review doc link is better when they don't, since they can leave anchored comments without creating an account.
What is the best way to collect feedback on mobile UI?
Anchored comments beat free-form email for UI feedback — a note pinned to the exact screen element tells you precisely what to change. The gap between 'the navigation doesn't feel right' (email) and a comment pinned to the tab bar icon saying 'this label is ambiguous' is about one revision round. The latter is immediately actionable.
Do testers need to install anything to give feedback on my app?
For design review, no — a shared link to your screens is enough. For testing an interactive build, iOS testers need to install the TestFlight app (free, from the App Store) and accept your invitation. Android testers need to opt in via a Google Play link and install through the Play Store. Neither requires a developer account on the tester's side, only on the developer's.
How many rounds of feedback should I plan for on a mobile app design?
One to two rounds is realistic when clients can annotate directly on the screens, because the feedback arrives element-specific and you can address each note cleanly. Email and screenshot-based feedback typically runs longer — each vague comment ('the buttons seem off') requires one exchange to locate before you can fix it. Budget an extra round for each vague-feedback cycle you expect.
How do I get feedback on a Figma prototype from a client who doesn't use Figma?
Share a view-only link in presentation mode — the client can open and navigate it without a Figma account. To leave comments, they need a free Figma account; that's a real barrier for some clients. If account creation is likely to stall the review, export the screens and share them in a tool that supports guest commenting so they can annotate without signing up.

Keep exploring

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.