A new homepage will not automatically fix an unclear service offer or a lost enquiry. If a redesign brief contains only websites you like, the team is left guessing at an appearance rather than a problem to solve. First collect the site's jobs, observed failures and strengths worth preserving on one page.
1. Turn the reason for a redesign into an observable problem
“The site looks old” can start the conversation, but it is not enough to assess a finished project. Write down which page should help which visitor complete which task. A hotel manager checking production scope has a different task from a customer comparing product dimensions.
Bring together support questions, team observations and measurement data where available. Support “the price scope is unclear” with actual questions, and “the form is unusable” with a repeatable test. If there is no data, say so. Do not present an assumption as a measured result. Give each finding an owner, an affected page and a way to verify that it has been resolved.
2. Review content alongside the visitor's journey
Does the homepage clearly explain who you are, whom you serve and what you offer? Does each service page show deliverables, process and the examples needed to make a decision? Identify unanswered questions before visitors reach the contact invitation. Missing content may need to be written before a new interface is designed; filling empty boxes afterwards can force another change to the page structure.
Read menu labels in terms of what a visitor is looking for, rather than internal departments. Explain the work and its scope in project pages instead of showing imagery alone, and do not add unverified results. On multilingual sites, check that buttons, service descriptions and error messages convey equivalent meanings. Inventory existing page addresses and working links as part of the redesign.
3. Check speed and usability through real tasks
Google's Web Vitals guide evaluates loading, responsiveness and visual stability separately. Lab tests help during development, but cannot replace real-user measurements. Avoid treating one score as a complete description of the experience.
On a phone, open the menu, find a service, inspect a project and complete the form. Observe whether large images or videos delay that journey on a slower connection. Record buttons that move as content loads and overlays that cover the screen. Note the device and the exact step where the problem appears; “mobile is slow” alone does not provide enough direction for a fix.
Repeat the journey with a keyboard and enlarged text. Menus should open and close, focus should remain visible and errors should be readable. For pages with substantial animation, also consider the visitor's reduced-motion preference; MDN explains how browsers expose that preference. Plan a calmer alternative that preserves the visual identity.
4. Test the form through to the record and follow-up
Consider a test scenario: a visitor presses Send and sees “Received”, but the server has not saved the enquiry. A message on the screen is not proof of delivery. Show success after the server confirms that it has accepted the record. A link that opens an email application does not confirm that an email was sent either; explain clearly what that step actually does.
Test invalid information, a dropped connection, a server error and repeated clicks. When something fails, keep the visitor's input, make the retry clear and avoid creating unnecessary duplicate enquiries. After a record is created, define who will see it, where it can be checked if a notification fails and who owns the response. A form is complete when it creates a traceable work item, not merely a successful animation.
5. Use the findings to choose repairs or a rebuild
Choose technology after defining requirements. If the existing system supports content editing and reliable enquiries, repairing selected areas may be enough. Replacing the platform becomes more relevant when verified limits in administration, integrations or maintenance repeatedly obstruct the work. Divide the decision into phases such as these, with a written deliverable and acceptance condition for each.
| Phase | When it applies | First deliverable | Acceptance condition |
|---|---|---|---|
| 1 · Repair functionality | Enquiries or essential navigation are broken | Working forms and critical links | Success and failure scenarios are verified |
| 2 · Rework content | Services and scope are unclear | Page plan, copy and project examples | Target users can answer their main questions |
| 3 · Redesign the interface | Content is sound but use is difficult | Mobile and desktop designs for priority pages | Main tasks can be completed in both layouts |
| 4 · Replace the platform | Maintenance and integration limits are confirmed | Migration, data transfer and rollback plan | Records, addresses and responsibilities are checked |
6. Make the launch decision with a checklist
- Are the target audience, primary task and acceptance criteria for each issue written down?
- Have content, project examples and every language version been approved?
- Have mobile, keyboard, enlarged-text and slow-connection scenarios been tried?
- Have form success, error and repeat-submission behaviour been verified?
- Have old links, new addresses and any necessary redirects been checked?
- Are content updates, backups and enquiry follow-up assigned to specific people?
- Is there a version to roll back to and an agreed post-launch review date?
Do not judge a redesign only by screenshots. Compare before and after measurements using the same tasks and comparable conditions, and keep unresolved problems visible. When scoping work with El Chedo, share the current address, observed difficulties and the jobs you expect the site to do in your project brief.