Requesting website changes: what to prepare for your designer

A useful change request tells the designer what the customer needs to do and what is preventing it. "Make it less plain" may describe your reaction, but it does not explain which part of the page needs to change or what the change should achieve.

You do not need to design the solution yourself. Give the team enough information to assess the problem, propose an approach and explain the scope.

Identify the customer task

Start with the reason for the request. You might want customers to understand a particular service, send better quote information or find a contact option more easily.

For a hypothetical equipment hire business, "Customers cannot tell which trailer suits their load" gives the designer something to work with. The solution might be clearer specifications or a comparison, rather than a larger heading.

business.gov.au's website guide recommends planning around customer tasks and keeping website information current. Use those tasks to explain the priority of a change.

Locate the issue precisely

Send the page address and name the section. If it is a problem you observed, include the device, browser and steps that led to it. A screenshot can help, but describe the issue in words too.

For a wording change, provide the current text and the exact replacement. Explain whether the replacement appears elsewhere, such as another service page or the footer.

For a design concern, describe the effect: "The enquiry button is hidden below the booking information on my phone." Avoid insisting on a particular technical fix unless it is a requirement of the business.

Supply usable content

Send approved copy and original image files rather than photos pasted into a document if the originals are available. Name each image so the designer knows where it belongs.

Explain the subject, any important crop and whether people shown have agreed to publication. Do not supply private customer information or images you do not have permission to use.

If you need writing or photo selection rather than publication of supplied material, say so. Drafting content and uploading approved content are different tasks and may have different scope.

Separate corrections from new work

A changed phone number needs a different assessment from a new service page or booking system. Mark factual corrections, customer-blocking problems and optional improvements separately.

If the change has a deadline, give the date and explain why it matters, such as a published event date. Ask the team to confirm whether it is achievable; sending a deadline does not establish that it has been accepted.

For Netbound, the monthly allowance is for minor edits measured in time. Read the package guide and ask whether your request fits. A new page or a substantial layout change needs assessment, and work beyond the agreed scope needs a quote before you authorise it.

Use a brief the team can answer

Include these details in one request:

The team should be able to respond with its understanding of the request, any missing details and whether a quote is required. Keep the approval and agreed scope in writing.

Review the result against the request

Check the changed section, nearby layout and mobile view. If the request affects an enquiry or booking, try that path as an agreed test. Confirm factual details before approving publication.

When giving feedback, point to what still differs from the agreed outcome. Combine related comments where possible so the designer does not have to reconcile conflicting versions.

Netbound customers can send changes through Messages, or email [email protected] if account access is unavailable. If you expect to edit content yourself, first confirm Frameshift access and scope for your website.