Brand Design

Design revisions: Turning scattered feedback into decisions

Turn design feedback into clear decisions with shared objectives, version control, priorities and defined scope, keeping revisions useful and traceable.

A person drawing a colourful illustration on a tablet with a stylus

One manager wants a larger logo, another asks for more space and sales says an explanation is missing. Comments arrive through separate messages while the designer tries to identify the final decision. Revision has become a coordination problem as much as a design task. Applying every request in order can create new contradictions. The solution is not to silence feedback but to connect it with a shared objective and an intelligible decision process.

Iteration is a normal part of design. A first proposal may not settle every detail, and real content or production information may reveal a need. If the fundamental purpose changes every round, however, the brief, authority or scope may be incomplete. A useful process makes the problem, retained decisions and consequences of new requests visible so both parties continue working on the same project.

State the question for this review round

Choosing a direction differs from checking final production artwork. Early discussion may concern perception and the main arrangement; later review may focus on wording, alignment and technical suitability. Reopening everything every time slows progress. State what this round is intended to decide and identify any placeholder text or unfinished imagery.

That distinction helps reviewers focus. A punctuation issue in temporary copy can be noted without replacing the main discussion about direction. A new positioning debate at the print-ready stage represents a substantial change. When the stage is clear, comments are easier to prioritise. Everyone should understand which decisions remain open rather than infer the status from the appearance of a polished file.

Return feedback to the agreed objective

Begin with the problem the design should solve: the customer, information priority and critical use condition. If those points were never established, clarification may be needed during revision. Adding many changes to an uncertain objective does not explain why the work succeeds or fails. A shared basis makes different forms of expertise more useful.

Imagine a fictional service page comparing three packages. Sales reports that buyers cannot distinguish scope. That observation is more fundamental than an instruction to enlarge a heading. The designer might solve it through a table, explanation or layout. Understand the need before treating one proposed action as the only solution. It may still be appropriate, but the reasoning leaves room for design judgement.

Distinguish preference, observation and request

A colour feeling cold is a reaction. Small text being difficult to read against a background is an observation. Changing the primary colour is a proposed solution. All can be discussed, but they are different inputs. When the problem behind a request is not explored, the designer can become an instruction executor rather than a contributor to solving the brief.

A concise feedback format can identify location, issue and effect on the objective, followed by an optional suggestion. Product names merging in a small list describes a task problem. Device or viewing size adds useful context. Make it better does not offer the same information. When the issue is located, the revised result can be checked against it more readily.

Consolidate stakeholder input before sending it

Sales, operations, technical staff and management contribute different knowledge. Collecting it is useful; forwarding contradictory requests unresolved transfers the client's decision problem to the designer. Name someone to consolidate comments and clarify who has final authority. Those roles can differ, but their relationship should be explicit.

Consolidation is more than pasting every message into one document. Group related points, remove repetitions and resolve conflicts. A larger logo and more space may compete for the same area. Designers can show alternatives without having to invent the organisation's commercial priorities. Establishing that arrangement within brand design work helps feedback support the creative process instead of continually interrupting it.

Identify the version behind every comment

Notes on an old PDF can conflict with comments on a new link. Establish the review source and version. If the content behind a link changes, retain enough history to understand the state that prompted a comment. Screenshot feedback should identify page and area. A filename containing final is not a complete version system; a clear date or version can help.

Shared review tools can support this arrangement. Adobe's shared-file commenting guidance illustrates location-based comments and resolution states. Whatever the application, the underlying need is traceability of location, meaning and outcome. Choose a process the team can access rather than creating another source of confusion through an unfamiliar tool.

Complete a marked screenshot with a reason

A red circle can locate an issue without explaining why a change matters. Add a short explanation, particularly for type, colour or spacing. Note the scale at which it was viewed. A subtle detail noticed in a magnified image and unreadable text on an actual phone may have different priorities. The annotation should help the next decision, not merely indicate dissatisfaction.

Separate a correction from changed scope

A typo in approved copy, an application adjustment within the chosen direction and a new layout for an additional service are different tasks. Revision scope should acknowledge that. A new audience or name can affect the entire project. Treating it as a minor correction distorts expectations about time and cost. Make the effect visible before continuing.

A scope change is not necessarily undesirable. Research may reveal a worthwhile need. Record the affected deliverables, information to prepare and approvals requiring reconsideration. A concise impact note helps explain why the work changes. The updated plan then reflects the new requirement rather than making additional time appear to be unexplained slowness.

Prioritise according to consequence

A problem causing customers to choose the wrong product differs from a small aesthetic preference. Meaning, function, accuracy and production obstacles may need attention first, followed by hierarchy and refinement. Giving every point identical importance can divert effort from the significant issue. Prioritisation helps solve the right problem before improving less consequential details.

Dependencies matter within a round. Finalising spacing before a major content change can create repeated work. Establish the core information and arrangement before the relevant detail review where appropriate. This is not a rigid sequence for every project. It is a way to see which decisions affect others. Designers should explain those relationships so intermediate approvals have a clear purpose.

Allow reasoned alternatives

The designer need not agree automatically when a requested action weakens the objective. Dividing content instead of shrinking text, improving contrast instead of enlarging the logo or changing order instead of adding boxes may be worth considering. An alternative should address the problem rather than dismiss the client's contribution. Keep the discussion centred on use and purpose.

Clients can question the rationale too. If a designer argues that something must be retained, ask which need and example support the view. Expertise should not become unexplained authority. A small application comparison or realistic content test can make the discussion concrete. Collaboration does not require either party to accept every request or explanation unconditionally.

Explain what changed in the next version

Include a short summary showing implemented points, alternative resolutions and open issues. Marking a comment resolved does not necessarily mean the suggested action was followed exactly. Record the decision so the same question does not return ambiguously at the next meeting. Reviewers can then focus on the genuinely new state rather than reconstruct the change history.

At approval, state what has become final. Agreement on a visual direction can differ from approval of production artwork. Relevant owners should check names, copy, contact information and technical output. Discuss the effect of later changes as well. A healthy revision process is not simply the one with the fewest rounds; it produces understandable decisions and a result that meets the intended use.

Keep the accepted review record with the delivered version. Someone joining later should be able to see why an apparent preference was selected and which constraints mattered. This reduces unnecessary reopening of settled questions. Where new evidence does justify another change, the record also makes it easier to distinguish a fresh requirement from an overlooked correction.

Frequently asked questions

How can we make a design comment more useful?

Identify the area, observed issue and effect on the objective. Add a proposed solution separately if helpful. This lets the designer understand the need behind it. A realistic use example gives a more concrete starting point than a general preference. State the version and viewing conditions where relevant.

Should every stakeholder provide feedback?

Include people whose knowledge the project needs, but do not treat every comment as an independent decision. A responsible person should consolidate input and resolve conflicts, with final authority clear. More participants without a shared review arrangement can create disorder rather than improve the quality of the result.

Why is a revision count not a complete scope definition?

One round can contain a small adjustment or a completely new direction. A changed name, audience or deliverable has a different effect. Explain what revisions cover and how new requests will be assessed. Counting rounds alone does not ensure that client and designer attach the same meaning to them.

What if the designer does not follow our suggestion?

Ask for the reason and how the alternative addresses the need. Agree on the underlying problem. An application example or short test can make the discussion tangible. If the requested action would weaken the objective, that should be explained. The decision should rest on use and goals rather than authority or preference alone.

What belongs in final approval?

Identify which elements are becoming final and assign the relevant checks. Copy, names, contact details, appearance and technical output may involve different owners. Record the approved version. Approving a direction and approving the production file can be separate activities; keeping the distinction clear prevents assumptions about what has already been checked.

All articles