Connect the redesign decision to a specific problem
Start a website redesign by identifying the business requirement your current site does not meet. Are customers misunderstanding a service, abandoning a mobile form, finding outdated product information or struggling to reach the right team? Each problem suggests a different intervention. Prepare an evidence based issue list before discussing colours and layouts. A new appearance will not automatically correct gaps in your offer or enquiry process. Without an initial definition of success, the project can become a discussion about preferences.
Imagine a hypothetical industrial maintenance company receiving enquiries mostly from outside its service area. This is an illustration, not a DUCOSOFT case study. Clearer service and location information may matter more than a new visual style. Another company may attract suitable visitors but have a broken form. If you lack reliable data, record that limitation and establish basic measurement. Explain which problem each design, technical or content change intends to solve.
Record a baseline you can compare later
Before changing the site, record important pages, traffic sources and business outcomes where information is available. Organic landing pages, advertising destinations and directly shared catalogue links may serve different purposes. Ask sales and support staff which pages they use. Missing analytics access does not mean existing content has no value. Investigate links in earlier proposals, QR codes and email signatures. Some of the site’s operating history sits with employees and customers rather than in a reporting dashboard.
Include the date, method, device type and sample pages in your baseline. Note seasonality, advertising expenditure, campaigns and product changes that could affect comparison. Do not attribute every difference between two months to design. A baseline helps explain change; it does not justify an automatic improvement claim. Distinguish verified figures from staff observations. This makes later reporting more useful and prevents an attractive redesign from receiving credit for unrelated commercial changes.
Give each existing content item a clear decision
For each important URL, record its title, purpose, accuracy, owner and migration decision. Useful content may remain; incomplete content may improve; overlapping pages may be combined around a meaningful destination. Do not delete a page solely because it no longer fits the new menu. A technical explanation customers still need deserves an explicit place in the new structure. Include downloadable catalogues, documents and images, and confirm that their usage permissions remain appropriate.
A common mistake is postponing migration until visual design is complete. Real content then reveals requirements too late. Test a genuine service page and a long article in the proposed template early. If Turkish, English and German versions exist, track equivalents in one inventory and make translation gaps visible. Appoint the person authorised to approve content at the start. Otherwise the launch schedule remains dependent on a sequence of newly discovered reviews.
Map old addresses to suitable new destinations
Google’s site move guidance addresses planned transitions between old and new URLs. For your business, the requirement is that a customer following a saved or search result link still reaches relevant information. List important addresses and select their destination individually. Keep useful addresses when there is no reason to change them. If language paths, categories or naming conventions change, document the reason and include downloadable files in the exercise. Confirm content suitability before redirect rules are implemented.
Google’s redirect documentation describes permanent server side redirects such as 301 and 308 for permanent moves. Your technical team should implement the appropriate method; you should approve whether the destination answers the original need. Sending an old repair service page to an unrelated homepage does not solve the customer’s task. Where no equivalent exists, agree an appropriate response with the team. Test chains and loops, and update internal links to point directly to current addresses.
Understand which visitor experience the speed test measures
One speed score cannot describe every visitor’s experience. PageSpeed Insights distinguishes laboratory measurements from real user data. A lab test remains useful when field data is unavailable, but it is a different type of evidence. Ask which page, device and connection conditions were measured. A fast homepage can coexist with a slow service template or advertising destination. Include representative templates in acceptance instead of treating the front page as the entire website.
web.dev describes Core Web Vitals through LCP for main content loading, INP for interaction responsiveness and CLS for visual stability. Translate these into visitor tasks: when can someone read the service, what happens after a menu tap, and does a button move while a form is being completed? User centred measurement helps keep the assessment tied to experience. Images, fonts, scripts and server response may require different changes. Ask the technical team to connect each finding with a proposed remedy.
Define conversion as a concrete completed task
A meaningful business outcome might be a suitable enquiry, appointment or completed application. Clicking a button is an intermediate action. Opening WhatsApp does not establish that a message was sent or a sale occurred. If the website prepares a message, explain that the visitor completes sending in the external application. This distinction prevents interest signals and confirmed outcomes from being combined in the redesign report. Define goals using terms the commercial team can understand and verify.
Request only information needed for the next decision and make validation errors clear. Explain what happens after submission and which team handles the enquiry. Rather than competing calls to action everywhere, establish a useful next step for the main purpose of the page. Evaluate the design against a real question: is this service suitable for me, and how can I contact the right person? A clear answer supports the entire journey, including employees who receive the request.
Test templates with real content and realistic tasks
Do not approve a design using short placeholder headings alone. Long service names, different image proportions, multilingual text and missing product photographs reveal how a template behaves. On mobile, check that menus, forms, language controls and fixed contact buttons do not obstruct one another. Try basic keyboard navigation and form labels. Record issues with the page, conditions and a screenshot; saying that something looks wrong does not give the team enough information to resolve it reliably.
For the illustrative maintenance business, choose three tasks: find the maintenance scope, verify the service area and prepare an enquiry. Let testers attempt them without being told where to click. Hesitation and misunderstandings reveal content and layout issues together. A small exercise of this kind does not establish statistical sales improvement. Its purpose is to identify obvious usability barriers. Change the affected content or arrangement and recheck the task, rather than redesigning the whole site after every observation.
Assign launch responsibilities and rollback conditions
The launch plan should state who approves the release and what would postpone it. Treat content, redirects, forms, notifications, measurement and administrator access as separate checks. Prepare appropriate backups of the old site and required configuration. Define what rollback actually restores, how new submissions will be preserved and who authorises the decision. Possessing a backup file does not demonstrate that every part of a live service can return without additional work. Protecting enquiries received during the transition is particularly important.
Have the technical team check that staging access controls or indexing restrictions do not remain unintentionally on the live site. The unfinished test version also needs appropriate access management. If domain or email settings change, assess their effects on related services. A loading homepage does not complete the migration. Follow a sample enquiry to its final recipient and confirm that staff can read it and take the intended action. Classify remaining issues by importance before accepting the release.
Monitor technical health and enquiry quality together
After launch, watch missing pages, unsuitable redirects, failed forms and unexpected layout movement. Review relevant Search Console information and site records with the technical team when assessing search visibility. Recrawling and data collection take time; do not label every short movement a lasting result. If addresses, content, design and advertising all change together, attributing an outcome to one factor is difficult. Maintain a dated record of changes so the limits of interpretation remain visible.
Assess enquiry suitability as well as volume. More forms do not necessarily mean better business. Requests outside the service area may suggest unclear content or audience targeting. Unanswered enquiries may reveal an operating problem rather than a design fault. Faster pages can still perform poorly if important information disappears. Discuss technical and commercial findings together. For each improvement, record the expected behaviour, accountable person and verification method. Avoid unverified conversion increases or ranking guarantees.
Compare proposals through measurable delivery scope
A proposal should address existing content, migration, redirects, performance work, form testing and maintenance responsibilities alongside design and page count. Specify included pages and languages. Advertising, continuing SEO management and regular content production can be separate activities; do not assume a redesign includes them. Discuss account ownership, editing training and the process for future changes. Compare prices against the same scope, including dependencies on client information and third party services.
For a redesign discussion with DUCOSOFT, prepare your current URL, examples of problems, important page list and available measurement records. Planning a completely new website is a different requirement; this guide concerns renewing an existing asset with its operating history. Bringing content migration, technical acceptance and business purpose into one plan makes design decisions more concrete. Your approval should confirm that visitors can find relevant information and complete the intended contact step, as well as approving the appearance.
| Deliverable | Acceptance evidence you can review |
|---|---|
| Content migration | Approved pages and documents are present; remaining gaps have a named content owner. |
| Address changes | Important old links reach suitable content without unexpected chains or loops. |
| Performance | Selected templates are assessed under comparable conditions; laboratory and field findings are distinguished. |
| Forms and contact | A test enquiry reaches the correct recipient; invalid entries receive clear instructions. |
| Languages | Titles, content, forms and menus open in the correct language; equivalent pages connect. |
| Measurement | Intermediate clicks and confirmed enquiries are defined separately, with comparison conditions recorded. |
| Management handover | An authorised company account has access; editing and the support route have been demonstrated. |
| Outstanding work | Nonblocking issues have owners and acceptance conditions; decisions on critical problems are recorded. |
