How to Make Design Feedback Actionable

“Make it cleaner” can describe a real problem. It just does not tell the designer which problem you noticed. The page might have too many competing actions, an awkward gap, dense copy, inconsistent alignment, or all four. A reasonable revision to one of those issues can leave the reviewer feeling that nothing improved.

Actionable design feedback connects a specific part of a design to an intended outcome and gives the next person enough context to make a useful decision. It does not require you to supply the final solution. Often the most valuable comment explains the problem clearly while leaving room for the designer to solve it.

How to give design feedback someone can act on

A useful comment usually contains a location, an observable concern, and a reason it matters. A proposed direction can help, but it should not conceal uncertainty about the problem. “Move the button” is specific about an action while still being vague about the outcome that action should improve.

Consider a fictional course landing page. “The page feels busy” is a reaction. “In the opening section, the course title, discount badge, and newsletter form all have similar visual weight; I cannot quickly tell whether enrollment or newsletter signup is the main action” identifies the conflict. The designer can now investigate hierarchy rather than guess which decoration the reviewer dislikes.

The comment can end with a question or a proposed direction: should enrollment be the dominant action here? That is a useful question if the priority has not been agreed. If enrollment is already the approved goal, ask for a version that makes it dominant. Do not turn a settled decision back into an open discussion simply because the feedback format contains a question mark.

The Nielsen Norman Group guidance on design critiques emphasizes evaluating a design against its objectives, giving the discussion a clear scope, and treating critique as a conversation. Those principles help separate useful feedback from a collection of preferences. The examples below translate that general approach into concrete interface comments.

Figma’s team found that the critique itself needed redesign

In Figma’s account of its design critique process, Noah Levin describes team feedback about shallow discussion, unhelpful agreement and comments that did not unblock work. The team collected those concerns in a Figma file, grouped them and continued the discussion in a dedicated Slack channel. It then used different critique formats for different needs, rather than expecting one meeting format to suit every stage.

The team’s diagnosis reaches beyond the wording of individual comments: a comment can be specific and still arrive in a discussion that cannot act on it. The wrong question, too little context or an unresolved decision owner can make an otherwise thoughtful review ineffective.

Before requesting feedback, state the maturity of the work. A concept needs discussion about the problem and direction. A nearly finished form needs attention to wording, states and interaction. If a reviewer believes the direction is open while the designer believes only spacing remains, both can leave frustrated without either having behaved badly.

For the course-page example, an effective opening could be: “Enrollment is the agreed primary action. The audience and price are fixed. Today I need help deciding whether the opening section explains the prerequisites before asking for commitment.” That gives reviewers a live question and protects settled facts. It does not instruct them to approve the layout.

Another message in the same published discussion proposes a critique sheet that states the feedback the presenter is and is not looking for, and aligns the feedback method before the session. That is a useful response to rushed discussion: move the scope-setting out of the meeting’s opening scramble. For the course page, put the enrollment goal and the prerequisite question on the review invitation, then reserve the session for examining the actual screen. A brief scope does more work than a longer list of rules about being constructive.

Triage the comment before editing the screen

A good critique should leave fewer unresolved questions, not merely more annotations. After collecting comments, sort by the kind of response each needs.

The distinction becomes practical when two comments conflict. “Shorten the page” and “explain eligibility” may both be satisfied by removing repeated background and moving eligibility earlier. “Prioritize two different actions” may require a business decision. Do not resolve the second conflict with two equally bright buttons and call it a compromise.

Separate observation, interpretation, and proposal

These three parts often get compressed into one confident sentence. “Users will ignore this button, so make it orange” combines a prediction and a solution without showing the observation behind either. Unless you have evidence of people ignoring it, that prediction should remain a concern to investigate.

An observation might be that the button has the same pale border as three secondary links. The interpretation is that its priority may be difficult to recognize. The proposal is to give the primary action stronger visual emphasis. That sequence lets another person disagree productively: perhaps the action is intentionally secondary, or perhaps contrast is sufficient but placement is the actual issue.

You do not need to write three labeled paragraphs for every comment. A natural sentence can carry the distinction. “The enrollment button uses the same treatment as the syllabus link. Since enrollment is the main task on this page, could we make its priority more visible?”

When you do have research evidence, identify it accurately. A reviewer’s difficulty is one observation. A recorded usability session is a different kind of evidence. An analytics pattern is another. Do not convert “I hesitated here” into “users cannot complete this task,” and do not discard the hesitation merely because it is not a formal study. Labeling its basis makes it useful at the right level of confidence.

The OpenDesign example below is an unsent element-comment draft: it identifies the selected word, the replacement and the styling to preserve.

Six common comments, made actionable

“Make the page cleaner”

Start by identifying what competes for attention. On the fictional course page, the opening section contains an enrollment button, a newsletter form, a video button, three badges, and a row of partner marks. Removing random items might produce a quieter screen, but it could also remove the information a visitor needs to decide.

A more useful comment would be: “The first screen asks visitors to enroll, subscribe, and watch a video before explaining who the course is for. Can we make the audience and enrollment path easier to read first, then place the newsletter invitation later?” This gives the designer a sequence to improve rather than a vague aesthetic target.

Review the revision against the same concern. Can someone now identify the audience and main action? If yes, acknowledge that improvement before introducing a new preference about the badge style. Constantly replacing the success criterion makes any design process feel arbitrary, even when each individual comment sounds reasonable.

“The spacing feels wrong”

Spacing feedback becomes useful when it names the relationship that is unclear. “Add more whitespace” might improve a dense section, but it can also break useful grouping and make related information feel disconnected.

Imagine a pricing card where the monthly price sits closer to the first feature than to the billing note beneath it. A concrete comment is: “The billing note visually groups with the feature list. Bring it closer to the price so the cost and billing period read together, then keep a clearer gap before the features.” The requested outcome is a grouping change, not simply more empty space.

If the issue is comfort rather than grouping, say so. “The paragraph and action button nearly touch on the narrow layout. Give them enough separation to read as distinct elements while keeping the button visibly attached to this section.” This is still actionable without inventing a pixel value that has not been checked at other widths.

“It needs to look more premium”

“Premium” can mean restrained, editorial, technical, luxurious, or simply expensive-looking. It is a legitimate brand intention only after the team makes the intended qualities more concrete. Otherwise one person may add gold gradients while another removes every decorative element.

For a fictional architecture portfolio, a better comment is: “The project photography is strong, but the bright badges and rounded promotional buttons give the page a retail feel. I want the work to carry more of the visual weight. Explore quieter controls, a more restrained color balance, and larger project imagery while keeping the existing type family.” The reference to a desired quality is now connected to visible choices.

A reference image can help, but explain which property you mean. “Use the composition and close relationship between headline and image” is different from “copy the color palette, font, and subject.” A small note about the relevant feature can prevent a reference from becoming an accidental instruction to imitate everything in it.

If you cannot yet articulate the quality, compare two specific alternatives. Ask what changes the impression between them. It is easier to discuss the amount of contrast or the prominence of photography than to argue over whether a page is sufficiently sophisticated. The goal is to turn taste into a shared direction, not to pretend taste plays no role.

“The copy is too long”

Length is sometimes the problem, but sometimes the problem is order. A useful answer may be buried in the fourth sentence while the first three explain the company’s ambitions. Cutting all sentences equally preserves the underlying weakness.

For a signup page, try: “The paragraph explains our approach before telling the visitor what happens after signup. Lead with the first useful outcome and the next step, then remove the repeated explanation about simplicity.” This gives the writer a clear editorial decision. It also avoids a word limit that may be too strict for the information the visitor actually needs.

If the layout imposes a real constraint, name it. “At the narrow viewport, the introduction pushes the first field below the initial view. Can we reduce the repeated context while keeping the information about the required work email?” The constraint is concrete, but the feedback protects a piece of content that matters to the task.

Be wary of treating every explanatory sentence as clutter. A short form that hides an important condition can be less usable than a longer one that makes the commitment clear. Review what a person needs to know before acting, then decide which words earn their place.

“The form is confusing”

This comment may refer to labels, the sequence of questions, an unexpected requirement, or feedback after submission. Ask where the uncertainty begins. A screenshot with a circle around the whole form rarely narrows the problem enough.

Suppose a fictional contact form asks for “Company size” and offers ranges without saying whether they refer to employees or customers. An actionable comment is: “The Company size options are ambiguous because the unit is missing. Specify that the question concerns employees, and check that the option labels use that same meaning.” That is a precise content change with an easy review criterion.

A different concern might be: “After submission, the message says one answer is missing, but it does not identify which one. Show the affected question and give a direct route back to it.” Here the problem concerns recovery rather than the original field design. The feedback should not trigger a redesign of every question.

The Nielsen Norman Group article on actionable usability findings explains why specific, descriptive findings help teams act and why observations should identify the design issue rather than blame the person using it. Apply that discipline even in an informal review. “The label omits the unit” is more useful than “People don’t read carefully.”

“Mobile doesn’t work”

A mobile comment needs a location and a condition. A page can be readable at one narrow width and fail when text grows, a menu opens, or a long title appears. “Fix mobile” hides the evidence that would make the issue reproducible.

A useful comment might be: “In the narrow preview, the project title wraps to three lines and pushes the download action outside the card. Keep the full title readable and allow the card to grow so the action remains inside its boundary.” The designer now knows both the trigger and the intended result.

Another example is: “When the navigation menu is open, the close control overlaps the page title. Review the open-menu state at this width and give the control a stable position.” The issue is not the entire mobile page; it is one interaction state under a specific condition.

Include the viewport or device context when you know it. “At 390px, with the navigation open” gives the next person a reproducible condition to check; “on mobile” leaves the failure ambiguous.

Decide whether the next step is a revision, a decision, or a test

Not every useful comment should become an immediate edit. Some reveal a missing product decision. Others describe a hypothesis that needs evidence. Converting all comments into implementation tasks can make a team very busy without making the design more coherent.

If the approved objective is clear and the design visibly conflicts with it, a revision is usually appropriate. If the comment exposes two competing objectives, someone needs to decide which takes priority. If it predicts behavior without enough evidence, a small test or review may be the right next step.

For the course page, “Make enrollment the primary action” is a revision when that priority is already agreed. “Should we prioritize enrollment or newsletter growth?” is a decision. “Visitors may not understand whether the course is live or recorded” is a concern that can first be examined through the actual copy and then tested with prospective readers if uncertainty remains.

Keep these outcomes distinct in your notes. A designer should not be expected to resolve a business priority by choosing a brighter button. Similarly, a product manager should not have to approve every small spacing correction. Clear next steps let each person contribute at the right level.

Handle conflicting feedback by returning to the task

Ask what each comment is trying to protect. Then inspect whether a design can satisfy both concerns through order, grouping, or progressive disclosure. Perhaps the eligibility answer belongs near the main action, while repetitive company background can move lower or disappear. The result is not a compromise measured by word count; it is a clearer information structure.

When the objectives truly conflict, document the choice and its reason. For example, a page aimed at qualified enterprise buyers may intentionally include detail that a casual visitor does not need. That decision should come from audience and purpose, not the seniority of whoever spoke last.

Do not quietly average incompatible aesthetic instructions. A design that is halfway between playful and solemn may express neither. Show the tradeoff with a concrete example and resolve the direction before making another full version. One focused decision can save several rounds of superficial revision.

Use comments in OpenDesign to keep the discussion concrete

In a supported HTML preview, OpenDesign can help you inspect the actual text and layout being discussed. You can make manual changes to text, links, images, and styles, inspect viewport presets, and send comments into chat. Use those capabilities to attach a concern to visible work rather than carry an abstract debate about what the page might look like.

A good comment still needs enough context to stand on its own. Name the affected element, state what you observed, and describe the intended improvement. If you attach an image reference, say which feature should guide the revision. The tool can carry the comment; it does not make a vague comment precise by itself.

After a revision, compare the same element under the same condition. If the original concern was a wrapped title pushing a button outside a card, use that long title again. A short replacement title can hide the problem without solving it. Keep the evidence stable enough that you can tell whether the design improved.

Close a feedback loop with a visible result

The final step is to say what happened to the comment. A short response can record that the issue was resolved, that the proposal was changed for a stated reason, or that a decision remains open. This is especially useful when several people review at different times.

For the pricing example, a useful closure is: “The billing note now sits with the price, and the feature list begins after a larger gap. The narrow layout keeps the same grouping.” That is more informative than “Done,” because it connects the change to the original concern. It also gives the reviewer something specific to verify.

Positive feedback should be just as precise. “The revised grouping makes the billing period easy to find; keep that relationship in the other cards” tells the designer what is working and should survive later changes. Praise that identifies a successful choice is part of maintaining quality, not merely a courtesy.