Website Design Revision Log Template: Keep Changes and Decisions Clear

A website design revision log records why a change was requested, what the team decided and how the result was checked. It is more useful than a list of filenames because it connects the evolving design to the decisions behind it.

You can keep the log in a document, spreadsheet or project system. The format matters less than consistent fields and a clear owner. Use the structure below for a small design project, then add complexity only when the work requires it.

Separate a request from an agreed change

A client comment is an input, not automatically an instruction ready for implementation. It may contain a factual correction, a preference, a question or a request that changes the scope. Record the original concern before translating it into a design task.

For example, “the page feels expensive” could refer to the visual tone, an unclear price explanation or the wrong target audience. Changing the color immediately may miss the actual issue. The log should show what was clarified and which response the decision owner agreed.

Use fields that answer practical questions

Include an item identifier, date, artifact or revision, location, request, decision, owner, status and verification note. Add a link to the relevant preview or source discussion. This is enough for most small projects without creating an elaborate tracking system.

Keep each field focused. The request describes the concern; the decision describes what the team will do; the verification note explains whether the result addressed it. Combining all three into one long paragraph makes the history harder to follow.

Start with a compact status model

Useful states include new, needs clarification, agreed, in progress, ready for review and closed. You can also use deferred for an idea that belongs in a later stage. Define what each state means so that a reviewer does not mistake “ready for review” for “approved.”

Avoid moving an item to closed merely because someone uploaded a new file. The change may still need confirmation. For a factual correction, verification could be a check by the content owner. For a design concern, it could be the decision owner's response to the revised preview.

Example: clarify the pricing section

Suppose a client says the setup fee looks like part of the monthly price. The location is the second pricing card, and the desired outcome is for visitors to distinguish recurring and one-time costs. The agreed task is to separate the labels and revise the supporting note.

After the update, record the revision containing the change and ask the factual owner to confirm the wording. The verification note should say whether the distinction is now clear. This preserves the reason for the change instead of leaving only “pricing edited.”

Example: handle conflicting feedback

One stakeholder asks for a shorter homepage while another requests three additional sections. Record both requests and identify the conflict. Ask the designated decision owner to set the priority before the designer starts making contradictory revisions.

The final decision might be to keep a concise homepage and move detailed information to service pages. The log should retain the reasoning and the agreed destination for the extra content. That helps if the same discussion reappears later.

Example: record a deferred request

A suggestion to add a customer portal may be useful but outside the current visual review. Mark it deferred, state why and record who will assess it for a future phase. Do not leave it among immediate design corrections where it can be mistaken for an unfinished task.

If the request changes the agreed project scope, discuss its effect on deliverables and schedule. A revision log makes the issue visible; it does not determine commercial or contractual terms on its own.

Pair a stable preview link with a revision label

Swelik allows the owner to replace a mockup while keeping the public URL. That is convenient for the active review, but the URL by itself does not identify the exact content that was visible last week. Record a revision name or date alongside the link.

Keep dated exports in your own archive. When a client mentions an old screenshot, you can compare it with the current revision without guessing. The preview is the current review destination; the archive preserves the historical artifact.

Write a useful change summary

When a revision is ready, summarize the meaningful changes in terms of the concerns they address. “Separated setup and monthly costs” is more useful than “updated version three.” Identify any items still waiting for input or confirmation.

Ask the client to reload an already-open preview before checking the update. Then direct them to the relevant sections instead of making them rediscover every change. The feedback questions guide can help phrase the verification request.

Keep comments and private information separate

Do not store passwords, account secrets or private management URLs in a log that is shared broadly. Use the appropriate secure access process for credentials. Keep the log focused on the design and the decisions needed to move it forward.

Also consider who should see internal notes. A client-facing revision summary may not need every internal implementation discussion. Share the information necessary for a clear decision without confusing the reviewer with unrelated work.

Close a review round deliberately

Before closing the round, check that each agreed item is resolved, deferred by agreement or clearly waiting on a named owner. Record the deliverable that moves forward and any conditions. Do not let an empty inbox stand in for an explicit conclusion.

Use the design approval guide to define the scope of a decision. A clean revision log supports that decision by showing what happened between the first comment and the accepted artifact.

A reusable entry format

Copy these fields into your preferred tool: item ID; date; project and revision; page or section; original concern; desired outcome; agreed response; responsible owner; status; preview reference; verification result. Keep the entry short enough that the team will update it.

At the start of each review, filter for unresolved items. At handoff, retain the completed log with the relevant exports and decision record. It becomes a practical explanation of the project rather than a forgotten administrative task.

Frequently asked questions

Is a revision log necessary for a small project?

A lightweight version can help even when there is only one page and one reviewer. It is especially useful when feedback arrives over several days or channels. Keep it proportionate to the work.

Should I delete rejected ideas?

Usually, retain a short record of the decision and its reason. That prevents the same idea from returning without context. You do not need to preserve every informal thought, only the requests that affected the review.