Start with the brief, not the final image

When a project is finished, the most tempting question is often, “Does it look good?” That matters, but it is not the same as asking whether the work does what it was meant to do. A visual identity might feel distinctive yet be hard to use on small screens. A photographic series might be beautifully lit yet fail to show the people or process the client wanted to introduce.

Begin the review by finding the original brief, proposal or notes from the first planning conversation. Write down the intended audience, the problem to solve, the promised deliverables and any practical constraints. Then separate goals from preferences. “Help first-time visitors understand our services” is a goal; “use a warm colour palette” may be a proposed way to reach it. This distinction gives you room to judge the result without treating every early idea as a requirement.

Make room for goals that changed

Creative projects rarely follow their first plan exactly. A team may discover that a message is unclear, that an asset is needed in a new format or that a proposed direction does not suit the audience. Before comparing the finished work with the original goals, record any changes that were discussed and accepted during the project. Note why they were made and who agreed to them.

Keep the original and revised goals side by side. This prevents a useful change from looking like an unexplained failure, while making it harder to quietly rewrite the brief to suit the final result. If a change was never clearly agreed, name it as an open question. The review can then ask whether the decision was reasonable and how a similar decision should be handled next time.

Review the work in the setting where it will be used

For each goal, look for something observable in the finished work. If a new identity needed to help a small team produce consistent materials, examine its templates and guidance as well as its main logo. If a workshop needed to generate options for a campaign, look at the range of ideas produced and whether the team could identify a direction to develop. Avoid relying only on whether people liked the presentation.

Use realistic conditions for the check. View a poster from a distance, test a page at a narrow screen width or ask someone unfamiliar with the project to explain what they think a photograph communicates. A small, informal check cannot prove how every audience member will respond, but it can reveal gaps the project team has stopped noticing.

A simple review grid can keep the discussion specific: list each goal, the part of the finished work that addresses it, what appears to work and what remains uncertain. Leave space for “not yet tested.” That is more useful than forcing a confident verdict where there is little evidence.

Discuss decisions rather than defend them

A review works best when it is not a trial of the person who made the work. Ask the team to describe why key choices were made and what trade-offs they accepted. For example, a compact identity system may be easier for a client to maintain but offer less variety than the team initially imagined. Both observations can be true.

Invite feedback with questions tied to the brief: “Which part helps a new visitor find the next step?” or “Where might this image be difficult to crop?” These are easier to act on than “What do you think?” Keep comments about the work and its use, not assumptions about anyone’s effort or taste. If several people are reviewing together, let them make brief notes individually before discussion so the first opinion does not set the direction for everyone.

Turn the review into a useful record

Close with a short account of what met the goals, what needs adjustment and what cannot yet be judged. Give any remaining changes an owner and a clear next action. Some questions, such as how easily a client can use a template over time, may need a later check rather than an immediate answer.

Finally, record one or two lessons about the process itself. Perhaps the team needed to agree on success criteria earlier, test a format sooner or document a change in scope more clearly. Keep this record alongside the finished files and brief. The purpose is not to prove that every decision was perfect; it is to make the project’s reasoning visible and help the next project start with better questions.

Back to category ↗