From feedback to a clear decision.

The design is ready. The decision is still somewhere in the conversation.

A designer sends a homepage for review. The client responds with a suggestion. A studio lead adds another note. A revised file follows. Before the next change can begin, someone has to work out which version everyone means and what has actually been agreed.

This is the situation I designed Accord around: small studios moving creative work between a designer, a studio lead, and a client. The project asks how a review workspace could keep the design, the conversation, and the next decision together.

To explain the design, this case study follows one illustrative homepage review for North Studio. The people and comments shown in the screens are demonstration content, rather than interview findings.

I started with the gap between sending a file and knowing what to do next.

A deadline tells a designer when work is due. An assignment tells them who owns it. Neither explains whether a client is reviewing the latest file, whether a comment needs an answer, or whether the work has been approved.

I framed the problem around those moments of uncertainty. My hypothesis was that attaching feedback and decisions to a specific version could make the handoff clearer. Scattered messages and outdated files remained problems to investigate, rather than findings I could claim from interviews.

The opportunity was a clearer review cycle.

The desk research pointed to existing approaches: contextual comments, version comparison, and explicit review decisions. The linked agency account and product documentation helped establish relevant patterns; they did not prove that studios would adopt Accord.

That shifted the design question from how many features to include to how clearly one review could move forward. I focused on the information each person needs at the moment they have to act.

Take one deliverable from “please review” to an approved version.

I chose one homepage design as the deliverable, meaning the item being reviewed. The designer prepares it, the studio lead checks it internally, and a named client approver makes the final decision.

At each step, the interface needed to answer three questions: Which version am I looking at? What needs attention? Who acts next? Those questions became the thread connecting the overview, the viewer, the feedback states, and the handover.

I kept the wider studio in view, then followed one piece of work.

I designed the information architecture, review flow, interface screens, and shared component system. The overview accommodates several clients and projects, while the detailed screens follow one review and revision cycle.

I left payments, hiring, contracts, and time tracking outside the project. Adding them would have expanded the workspace without answering the central question. The design effort stayed with the transition from a file to feedback, a revision, and a recorded decision.

The structure moves from studio overview to project, then to the current deliverable and its review history. This gives the studio lead a way to scan the work while giving the client a direct route to the item that needs a decision.

The studio lead needed a place in the flow.

A direct designer-to-client conversation is only one way a review can happen. I included an internal check before the client review, so the studio can align on the work before asking for an external decision.

I also considered feedback received on a call. A lead should be able to record that feedback while identifying whose request it represents. Recording a note must remain separate from approving work on the client’s behalf.

A finished comment is not an approved design.

This distinction shaped the rest of the experience. Resolving a comment means the team has dealt with that request. Approval means a named person has accepted a specific file version. Combining those actions would leave the status of the whole design unclear.

I therefore kept comment states and review decisions separate. I also made the current version the default destination, with previous versions available for comparison. Earlier feedback keeps its original context instead of silently moving onto a changed layout.

For this design, one named client approver owns the final decision. That keeps the review understandable, but studios needing several approvers would require further exploration.

First, give everyone the same place to begin.

The studio overview brings the deliverable, designer, reviewer, stage, deadline, and next action into the same row. A lead can see where a decision is waiting before opening the project.

Inside the review, the current file sits beside its feedback. The brief and responsible people stay nearby. I gave the design most of the space and attached the comment to a specific area, so the client can point to the issue instead of describing its location in another message.

Then, turn a vague comment into an actionable request.

In the example, the client writes, “The main action doesn’t stand out enough.” That identifies a concern, but it leaves the designer guessing whether to change the wording, emphasis, or intended action.

The designer asks whether booking a consultation should be the priority. The client confirms it in the same thread. I used a “Needs clarification” state to make this waiting point visible, preserving the answer beside the original request.

The next revision can now follow a specific direction: make “Book a consultation” the primary action and keep exploring the work secondary. The reason for the change remains visible to the next reviewer.

Before approving, make the change easy to check.

The comparison view places the previous and current designs side by side, with explicit version labels. The reviewer can check whether the revision addresses the request before resolving its feedback.

I kept the final decision separate. “Request changes” leaves the version unapproved and sends work back for revision. “Approve version” names the exact file being accepted. In the proposed flow, unresolved feedback must be dealt with first; that rule still needs testing with teams that allow non-blocking suggestions.

A later revision starts another review. It cannot inherit an approval given to an earlier file. This keeps a decision attached to the work the client actually saw.

Finally, let the review end with something clear to hand over.

Once the client approves version 3 in the example, the handover brings its download and approval record together. The record identifies the approver, the version, and the time of the decision.

The approved file becomes the main action, while the history remains available for reference. The designer and client can leave with the same understanding of what was accepted, without rebuilding the decision from the conversation.

The result is a designed review cycle, ready to evaluate.

Accord brings one deliverable through contextual feedback, clarification, comparison, and version-specific approval. The screens show how the next action stays connected to the decision before it.

This is an unlaunched design exploration. No participant interviews or usability tests have been completed, and there are no measured business results. The next step is to evaluate the workflow with designers, studio leads, and client approvers.

The question now is whether the clarity holds up in use.

I would ask participants to identify the current version, clarify a request, check a revision, and approve the correct file. I would watch where they hesitate, especially when distinguishing a resolved comment from an approved design.

I would also examine the effort needed to keep the record current. A shared workspace is only useful if updating it fits the way a studio works. The design gives those questions something concrete to test.