The method used to put the PayWise Kiosk report together — turning "this doesn't match the design" into a report a developer can act on without a call. Follow this when handing off any UI discrepancy: kiosk, app, or web.
Walk the actual product end to end — phone video or screen recording is fine — touching every screen a customer would see, start to finish. Don't skip steps because they "look fine"; you want the full set to compare against, not just the ones you already suspect are wrong.
In FigCraft (or a Figma page), paste each screen's photo into its own row, left to right:
If one screen needs more than one note, add extra sketch columns rather than cramming everything into one — a modal's overall position and its internal spacing are two different sketches, not one.
Draw directly on the current-state screenshot — circle the element, arrow where it should move, box the area that should expand. Keep it to one colour (red works) so it reads instantly as "this is the note," separate from the UI itself.
This is the step that makes the report land: a developer trusts a circle drawn on their own build's screenshot more than a paragraph describing it.
Before writing anything up, sort your notes into two piles:
Screen-specific — only shows up on that one screen (a modal's padding, a missing icon on one form).
Cross-cutting — the same issue repeats across most or all screens (everything sits too low, nothing is scaled to the real screen size). These go at the top of the report, once, instead of being re-explained on every row.
Share the FigCraft/Figma file, any source video, and the Figma link. Ask for a single-page report: cross-cutting notes first, then one section per screen showing the three columns in order, each with a one-line caption — nothing more.
Say explicitly that the screenshots should carry the argument — no invented diagrams, percentage call-outs, or synthetic "before/after" graphics layered on top. If a point needs more than the photo and a sentence to land, that's a sign the sketch needs a clearer mark-up, not a better write-up.
The developer built what the spec implied, with the information they had. The report is asking for a change, not pointing out a mistake — even when a screenshot makes the gap obvious. Pass on the wording below once, so it doesn't need re-explaining on every pass.
| Instead of | Write |
|---|---|
| "It should sit right under the header instead." | "We'd like to move it up so it sits right under the header." |
| "This is missing / this is wrong." | "We'd like to add…" / "Can this be done?" |
| A paragraph explaining why it's broken. | One line naming the change, and let the sketch show the why. |
Publish as a shareable link rather than a static export — the first draft rarely survives contact with a second read. Expect a few rounds: a screenshot gets swapped, a line gets reworded, a link gets added. Update the same link each time rather than sending a new one, so whoever you handed it to is never looking at a stale version.