Feedback and approvals

Design feedback and approvals for design subscriptions

How design subscription studios stop revisions getting lost in Slack: one approver, one review round, a revision test and an approval line on each card.

Published 24 September 2026. Tool prices checked September 2026.

If revisions keep getting lost between a Slack thread and a Figma file, you do not need another tool yet. You need one approver, one place for comments and one line on the request card that records the yes. You also need a test for whether a change is a revision or a new request. This guide sets up each of those, with a worked example you can copy onto your board this week.

Feedback is useful when the designer can act on it without guessing which direction the client has chosen. Approval is a separate event: an authorised person accepts a specific version for a defined use. Treat neither a friendly comment nor silence as that decision.

Name one approver before the first review

Three people at the client comment on the same draft. The marketing lead wants the photo bigger, the founder wants it gone, and a sales manager adds a thumbs-up in Slack. Who decides? The approver, and you want that settled at onboarding, not on the day the conflict lands in your queue.

The requester may collect input from as many colleagues as they like, but one person resolves conflicts before the studio starts a revision. Write down who can approve, what they are approving (a direction, a final file, a print proof) and which checks stay with the client. Your studio can own layout quality without owning the accuracy of the client's product claims.

Include a substitute approver or a rule for absence. Otherwise a request can wait for a week while your team tries to infer authority from whoever replied most recently. The client onboarding guide puts the approver and substitute on the account card before the first brief arrives.

Run one review round in five steps

Slack is where approvals go to disappear. A "looks great!" in a channel is not attached to a version, and it scrolls away under the next five messages. On Slack's free plan, only 90 days of message history stays visible (Slack pricing page). Keep Slack for nudges. Keep comments on the file and the decision on the card.

  1. Name the version. In Figma, name the page or frame with the request and version, such as "Acme social set v2, 9 Oct". Say what decision you need: pick a direction, or approve for publishing.
  2. Send everyone to one place. Reviewers comment in Figma, pinned to the element they mean. Ask each comment to name the element, the problem and any replacement copy or asset. Record a two-minute Loom walkthrough with the version so the client hears your reasoning before they react. Loom Starter is $0 (Loom pricing).
  3. The approver merges the comments. The client approver turns scattered comments into one change list. Anything they cannot decide gets marked unresolved, not quietly picked by your designer.
  4. You check scope. Read the change list against the original brief. Confirm the effort and any effect on the queue before anyone opens the file.
  5. Share the next version with a change summary. Post v3 with three or four lines on what changed, then ask for approval of v3 by name.
A loop: version 2 shared in one place, reviewers comment, the client approver merges comments into one change list, the studio checks scope, version 3 is shared with a change summary, the approver records approval of version 3 on the request card.
Never hand your designer a pile of opinions. The client approver merges them into one change list, and a round only ends when a named version is approved.

Speed follows from a clean change list. Brett Williams, who ran DesignJoy on his own, said in a 2021 Indie Hackers AMA that revisions were "usually completed the very next day". That is one operator's practice, not a benchmark. It only works when the designer starts the morning with one instruction set, not five opinions to reconcile.

Worked example: two opinions on v2

This example is illustrative. You deliver v2 of a six-post LinkedIn set for a software client. The marketing lead comments "make the product screenshot the hero on every post". The founder comments "too salesy, lead with the customer quote". Your designer should not choose between them.

The marketing lead is the named approver, so the conflict goes back to her. She returns one instruction: "Lead with the customer quote on posts 1 to 4. Keep the screenshot as hero on posts 5 and 6. Swap the CTA to Book a demo on all six." That is one change list, inside the original brief, and your designer can finish v3 the next day.

Revision or new request?

Before you sell "unlimited revisions", decide what a revision is. ManyPixels lists "Unlimited revisions" on every plan, with its Advanced plan at $699 a month (ManyPixels pricing). That promise holds only because a boundary sits behind it. If you plan to charge $3,995 a month for one request at a time, protect that slot. A client who keeps turning revisions into new work is quietly taking that slot for free.

The test: compare the change with the accepted objective, audience, format and supplied content. Fixing work that missed the agreed brief is a revision. Replacing the objective after a direction was accepted, or adding a deliverable, is a new request that joins the queue.

Three common changes and how to call them
Change the client asks forCallWhy
Swap the headline font to the one in their brand guideRevisionSame objective and format. The draft missed a supplied brand rule.
New headline copy after v2Revision if it fixes an error or tightens the agreed message; new request if it changes the message or audienceSupplied content changing a little is normal. A new campaign idea on the old layout is new work.
Turn the approved LinkedIn set into Instagram stories and a printed flyerNew requestNew formats are new deliverables, even when they reuse approved artwork.

Do not label every inconvenient comment out of scope. Explain the particular boundary, offer a way forward ("we can do the stories as the next request, starting Thursday") and let the approver choose. Write the rule into your offer before the first client pays; the service design and pricing guide covers where it goes.

Record the approval where the work lives

The yes belongs on the request card, next to the file link, not in a Slack thread. On a Trello card, the approver or your account lead adds one comment line in a fixed format:

Approved v3, 14 Oct, by the marketing lead (named approver), for LinkedIn publishing.

That line holds the version, the date, the person's role and the use. Trello's free plan covers up to 10 collaborators per Workspace. That is enough to invite your client's requester and approver to their board (Trello pricing). If the approval arrives by email or Loom reply, copy it onto the card the same day.

If an approved file later changes, reopen review for the changed version rather than reusing an approval that no longer describes it. Be plain with clients about what the line means: it approves the design for the stated use. It does not cover legal, accessibility or print checks. Those stay with whoever the agreement names.

The workflow and approval checklist gives you the card fields and the close-out checks. Once the line is on the card, the request can move to delivery, as set out in the requests and delivery guide.

When Figma comments stop being enough

Figma comments, a Loom and a card line cover most static design reviews, and Figma's Starter plan is free (Figma pricing). When you review video, PDFs for print or files for clients who will not open Figma, compare the proofing tools and prices in proofing and feedback software.