There is usually a moment in a design review when someone asks, “Which version are we looking at?”

It happens even on fairly organised projects. A designer posts a screenshot in chat, the developer adds another one to the task, somebody sends the client a PDF in the afternoon, and by the next morning the screen has changed again. None of this feels messy while it is happening. It only becomes messy when a person comes back later and has to work out which file belonged to which conversation.

I have found that most of the friction around review files comes from this, not from the design tools themselves. Teams already have Figma, Jira, Linear, Slack, email, Notion, or whatever combination works for them. What they sometimes do not have is a simple way to move the actual visual between those places without making another copy every time.

A link is useful in those situations because it can follow the conversation. If a screenshot is sitting on your computer and the ticket needs a URL, you can turn a screenshot into a URL and put it directly beside the issue. A longer review document works in much the same way. Instead of sending the PDF again to every new person, you can share a PDF through a link and keep the discussion wherever it already lives.

That does not mean every review file needs to become a link. Sometimes attaching the file is easier. Sometimes the reviewer needs the original design file. The useful choice depends on what the next person is actually expected to do.

A screenshot is usually enough, until it isn't

Say the mobile navigation is sitting a little too low after the latest build.

Nobody needs a twelve page design document for that. A screenshot showing the header, the navigation, and a little of the content below it will probably explain the problem faster than a paragraph.

The trouble starts when the screenshot is cropped too tightly. If all the developer sees is the navigation bar, they may have no idea whether the spacing problem comes from the header above it or the content below. On the other hand, sending the entire desktop with twenty browser tabs visible is not particularly helpful either.

The useful screenshot is usually somewhere in between.

This sounds obvious until you see how review images actually get shared. People grab whatever is on screen, paste it into chat, and move on. Later, someone downloads that image, adds an arrow, saves it again, and uploads the new copy somewhere else.

Now there are two versions of the same screenshot.

A few rounds later, there may be five.

One habit I like is keeping the explanation outside the image unless the annotation genuinely makes the problem easier to spot. A single arrow pointing at the wrong spacing is fine. Covering half the screen with labels usually makes the screenshot harder to read.

The comment beside it can do the rest.

Instead of:

Spacing issue here.

Write:

On the 390 px layout, the search field is touching the right edge after the menu opens.

The developer now knows what to look for and when it happens. The screenshot does not have to carry every detail by itself.

PDFs start making sense when the screens belong together

A single screen is easy to review as an image. A whole flow is different.

Onboarding is a good example. There might be an account screen, profile details, notification permission, a preference screen, and then the final confirmation. You can send all of those as individual screenshots, but at that point the reviewer has to keep them in the right order.

That is where a PDF becomes useful.

The designer can put the screens in sequence and add a small note beside the ones that changed. A client can open the document, go from page one to page two, and understand the flow without being dropped into a design workspace they have never used before.

PDFs are also handy when the review includes things that do not live naturally inside Figma.

A proposal might contain a short explanation at the beginning, followed by the new screens, followed by a few questions that need approval. A brand review may have screenshots mixed with copy and reference material. Nobody wants twelve separate attachments for that.

There is one slightly boring habit that saves trouble here: open the final PDF and actually move through every page before sending it.

Old comments survive inside documents. So do screenshots from earlier versions, notes meant for the internal team, and sometimes information copied from another client project. The cover can look perfect while page nine still contains something that should never leave the company.

People tend to check a PDF less carefully than they check an email because it already looks finished. That is exactly when things get missed.

Some problems only exist while the interface is moving

The most frustrating UI bugs are sometimes the ones that cannot be shown properly in a screenshot.

A dropdown flashes and disappears.

The page jumps after a form is submitted.

A modal opens behind another layer.

The animation works, technically, but it feels strangely slow.

You can describe all of that in text, but after a certain point the description becomes harder to understand than the bug.

A short recording is better.

And short really does mean short. If the issue happens after three taps, show the three taps. There is no reason to record four minutes of setup unless the setup itself is part of the problem.

I have seen bug reports where the important moment happens at 3:42 in a five minute video. By the time the developer finds it, the recording has already created more work than it saved.

A useful clip normally starts just before the behaviour you want someone to see.

For design reviews, video can also answer questions that have nothing to do with bugs. Maybe the transition between two screens feels abrupt. Perhaps the loading animation attracts too much attention. Those are judgement calls, and watching the motion makes the conversation much easier.

Things get different once the client is involved

Internal teams tolerate a lot because everyone already knows the tools.

A developer knows where the project board is. The designer knows which Figma page is current. The product manager has followed the conversation all week.

The client may open the project once every ten days.

If reviewing one screen requires finding an invitation, signing into another service, choosing the right workspace, opening the correct project, and then locating a particular frame, you have introduced quite a lot of work just to ask whether the new header is approved.

Sometimes the design tool is still the right place. If the client needs to click through a prototype or leave comments across several screens, access to the original project is useful.

But plenty of reviews are much smaller than that.

“Can we use this hero section?”

“Is the revised pricing page okay?”

“Which of these two checkout versions do you prefer?”

For those, showing the relevant thing directly is often easier.

The mistake is assuming that because the internal team uses a certain workflow every day, everybody else should use it too.

Version names get ridiculous faster than anyone admits

Most teams eventually produce something like:

homepage-final-v2-final-approved.pdf

That filename is a joke until someone replies to the wrong one.

Imagine a PDF goes to the client on Monday. The team makes two changes on Tuesday. Another version goes out Wednesday morning. On Friday the client replies to Monday's email saying, “Looks good, approved.”

What exactly has been approved?

This is not really a file naming problem. It is a conversation problem.

Clear filenames help, of course. So does putting the current version somewhere obvious. But the important thing is that people should not have to guess whether the thing they opened is still the thing being reviewed.

Sometimes keeping an old version is useful. You may want to look back and see what changed after a particular meeting. There is no need to delete history just to keep things tidy.

The old copy simply needs to look old.

A review screenshot is not a developer handoff

This gets mixed up surprisingly often.

A screenshot may be completely adequate when the question is, “Does this layout feel too crowded?”

That same screenshot is not enough when somebody has to build the page.

The developer may need to know what happens at smaller widths, which state appears after an error, how a component behaves with longer content, and where the actual assets come from. None of that can be reliably reconstructed from a picture.

I like screenshots in development tickets for a different reason. They tell the developer which state or which part of the interface the ticket is talking about.

The implementation details still belong in the proper source.

Otherwise temporary review material slowly turns into documentation, and six months later someone is building from an image that was never meant to define the final behaviour.

Testing has the same problem, just from another angle

A quality assurance person sees visual files differently from a designer.

The designer might send a screenshot to discuss appearance.

The tester sends one to prove what happened.

That distinction changes what needs to sit beside the image.

If the problem only appears in Safari, say that. If it happens after the user removes their saved address and returns to checkout, that sequence is probably more useful than a second screenshot.

Sometimes a recording is the quickest answer.

A developer can watch the steps, reproduce them, and compare the result after making the fix. There is much less room for the familiar exchange where one person says, “I cannot reproduce it,” and the other replies, “It happens every time for me.”

Environment details do not need to become a form with twenty fields either. Put in the information that actually changes the behaviour.

Remote teams expose weak review habits very quickly

If everyone is in the same office, missing context is cheap.

You turn your chair around and ask what the screenshot means.

With a remote team, that question can sit unanswered until the other person wakes up.

This is where a small amount of care pays off. A sensible filename, one visual reference, and a sentence explaining what the person should notice can be enough for work to continue across time zones.

Not every issue deserves a formal write up.

In fact, forcing every small design problem through a heavy template can make people stop documenting things properly because the process feels annoying.

A tiny spacing problem might only need an image and one sentence.

A checkout bug involving several actions probably needs a little more.

A large redesign going to a client deserves a proper document because several decisions depend on each other.

Those are three different situations. They do not need to look like the same workflow.

There is also no reason every review file should live forever

This part tends to get ignored because deleting old review material is nobody's exciting Friday afternoon task.

A screenshot is shared for a staging bug. The bug is fixed. The release goes out.

The screenshot is still there six months later.

If it only contains a public interface, that may not be a big concern. If it shows an internal dashboard, a customer account, an unreleased feature, or a client document, the situation is different.

The useful life of the file should roughly follow the reason it exists.

Some documents are meant to stay available. Others only need to survive until somebody gives feedback.

It is also worth looking at what appears in a screenshot before sending it outside the company. People who stare at the same product every day stop noticing the names, email addresses, IDs, and internal information scattered through the interface.

The client or stranger opening the image will notice them.

Good review workflows are usually boring

That is not an insult.

When the process is working, nobody talks about where the screenshot is hosted or which tool opened the PDF. They open the reference, understand what they are supposed to look at, and reply.

A developer is not searching through last Tuesday's Slack messages.

The client is not asking which PDF is current.

A tester is not recording the same bug again because the first video disappeared into a chat thread.

The tools quietly get out of the way.

That is really the useful distinction between screenshots, PDFs, and recordings during UI/UX review. A screenshot is great when there is one thing to point at. A PDF is easier when several screens need to stay together. A recording earns its place when movement is part of the problem.

After that, the rest is mostly common sense: keep the reference easy to open, say what somebody should look at, and do not make the next person reconstruct the whole conversation before they can respond.