How to run a design review with clients who don't have an account

Most design reviews stall at the same moment: you send a link, and the client lands on a sign-up page. Some reply with a screenshot covered in red circles; others forward the link to a colleague who can't open it. They agreed to look at a design, not to join your tools. This guide covers how to run a review that works for people who will never have an account, without losing track of what they saw, what they said and what they agreed to.

Why "just sign up" breaks client review

Asking a client to create an account feels small to the team and large to the client. They have to pick a password, accept terms, maybe verify an email, and then find the right screen inside a product they have never used. Every step is a chance for the review to slip a week.

Accounts also blur roles. A client with a full account may see internal boards, half-finished explorations or other clients' work if permissions aren't tight. A client with no access at all ends up giving feedback through email, chat and phone calls, so the decision trail lives in five places.

What you want is the middle ground: a private, temporary way in that shows exactly one thing, lets the client respond in context, and records who said what.

Decide what the client is actually reviewing

Before you share anything, write down the scope in one or two sentences. Nielsen Norman Group's guidance on design critiques recommends defining what will and won't be critiqued and agreeing on objectives before feedback starts, because feedback without shared goals turns subjective. That advice matters even more with clients, who often have less context than the team.

A useful scope note looks like this:

## What we're asking you to review
- The new onboarding flow: welcome, workspace setup, invite teammates
- Phone and desktop sizes
- The empty and error states on the invite screen

## Not in scope this round
- Copy on the marketing site
- The billing pages (next review)

## The decision we need
Approve the flow, or tell us what must change before we build it.

It names the screens, rules out what you won't discuss, and states the decision you need, so "looks nice" isn't mistaken for approval.

Freeze a version before you share

Never send a client a link to a design that is still moving. If a designer nudges a button after the client has looked, the client's approval now refers to something nobody can see any more.

Freeze the design as a numbered version before review, and make the link point to that version, not to "latest". If feedback leads to changes, those changes become a new version and a new review. It's the only reliable answer to the question that comes up weeks later: "What exactly did they approve?"

In M1rror this is built into the review step: "Send for review" freezes the current draft as a new version, called a release, and approvals bind to that exact release. A changed design means a new release and a new review. See send a release for review for how that flow works.

Choose what the link allows

A guest link is a set of decisions, not just a URL. Work through them on purpose.

What to share

Share the smallest thing that answers the question. If you need approval on a flow, share that version of the flow. If you are early and want reactions to references or direction, share something that only accepts comments, so nobody "approves" a moodboard by accident.

What guests can do

Separate the actions:

• Comment: almost always yes.
• Request changes: useful when the client is a decision-maker.
• Approve: only for the people whose sign-off you need.
• Appear in presence: helpful on a live call, unnecessary for async review.

How long it lasts

Pick an expiry that matches the review window, not "forever". A week is usually enough for an async round; a day is enough for a live session. A short expiry limits the damage if a link is forwarded further than intended.

Whether it needs a passcode

A passcode adds friction, so use it when the work is sensitive: unreleased products, client names, anything under NDA. Send the passcode through a different channel from the link.

In M1rror, "Share for review" covers each of these decisions. You choose a release (for review and approval) or the board (comments only), an expiry of 1, 3, 7, 14 or 30 days, an optional passcode of at least six characters that is entered before anything is shown, and whether guests can comment, approve or request changes, and appear in presence. Guests verify with name, email and a six-digit code; the token is shown once and only a hash is stored; revoked links stop working immediately; and guest pages are not indexed by search engines. The guest review links guide walks through the settings.

Know who is commenting without an account

"No account" shouldn't mean "anonymous". You still need a name against every comment and decision, and some confidence that the email is real.

The common pattern is a lightweight check at the door: the guest enters a name and email, receives a short one-time code, and types it in. That proves they control the address without giving them a password to forget.

Two privacy details are worth copying even if you build your own flow. First, guests don't need to see other people's email addresses; showing author names is enough. Second, guests shouldn't be able to @mention your team, because that turns a review link into a way to message anyone in your workspace.

Keep the link private by design

A review link is a bearer secret: anyone holding it gets in. Treat it like one.

Store a hash, not the token

Show the token once when the link is created and store only a hash. If your database leaks, the stored values can't be pasted into a browser.

import { createHash, randomBytes } from 'node:crypto';

export function createReviewToken() {
  const token = randomBytes(32).toString('base64url');
  const hash = createHash('sha256').update(token).digest('hex');
  // Return `token` to the person creating the link, once.
  // Persist only `hash`, plus expiry and permissions.
  return { token, hash };
}

export function hashToken(token: string) {
  return createHash('sha256').update(token).digest('hex');
}

Make unknown, expired and revoked links look the same

When a link is wrong, expired or revoked, return the same "not found" page. Different messages tell someone guessing links which ones used to exist. Revocation should take effect on the next request, not after a cache expires.

Keep review pages out of search engines

Review pages should never appear in search results. Google's documentation on blocking indexing explains that a noindex rule drops a page from results, that you can send it as an X-Robots-Tag header, and that the page must not be blocked in robots.txt, or the crawler never sees the rule. In a Next.js App Router project:

// app/review/[token]/layout.tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  robots: { index: false, follow: false },
};

export default function ReviewLayout({ children }: { children: React.ReactNode }) {
  return children;
}

Run the review itself

The link gets the client in. The review still needs running.

Brief before you share

Send the scope note with the link. Say how long the review should take and when you need a response. If you're running it live, spend the first two minutes restating the goal and the user problem, as the NN/g critique guidance suggests, before anyone looks at pixels.

Ask for feedback in place

Feedback is most useful when it is attached to the thing it is about. "The button is too small" is ambiguous on a screen with six buttons. A comment pinned to the button isn't. Encourage clients to click on the element and comment there, and to draw if words are hard: a rectangle around a cluttered area or an arrow pointing at a misaligned icon says more than a paragraph.

Require a reason with every decision

An approval with no words attached is fragile. Ask for one or two sentences: what they are approving and any conditions. "Approved, assuming the invite limit copy is checked by legal" is a very different decision from a bare tick.

Decide what a guest approval means

This is the question teams skip, and it causes the most trouble later. If a client approves through a guest link, does that publish the design, or is it input for the team's own decision?

There are good reasons for either, but write the rule down before the review:

• Advisory: guest approvals are recorded and shown, and a team member makes the final call. This is safer when many stakeholders are invited.
• Required: named stakeholders must approve before the version can ship. This suits contracts where the client signs off formally.

M1rror defaults to advisory: guest approvals are recorded and shown, but only member approvals publish, unless an admin names required stakeholder emails. Team reviewers don't need a paid seat either; reviewers and viewers are free on every plan, which helps when the "client" is really an internal stakeholder. More on roles in members and roles.

After the review

Close the loop the same day:

1. Summarise decisions and requested changes in one message, linking to the comments.
2. Make the changes as a new version, not as edits to the approved one.
3. Revoke the old link if it's no longer needed, rather than waiting for it to expire.
4. Send a fresh link for the new version, with a short note on what changed since last time.

A checklist for guest design review

• Scope note written: screens, out-of-scope, decision needed
• Design frozen as a numbered version
• Link points to that version, not "latest"
• Permissions chosen: comment, request changes, approve, presence
• Expiry matches the review window
• Passcode set for sensitive work and sent separately
• Guests verify identity with a one-time code
• Token shown once, stored hashed
• Unknown, expired and revoked links look identical
• Review pages marked noindex
• Rule written down: are guest approvals advisory or required?
• Every decision carries a written reason
• Changes go into a new version with a new review

Wrapping up

Clients don't need an account to give you good feedback. They need a private link that shows one frozen version, a way to comment on the exact thing they mean, and a clear statement of what their approval does. Get those right and reviews stop living in email threads, and "what did they approve?" has a one-click answer. If you're also tidying the design itself before showing it, our guide to making your web app look professional is a good place to start.