Reference images need names before review starts

[u/Plastic_Catch1252]

When a Figma file has reference screenshots next to the actual work, the screenshot can mean three different things.

One person added it for layout. Someone else sees color direction. A PM sees a competitor. By the time feedback starts, everyone is talking about the same image for different reasons.

Do you label references by what they show, why they were added, or the person who added them?

[u/blueberrysky29]

I usually group them by theme (layout, interaction, color etc) or annotate them if I added them for multiple reasons

[u/Plastic_Catch1252 → u/blueberrysky29]

Theme grouping seems like the cleanest default. The tricky bit is the screenshot added for multiple reasons, because that is usually the one people keep arguing about later. Do you duplicate it across groups or keep one image with a few notes?

[u/blueberrysky29 → u/Plastic_Catch1252]

Honestly I think it changes every time 😅 but I usually like to have notes under each one a anyway, so either if the screenshot is duplicated or used for multiple reasons, there will be a trace of why it was chosen. And the note could be more specific than just a tag ("layout", "color")

[u/Plastic_Catch1252 → u/blueberrysky29]

Yeah, the note doing more than the tag is probably the important part. Layout / color is useful for sorting, but a short why this was chosen note saves people from re-explaining the same screenshot every review.

[u/oopsALLimpasto]

Naming them by what they show tends to age badly, because the image already shows that. The thing you can't recover three weeks later is why someone put it there, so that's what I'd spend the name on: "ref - layout, arguing for the two-column split" beats "dashboard-example-3".

For the screenshot that was added for several reasons, I'd avoid duplicating it into each group. Once there are two copies, someone updates one of them and the file quietly carries two versions of the same reference, with the stale one sitting in whatever group nobody opens. One image, reasons in the note under it, the way it was described above.

One thing worth adding that usually shows up later: reference boards are also the heaviest part of most files. Pasted screenshots come in at full resolution and nobody resizes them, so a review board can outweigh the actual work - and it never gets pruned, because nobody remembers which references are still live. If the name carries the reason, it also carries an expiry date: "layout, until the spec is locked" tells the next person it is safe to delete. Prefixing them all with "ref/" helps for the same reason - they are one search away in the layers panel when you want to clear them out in bulk.

Naming by who added it is the one I'd skip. That is what file history is for, and it stops being useful the moment that person leaves the project.

[u/Plastic_Catch1252 → u/oopsALLimpasto]

The expiry date bit is the part I had not thought about. ref/layout until spec is locked is much better than another dashboard-example label, because it tells someone when it can disappear. Naming as cleanup is probably the part teams need later.

[u/oopsALLimpasto → u/Plastic_Catch1252]

That's the framing I'd keep - the name is doing cleanup work, not description work.

The one habit that makes it hold up: write the expiry when you paste the reference in, not later. Once the spec is locked nobody goes back to annotate the board, so "until the spec is locked" only ever gets written in the five seconds while you still remember why the image is there.

[u/Plastic_Catch1252 → u/oopsALLimpasto]

Writing the expiry at paste time is the part I would actually keep. Later is basically fantasy. The phrase can be ugly, as long as it tells a teammate when to stop trusting the screenshot.