How to review an app design (and get feedback that's actually usable)
To review an app design, work screen by screen: check that every primary action has a tap target of at least 44px, that the flow between screens matches what a first-time user would expect, and that platform conventions (iOS or Android) aren't violated in ways that will confuse the client's users. Once your own pass is done, share the screens as an annotated review link — the client clicks the exact element they mean, not describes it in an email.
Check tap targets and spacing before anyone else sees it
The most common round of client feedback on an app design is 'this feels cramped' or 'I keep hitting the wrong button.' Both are tap-target problems, and both are diagnosable before the client sees the design. Apple's HIG specifies 44×44pt as the minimum; Google's Material Design uses 48×48dp. Open the design in Figma (or your tool of choice), select each interactive element, and confirm the hit area — not the visual footprint of the button, but the full touchable zone including any padding. Buttons that look correctly sized on a desktop canvas can drop to 30px when exported and opened on a real phone. Run the same check on links inside body copy: inline links are almost always undertapped. Fix these before sharing — a client who hits the wrong button on their phone during review will call it a 'usability problem' without being able to name the cause, and you'll spend a round diagnosing it instead of collecting meaningful feedback.
Walk the main flow as a first-time user
Designers live in the file. They know that tapping the avatar opens the profile, that swiping left reveals the archive action, that the empty state resolves after onboarding step 3. A first-time user does not. Before sharing for review, walk the primary flow cold — from the screen the user lands on to the goal they came to complete — and note every point where you relied on context you built into the design over the past two weeks. The most revealing test: write down what you expect to happen at each tap, then check whether a label, icon, or animation actually communicates that to someone with no context. Unlabeled icon-only nav tabs fail this test almost every time. Empty states that show nothing fail it. Back buttons that say 'Back' instead of the actual screen name fail it. Log each one as a question to include with your review link — 'Is it clear what this button does?' gets a better answer than 'Do you have any feedback on the nav?'
Flag platform violations before the client does
Clients notice when something feels wrong on their phone even when they can't name why. The reason is usually a platform convention violation: a bottom-sheet that opens from the top on iOS, a swipe-to-go-back gesture that's blocked, a floating action button placed where the thumb can't reach it. Run a quick audit: on iOS designs, navigation belongs at the bottom (tab bar) or the top (navigation bar with back arrow at left); modals slide up, not in from the right; destructive actions get a confirmation sheet. On Android designs, the back gesture (swipe from edge) should work on every screen; the FAB sits bottom-right. These aren't aesthetic choices — they're what determines whether a client's users feel at home or feel confused. Catching one genuine platform bug in your own review is worth more to a client than any visual polish, and flagging it yourself (before they spot it) builds more trust than explaining it after.
Share a link they annotate on the exact screen — not a PDF or a Figma invite
The most avoidable waste in an app design review cycle is a client who sends back a three-paragraph email describing what they mean. 'The screen where you log in — the button at the bottom — not the main one, the smaller one' is a description that requires two exchanges before you know which element to fix. The fix is changing the channel: share the app screens as an annotated review link where the client taps the exact element and pins a note to it. You see 'Login CTA — copy feels too generic' anchored to the button. No decoding. Critically: the client needs to be able to do this without creating an account. Most designers have experienced the Figma guest barrier — a client who opens a Figma link for the first time hits a login prompt and falls back to email, because making an account to leave a comment isn't something a busy client will do. Share a link that opens in a browser tab and accepts a comment in one click.
Drop the app screens into Drafty — export the frames from Figma as images or use the live preview URL — and share the link. Your client opens it on their phone, taps the exact element, and pins a note. No Figma account, no extension, no re-emailed screenshots. Every comment lands in one thread anchored to the spot. When you push revised screens, the same link updates — you don't send a new export each round.
Open a live demoQuestions
- What should I look for when reviewing an app design?
- Check four things: tap targets on every interactive element (minimum 44×44pt on iOS, 48×48dp on Android), the primary flow from landing screen to goal completion as a first-time user would experience it, platform convention violations (bottom nav on iOS, back gesture support on Android, correct modal directions), and empty states — the most-skipped screen in any app review. Fix what you find before sharing; it reduces the rounds of feedback you need from the client.
- How do I share an app design for client review without a Figma login?
- Export the frames as PNG images or use a live preview URL, then share them through a review tool that accepts guest comments without an account. If you share a raw Figma link with a client who doesn't have an account, they hit a login wall and most will fall back to emailing you instead. A review link that opens in any browser and accepts a comment in one tap removes that barrier entirely.
- How do I get specific feedback instead of 'I don't like it'?
- Vague feedback comes from reviewers who can't point at what they mean. On email or a flat screenshot, they describe — and descriptions drift. Giving a client a way to tap the exact element and leave a note tied to that spot produces 'the back button on the order confirmation screen is too hard to spot' instead of 'navigation feels confusing.' Two specific questions also help: 'Is it clear what tapping this button will do?' and 'Does this screen feel like it belongs on your phone?' — specific questions pull specific answers.
- How many rounds of review does an app design usually take?
- One or two when the client annotates directly on the screens. Email-based review adds rounds: 'the screen with the list' requires at least one exchange to locate the element before you can fix it. Running your own review pass (tap targets, flow, platform conventions) before the client sees the design removes the most predictable round — the one where they catch the same thing you would have found.
- Can the client review the app design on their phone?
- They should. App designs reviewed only on a desktop miss the most important surface. Share the review link in a message — iMessage or Slack — so the client opens it on the device your app is built for. Comments pinned on mobile are usually more useful than comments pinned on desktop for an app design, because the client is experiencing the scale and spacing your users will actually feel.
- What is the difference between reviewing an app design and a website?
- The main differences are interaction model and platform conventions. Websites are mostly scroll-and-click on a wide canvas; apps are tap-and-swipe on a narrow one with platform-specific gestures (back swipe, pull-to-refresh, bottom sheet). App reviews need to check flows between screens, not just individual screens in isolation — because a screen that looks correct on its own can confuse users who arrive from an unexpected path.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.