Website Redesign Brief: What to Give Your Developer

Website Redesign Brief: What to Give Your Developer

A website redesign brief is a practical document that tells your developer what the current website is failing to do, what the new website must achieve, and how the project should work. Give your developer clear information about your business, audience, pages, content, features, integrations, budget expectations and approval process before design or development begins.

A good developer brief reduces assumptions. It also makes it easier to compare proposals, identify missing work and avoid paying for changes that should have been discussed at the beginning.

1. Start With the Business Reason for the Redesign

Do not begin your website planning with colours, animations or examples of websites you like. Begin with the business problem.

Your developer needs to understand why you want to redesign the website now. The reason could be that the current website is outdated, difficult to update, not mobile-friendly, slow, confusing for visitors or unable to support new services.

Write this information in a few direct paragraphs.

For example:

Our current website was built several years ago. It does not clearly explain our school’s admissions process, is difficult to update and receives most visits from mobile users. We want a simpler website that helps parents understand the school, enquire about admissions and find important documents.

This gives the developer more useful direction than saying, “We need a modern website.”

Useful questions to answer

Include answers to questions such as:

• What is wrong with the existing website?
• What has changed in the business since it was built?
• What should the new website help visitors do?
• Is the main goal enquiries, online sales, donations, registrations, bookings, awareness or information?
• Which parts of the current website should remain?
• Which parts should be removed?
• Is there a deadline connected to an event, campaign, admission season or product launch?
• Who will manage the website after launch?

The goal should be specific enough to guide decisions.

A clinic may want more appointment enquiries rather than a general “better online presence”. An NGO may need a donation page, impact information and volunteer registration. A D2C brand may need better product discovery, payment and order communication. A small agency may want qualified enquiries rather than a high number of form submissions.

Define the main conversion

Every website can have several actions, but one or two are usually more important than the others.

Possible primary actions include:

• Submit an enquiry form
• Call the business
• Start a WhatsApp conversation
• Book an appointment
• Buy a product
• Donate online
• Register for a programme
• Download a brochure
• Request a quotation
• Visit a physical location

Mention the primary action in the brief. Also list secondary actions, such as reading a blog, viewing a portfolio or subscribing to updates.

This helps your developer plan page layouts, buttons, forms and tracking. It also avoids a website where every button competes for attention.

2. Describe Your Audience and Buying Process

Your developer should know who the website is for. “Everyone” is not a useful audience definition.

List your important visitor groups and explain what each group needs to know before taking action. An Indian small-business website may serve local customers, corporate buyers, distributors and job applicants at the same time. These audiences may need different navigation paths and content.

Include audience details

For each important audience, describe:

• Who they are
• Where they are located
• What problem they are trying to solve
• What questions they usually ask
• What may stop them from contacting or buying
• Whether they are likely to use a phone or desktop
• Whether they already know your organisation
• What action you want them to take

For example, a coaching institute may have students researching courses and parents checking credibility, fees and safety. A manufacturer may need to speak to procurement managers who want specifications, certifications and a quotation. A trust may need to communicate with donors, volunteers, beneficiaries and institutional partners.

Explain the decision-making process

The developer does not need a long sales manual, but they should know how a visitor becomes a customer, donor, patient or applicant.

Answer questions such as:

• Does the visitor usually decide immediately?
• Do they need to speak to someone first?
• Do they compare several providers?
• Is trust or proof a major concern?
• Do they need to see pricing?
• Are there multiple service areas or locations?
• Does the enquiry need to go to a particular team member?
• What happens after a form is submitted?

This affects the website structure. A high-consideration service may require detailed service pages, FAQs, credentials, team profiles, process explanations and enquiry options. A simple local service may need clear contact details, location information, operating hours and a short enquiry form.

3. Document the Existing Website Before Replacing It

A redesign should not accidentally remove useful content, search visibility or important website functions.

Share the current website address and explain what should happen to the existing content. If the website has been active for several years, it may have pages that receive visits from Google even if they are not linked prominently in the menu.

Provide access and records

Depending on the project, your developer may need access to:

• Domain registrar
• Hosting account
• Content management system
• Google Analytics or another analytics tool
• Google Search Console
• Google Business Profile
• Meta or other advertising accounts
• Email service
• Payment gateway
• CRM or lead management system
• Existing backup files
• CDN or security service
• DNS management

Do not send passwords in an unprotected document. Use a secure method agreed with the developer. Also make a note of who owns each account. A website should not be dependent on an ex-employee’s email address or a vendor’s private account.

List what should be kept, changed or removed

Create three simple lists:

Keep

• Pages that are still accurate
• Existing blog posts that are useful
• Brand assets
• Product descriptions
• Testimonials that have permission for publication
• Downloadable documents that are still valid

Change

• Pages with outdated information
• Services that have changed
• Old images
• Confusing navigation
• Forms that no longer send enquiries correctly
• Content that needs a clearer explanation

Remove

• Discontinued products
• Old events
• Duplicate pages
• Expired offers
• Staff profiles that are no longer relevant
• Downloads with incorrect information

This is also the right time to identify legal or operational content that must be updated, such as refund terms, privacy notices, shipping rules, cancellation policies, medical disclaimers or donation information.

Plan redirects and search continuity

If URLs will change, include a requirement for redirects. A redirect sends visitors and search engines from an old URL to the appropriate new URL.

Ask the developer to prepare a URL mapping for important pages. For example:

Do not assume every old URL should go to the homepage. A relevant destination is usually more useful for visitors.

4. Write the Redesign Requirements as a Scope

Your redesign requirements should describe the work in plain language. A developer should be able to use this section to estimate effort and identify questions.

List required pages

Prepare an initial sitemap. It does not need to be perfect, but it should show the expected structure.

A basic business website may include:

• Home
• About
• Services
• Individual service pages
• Industries or sectors served
• Case studies or work
• Blog or resources
• Frequently asked questions
• Contact
• Privacy policy
• Terms and conditions

A school may need:

• About the school
• Leadership
• Academics
• Admissions
• Facilities
• Student life
• News and events
• Notices or circulars
• Parent contact information

An NGO may need:

• About the organisation
• Programmes
• Areas of work
• Impact or annual reports
• Get involved
• Donate
• Volunteer
• Contact

List which pages are included in the first phase and which may come later. This prevents a project from growing informally during development.

Separate must-have and nice-to-have features

Use three categories:

Must have

Features required for launch, such as:

• Responsive design
• Enquiry form
• WhatsApp or phone contact
• CMS access
• Basic search engine settings
• Privacy and terms pages
• Payment integration
• Product or service catalogue

Should have

Useful features that can be included if the scope allows, such as:

• Blog filters
• Download library
• Multiple enquiry forms
• Team member profiles
• Location pages
• Newsletter signup
• Testimonials management

Later

Features that do not need to delay launch, such as:

• Customer login
• Member dashboard
• Advanced calculators
• Mobile app connection
• Multi-language support
• Custom reporting
• Marketing automation

This prioritisation is important for Indian businesses working with a controlled budget. It allows the core website to launch without treating every possible feature as essential.

Explain each special feature

Avoid writing only “add a booking system” or “integrate CRM”. Explain how the feature should work.

For a booking function, include:

• What can be booked
• Whether availability is fixed or managed by staff
• Whether payment is required
• What confirmation the visitor receives
• Whether reminders are needed
• Who can change or cancel bookings
• Whether the system must connect to calendars

For an online store, include:

• Product categories
• Product variations
• Inventory requirements
• Delivery locations
• Shipping rules
• Cash on delivery requirements
• Payment gateway preference
• GST invoice needs
• Return and refund process
• Customer notifications
• Coupon or discount rules

These details affect technology choices, testing and the amount of development work.

5. Give Clear Content and Design Direction

A website redesign often slows down because content is not ready. Tell the developer who will provide the text, images, videos and other assets.

Decide who is responsible for content

Your brief should state whether:

• Your team will write all content
• The developer will upload supplied content only
• A copywriter is required
• Existing content should be edited
• Product descriptions need to be created
• Translation is needed
• The developer should source stock images
• Photography or video production is required

Content responsibility should not remain unclear. A website cannot be completed properly when the design is approved using placeholder text but the real content is much longer or shorter.

Prepare a content list with the status of each page:

Include brand guidelines

Share what is available:

• Logo files in usable formats
• Primary and secondary colours
• Fonts
• Brand guidelines
• Photography
• Product images
• Illustrations
• Video files
• Social media links
• Existing presentation or brochure designs

If there is no formal brand guide, tell the developer which visual qualities matter. For example, the website may need to feel calm and trustworthy for a clinic, clear and institutional for a school, practical for a manufacturer or warm and community-focused for an NGO.

Avoid describing the design only with vague terms such as “premium” or “modern”. Add practical examples:

• Use large, readable text
• Keep the navigation simple
• Show the phone number on mobile
• Use real staff and workplace images
• Avoid heavy animation
• Make service differences easy to compare
• Keep forms short
• Use high contrast for important buttons

You can share two or three reference websites, but explain what you like about each one. A reference may be useful for navigation, layout, typography or content presentation without being copied.

Include accessibility expectations

Accessibility is not only relevant to large organisations. A readable website helps older visitors, people using mobile devices, people with limited vision and anyone visiting in bright outdoor conditions.

Mention requirements such as:

• Clear text sizes
• Adequate colour contrast
• Keyboard-friendly navigation
• Labels for forms
• Alternative text for meaningful images
• Captions or transcripts for important videos
• No essential information hidden only inside images
• Visible focus states for interactive elements

Your developer can advise on the appropriate level of accessibility for the project.

6. Specify Technology, Integrations and Compliance

You do not need to choose every technical detail yourself. However, you should explain existing systems and any restrictions.

Mention the preferred platform only when there is a reason

Common choices may include WordPress, Shopify, WooCommerce, Webflow or a custom application. The right option depends on the type of website, update frequency, integrations, internal skills and budget.

If you already use a platform, explain why you want to keep or replace it. For example:

• The internal team already knows WordPress
• The store needs Shopify features
• The current CMS is difficult to manage
• The website must connect to an existing application
• The organisation needs separate access for multiple editors

Do not select a platform solely because another organisation uses it.

List all required integrations

Common integrations for Indian websites include:

• Razorpay, Cashfree or another payment gateway
• UPI payments
• WhatsApp Business
• Google Maps
• Google Analytics and Search Console
• Meta Pixel or other advertising tools
• Zoho, HubSpot or another CRM
• Mailchimp or an email platform
• Shipping providers
• Accounting or invoicing software
• Event registration platforms
• Calendars and video meeting tools
• SMS or transactional email services

For every integration, state whether an account already exists, who owns it and what the expected data flow is.

For example, a form may need to send an email to the admissions office, create a lead in a CRM and send a confirmation message to the parent. This is different from a simple email form.

Cover security and privacy

Ask your developer to include:

• HTTPS
• Regular backups
• Software and plugin update responsibility
• Spam protection for forms
• User access controls
• Secure payment handling
• Error monitoring where appropriate
• A plan for restoring the website
• Protection of admin credentials

If the website collects names, phone numbers, email addresses, health information, donor details or payment-related information, discuss privacy requirements before development.

Your website should have appropriate privacy information and a clear explanation of how personal data is collected and used. Consider India’s Digital Personal Data Protection framework and any sector-specific obligations that apply to your organisation. A clinic, school, NGO and e-commerce business may have different risks and responsibilities.

Do not ask the developer to store sensitive information unless there is a clear business need and a suitable security plan.

7. Set Budget, Timeline and Approval Rules

You do not have to provide a fixed budget if you are still comparing options. But you should explain the budget approach and the level of work expected.

Website costs in India vary widely depending on the number of templates, content work, custom functionality, integrations, product or member data, testing and ongoing support. A simple brochure website and a website with payments, booking, dashboards or complex workflows are not comparable projects.

You can provide:

• A budget range
• A maximum budget
• A request for two scope options
• A first-phase budget and later-phase plan
• A request for separate design, development and maintenance estimates

If GST applies, ask whether the proposal is inclusive or exclusive of GST. Also clarify recurring costs such as hosting, domain renewal, paid plugins, email services, payment gateway charges, SMS, maintenance and third-party subscriptions.

Define the project process

Ask the developer to explain:

• Discovery and requirement review
• Sitemap approval
• Wireframes, if needed
• Visual design
• Content preparation
• Development
• Internal testing
• Client review
• Revisions
• Final approval
• Launch
• Post-launch support

State who will give approvals. If five people provide conflicting feedback, the project can become slow and difficult to control. Nominate one decision-maker and identify other people who must review specific areas.

Define revisions and change requests

Your brief should distinguish between a revision and new work.

A revision might be changing a heading, adjusting a colour or correcting an approved layout. A new feature, additional page type or changed workflow may affect scope and cost.

Ask how change requests will be documented and approved. Written decisions are useful even when communication happens through email or WhatsApp.

8. Include Launch, Ownership and Maintenance Details

A redesign is not complete simply because the new pages look finished on a staging link. Your brief should include the launch process.

Add launch requirements

Ask who will handle:

• Domain and DNS changes
• Hosting setup
• SSL certificate
• Redirects
• Form testing
• Payment testing
• Analytics configuration
• Search Console verification
• Backup before launch
• Mobile and browser testing
• Search engine indexing settings
• Website speed checks
• Post-launch issue reporting

For an e-commerce site, test the full purchase process, including payment failure, order confirmation, refund handling and mobile checkout. For a school or clinic, test enquiry routing and auto-replies. For an NGO, test donation records, receipts and notifications.

Clarify ownership

The final agreement should state who owns:

• Domain
• Hosting account
• Website files
• Source code
• Design files
• Content
• Database
• Images and licences
• Analytics accounts
• Payment gateway account

Make sure important accounts use your organisation’s email address. Ask how you will receive administrator access and whether there are any restrictions on moving the website to another hosting provider later.

Plan ongoing maintenance

Websites need updates after launch. Decide whether you need:

• Security and software updates
• Backups
• Content edits
• New landing pages
• Blog uploads
• Product updates
• Form monitoring
• Performance checks
• Technical support
• Monthly reporting

Some small organisations only need occasional support. Others need a regular maintenance arrangement because they publish notices, manage products or run frequent campaigns.

Do not assume maintenance is included unless it is written in the proposal.

A Reusable Website Redesign Brief Template

You can copy the following structure into a document and complete it before speaking to a developer.

Business overview

• Organisation name:
• Website address:
• Business or programme description:
• Locations served:
• Main services or products:
• Main competitors or alternatives:
• Primary contact person:
• Decision-maker:

Redesign objective

• Why are we redesigning the website?
• What is not working today?
• What should improve?
• What is the primary conversion?
• What are the secondary conversions?
• How will we judge whether the new website is useful?

Audience

• Main audience groups:
• Location and language:
• Common questions:
• Main concerns or objections:
• Typical device:
• Expected action:

Sitemap and content

• Required pages:
• Pages to retain:
• Pages to remove:
• New content required:
• Content owner:
• Image and video availability:
• Translation requirements:
• Blog or resource migration:

Features

• Forms:
• Payments:
• Donations:
• Booking:
• Product catalogue:
• Search:
• Filters:
• User accounts:
• Downloads:
• Notifications:
• WhatsApp:
• CRM:
• Analytics:
• Other integrations:

Design and brand

• Existing brand guidelines:
• Logo and brand assets:
• Preferred visual direction:
• Reference websites:
• Design restrictions:
• Accessibility expectations:
• Mobile priorities:

Technical and legal

• Preferred platform, if any:
• Existing hosting:
• Domain provider:
• Required accounts:
• Backup expectations:
• Security requirements:
• Privacy policy:
• Terms and conditions:
• Refund, shipping or cancellation policy:
• GST or invoicing needs:

Project management

• Target launch period:
• Budget approach:
• Internal reviewers:
• Approval process:
• Expected deliverables:
• Revision process:
• Training required:
• Maintenance after launch:

Frequently Asked Questions

How long should a website redesign brief be?

There is no fixed ideal length. A small business website may need several focused pages, while an e-commerce store, school or NGO with multiple audiences may need a more detailed document. It should be complete enough to explain the decisions that affect scope, cost and technology.

Should I include website examples in the developer brief?

Yes, but explain what you like about each example. Mention whether you are referring to its navigation, page structure, typography, product display, forms or overall tone. This is more useful than asking for an exact copy of another website.

Do I need final content before development starts?

You do not always need every final word before the first discussion, but important content should be prepared before final design approval. Text length, product information, images and page requirements can affect layout. Confirm whether content writing, editing, migration and uploading are included in the scope.

Should SEO be included in a website redesign project?

Basic search engine requirements should be part of most redesigns. Discuss page titles, headings, URLs, redirects, metadata, sitemap configuration, image handling, mobile usability and performance. If you need ongoing content strategy or search optimisation, list that as a separate requirement rather than assuming it is included.

Can I redesign the website in phases?

Yes. A phased plan can be practical when the organisation has a limited budget or incomplete content. Launch the essential pages and conversion features first, then add items such as a resource library, advanced integrations, member accounts or multi-language content after the core website is stable.

What should I ask before accepting a developer’s proposal?

Ask what is included and excluded, who owns the accounts and files, how revisions are handled, what recurring charges apply, how redirects and analytics will be managed, and what support is available after launch. Also ask the developer to identify assumptions and dependencies in writing.

Where to Start

Create one shared document with your redesign objective, audience, sitemap, feature priorities, content responsibilities, existing account details, compliance needs, budget approach and approval process. Then review it with the people who handle sales, operations, content and customer enquiries before sending it to developers.

Ask for proposals that respond to the same brief so you can compare scope rather than comparing only headline prices. Govindani Infotech can review your requirements and discuss the right approach with you on WhatsApp; pricing is confirmed by the team after understanding the project.