Before requesting a website redesign quote, document the business problem, the users and tasks involved, the required scope, and the systems the site must work with. You do not need a complete technical specification. You do need enough detail for bidders to identify assumptions, dependencies, and risks instead of pricing different interpretations of the same vague request.
Begin with the problem, not a list of features
Before requesting a website redesign quote, document the business problem, the users affected, and the evidence you have. A useful brief explains what is failing or changing, what the redesigned site must let people do, and how your team will judge whether the work is complete.
Avoid starting with a solution such as “add a portal” or “make it modern” without explaining the need. A portal could mean a private document library, a customer ordering flow, or an internal approval tool. Those have very different requirements, permissions, and costs.
Describe users and the journeys they need to complete
Name the important user groups: prospective customers, existing account holders, staff, distributors, or another specific audience. For each, describe the task they arrive to complete and what currently makes it difficult. Include unusual but important cases, such as a customer who needs to revise an order or a staff member handling an incomplete submission.
Record the journey in plain language, from entry point to successful outcome. For example: a customer finds a product, checks whether it fits their needs, requests a quote, and receives confirmation. Note where users need to sign in, provide information, contact staff, or leave the site. This reveals missing pages and functional decisions early.
Define scope, content, and what must remain
List the page types and functions that belong in the project, rather than trying to inventory every URL in the first conversation. Identify content that must be retained, rewritten, consolidated, or removed, and who is responsible for supplying and approving it. Flag documents, product records, or frequently changing content that need a manageable editing process.
Also identify what should not change without approval: established URLs, customer account behavior, forms, integrations, or parts of the brand. A redesign can affect search visibility and everyday operations if important pages disappear or URLs change without redirects. Ask for an inventory and migration plan when the site has substantial content or organic search traffic.
Make integrations and data responsibilities explicit
List each system the website exchanges information with, such as a CRM, payment provider, inventory database, email platform, or internal application. For each connection, state what data moves, in which direction, when it moves, and which system is the authoritative record. “Connect the CRM” is not enough to estimate field mapping, permissions, and handling of rejected or duplicate records.
Describe failure behavior that matters to the business. If a request times out, should the site retry, show a clear message, queue the task for staff, or prevent a duplicate charge? Identify who owns credentials and vendor accounts, what access a developer will need, and who monitors issues after launch. These details help separate a straightforward form from a workflow that needs custom engineering.
Bring evidence and constraints, not guesses
Share whatever evidence you already have: common support questions, analytics, search landing pages, form abandonment observations, accessibility concerns, slow or unreliable workflows, and feedback from staff. You do not need perfect measurements to request a quote. Mark observations as confirmed, suspected, or unknown so bidders can distinguish requirements from assumptions.
Document constraints such as launch dependencies, internal approval steps, available staff time, hosting or database arrangements, and systems that cannot be replaced. If an existing ColdFusion/CFML application or custom database is involved, include its role and relevant documentation. A redesign may need to preserve working application behavior rather than replace it.
Separate launch needs from later improvements
Prioritize requirements as essential for launch, desirable, or out of scope for this phase. Explain why each essential item matters. This gives bidders room to propose sensible implementation options without quietly dropping a business-critical workflow, and helps prevent every possible improvement from becoming a launch dependency.
A redesign is unnecessary when the current site already supports the required user journeys and the real issue is limited to an isolated defect, outdated content, or an integration failure that can be corrected independently. The practical next step is to document the failing journey and ask whether a focused repair or broader redesign better addresses it.
Ask for assumptions, verification, and handoff
Request a response that identifies deliverables, assumptions, exclusions, dependencies, and open questions. Ask how the proposed work will be tested: important user journeys, form validation, permissions, integration errors, redirects, accessibility, and behavior across common devices. The right test plan depends on the site; a public brochure site and an account application do not have the same risks.
Clarify who owns the design files, source code, hosting accounts, domain settings, and integration credentials, as well as who handles content entry and launch approval. Require a clear handoff plan for staff who will update the site and a process for reporting issues. For a custom website design and development project, these responsibilities are part of the scope—not administrative details to settle after the build.
Redesign quote preparation checklist
- Name the business problem and the users affected, with concrete examples.
- List required page types, user journeys, and content that must move or change.
- Document integrations, data ownership, permissions, and failure-sensitive workflows.
- Gather current analytics, search, accessibility, performance, and support evidence where available.
- Separate launch requirements from later improvements and identify who approves each.
- Ask bidders to state assumptions, exclusions, dependencies, testing, and handoff responsibilities.
Questions about this approach
Do I need a complete specification before asking for a quote?
No. Prepare a practical brief with user journeys, page types, integrations, constraints, priorities, and evidence of current problems. A developer or designer can help investigate unknowns; mark those items as questions rather than inventing specifications.
Should I send bidders logins to our current systems?
Provide access only through an approved, controlled process, and do not include passwords in a general brief. Describe the systems, data flows, and permissions involved first. During discovery, agree on appropriate access, account ownership, and how credentials will be protected.
What should I document about SEO before the redesign?
Treat an existing site’s URLs and important search landing pages as assets to assess. Ask for a plan to preserve or intentionally change URLs, map redirects, and verify that key pages remain accessible to visitors and search engines after launch.
For help applying this approach, explore our custom web design services.
Discuss your project with Full Blown Studio
Tell us what needs to work better and what you have tried. Discuss your project, email bob@fullblown.com, or call (661) 429-0940.
