A customer reports that a setting is missing. The support reply needs one screenshot, but the raw capture shows an internal workspace name, three unrelated browser tabs, and a 4 MB desktop image that the ticketing system will shrink unpredictably.
That is not really an image-export problem. It is an evidence-handoff problem: show enough context to resolve the case, remove everything the customer does not need to see, and deliver an attachment that stays readable in the support channel.
TinyImage can compress and export the prepared image directly from Figma. The judgment about what to reveal, annotate, and verify still belongs to the support team.
Start with the question the image must answer
Do not begin by decorating the screenshot. Write the single question it needs to answer:
- Where is the control?
- Which value should the customer choose?
- What should success look like?
- Which difference explains the reported behavior?
If one image is trying to answer all four, split it. A tight annotated screenshot is usually easier to understand than a full desktop capture with six callouts.
Keep enough orientation for the customer to recognize the screen. For a buried setting, that may mean showing the section heading, the control, and one nearby landmark. It rarely means showing the entire app window.
Redact before adding annotations
Support screenshots routinely capture more than expected: customer names, email addresses, workspace URLs, API tokens, billing details, private filenames, or internal conversations.
Crop away unnecessary material first. Then replace sensitive areas with opaque shapes rather than a blur that may still reveal character lengths or patterns. Finally, inspect the flattened export—not only the editable Figma frame—to confirm nothing shows through.
Use realistic dummy values when the hidden information is structurally useful. [email protected] may teach the expected input better than a black rectangle, provided nobody could mistake it for the customer’s actual data.
Make each annotation earn its place
Use numbered steps when order matters, an outline when a control is hard to spot, and a short label when the UI wording needs clarification. Avoid combining arrows, circles, highlights, and paragraphs in one image.
A useful two-image reply might be:
- An orientation image showing where to open Export settings.
- A close-up showing the exact option and expected value.
That sequence is more robust than an enormous screenshot that becomes unreadable on mobile.
Keep annotations away from UI labels. Use contrast that survives both light and dark ticket viewers, and never use color as the only distinction. If the reply says “choose the green option,” it will fail when the customer’s theme, color perception, or product version differs.
Export for the reply channel
Ticket systems, chat tools, and email clients handle images differently. Before setting an arbitrary quality percentage, check:
- maximum attachment size
- whether the service recompresses images
- whether inline images display at their natural width
- whether transparent backgrounds turn black or white
- whether the customer is likely to view the reply on mobile
PNG is often sensible for small UI crops with text and sharp edges. A photo-heavy capture may be much lighter as JPEG or WebP if the destination accepts it. The correct choice is the smallest file that keeps the relevant labels and state changes clearly readable.
Use TinyImage to test compression on the finished frame and inspect the result at 100% zoom. File size alone is not acceptance criteria. Thin text, subtle borders, and low-contrast disabled states are usually the first details to degrade.
For broader engineering handoff, see the image compression handoff checklist. Help-center authors have a different publishing problem covered in the documentation screenshot workflow.
Review the attachment like the customer
Before sending, open the exported file outside Figma and ask someone without the case history to interpret it. They should be able to state:
- which screen this is
- what they should click or compare
- what outcome to expect
Also confirm that the screenshot matches the product version and platform in the ticket. A beautifully annotated macOS screenshot can make a Windows customer’s problem worse if menus differ.
Keep the source frame named with a case-neutral description such as export-settings-compression-option, not a customer’s name or ticket number. Reusable instructional evidence should be easy to find without turning the design file into a second support database.
A send-ready checklist
Before attaching the image:
- The screenshot answers one clear support question.
- Private and irrelevant information has been removed.
- The crop preserves enough orientation without showing the full desktop.
- Annotations do not cover the interface they explain.
- Text remains readable at the size used by the ticket system.
- The exported file was opened and checked after compression.
- The UI version and operating system match the customer’s context.
- The written reply still explains the action; the image is supporting evidence, not the entire answer.
The goal is not the smallest possible screenshot. It is the smallest trustworthy piece of evidence that helps the customer take the next step.
Pro Bundle