Website repair, improvement or redesign: what to establish first

For an initial discussion, it is useful to describe repair as correcting a fault in existing behaviour. An improvement adds a capability or makes an existing journey more effective. A redesign may revisit visual presentation, navigation and page structure.

These kinds of work can overlap. A new design does not repair a broken integration by itself, and a technical fix does not automatically make confusing information understandable. The appropriate approach becomes clearer after the cause is investigated.

• Which public page is affected? Provide an appropriate open address rather than a private account or a secret link.
• What steps did you take, what did you expect and what happened instead? Describe one specific scenario in order.
• Which device and browser were involved? Note whether the issue happens consistently or only under particular conditions.
• When did you notice it? Include any known preceding change to content, a module or the system.
• If a screenshot is useful, conceal names, contacts, order details and other personal information before sharing it.

Where known, list the CMS, modules, external integrations and areas that editors can change. Do not guess missing information. Identify responsibility for the domain, hosting and content by role; personal account details are unnecessary at this stage.

Establish whether a current backup and a recovery method exist. Do not send the backup itself, passwords or keys through a public form. Any necessary access arrangement should be discussed separately.

List service copy, product information, files and language versions that must be retained. Distinguish outdated content from information that only needs a different presentation. This helps prevent a design decision from causing accidental loss of useful material.

If addresses change, map old pages to relevant new destinations and plan permanent redirects. Update internal links too. Keep this as a separate check before releasing the new version.

• Forms: required fields are understandable, errors are explained and visitors can see the submission outcome.
• Navigation: the selected service can be reached on a phone and using a keyboard.
• Content: long headings, empty results and an additional language do not make the page difficult to use.
• Editing: the agreed information can be updated without a code change every time.
• Destinations: selected scenarios for retained old addresses and new pages are checked.

For each approach, record the problem it addresses, what stays, what changes and how the outcome will be checked. A new feature need not become part of the first stage if it does not resolve the main difficulty.

For example, when enquiry submission fails, investigate that journey first. When the structure prevents visitors from choosing a service, navigation and content may also need attention. These are illustrative scenarios rather than claims about client projects; the decision depends on the actual website.

Use Siteman's separate contact form to share the public address, main problem and expected behaviour. State which parts must be retained. Leave access credentials, backups and customer databases out of the initial description.