What to prepare before hiring a website designer
Bring a short brief that explains who the site serves, what visitors need to do, what content is ready, and who will own the site after launch.
You know your business needs a better website, but a designer asks what the new site should do. “Look modern” is honest, yet it leaves the most important decisions open: which customers the site serves, what they need to find, and what should happen after they contact you.
Before requesting proposals, write a short brief about the work the website must do. You do not need finished copy or a technical specification. You need enough detail for a prospective partner to understand the audience, the main visitor tasks, the content you can supply, the limits of the project, and the decisions that still need discovery. A useful brief makes proposals easier to compare and gives you a way to judge the finished site.
Some businesses turn to outside help, though the survey evidence is narrower than a count of website redesigns. In Statistics Canada’s analysis of businesses outsourcing work, Table 1, 10.9% of Canadian businesses with one to four employees reported outsourcing website or software development or computer programming in the preceding year. The survey grouped those activities together. It does not tell us how many commissioned a business website, what they spent, or whether the work succeeded. Your decision should follow your own needs and capacity, not that percentage.
Start with the customer question, not a page count
Describe the people the site should help and what they are trying to decide. A bookkeeping practice, for example, might serve owner-operated businesses that need to know whether the practice handles monthly books, year-end preparation, or both. A prospective client should be able to see the fit, understand the next step, and make an inquiry without sending financial records through an ordinary contact form.
Try writing a brief in the customer’s voice: “I run a small business in Gatineau. Do you work with companies like mine, can I read about the service in French, and how do I ask for a consultation?” That is more useful than “We need a home page, about page, and contact page.” The pages should be chosen to answer the questions.
List the tasks that matter most, such as comparing services, checking a service area, finding an address, or contacting the team. Mark anything that must work in both English and French. Include the whole path, including form messages and the reply your team sends afterward. If a task depends on an existing booking or customer system, name that system and describe what the site needs to connect to it. A designer can then separate ordinary content from a feature that needs integration or custom software.
Gather the material only your business can confirm
You can ask for help shaping copy, but the business should verify its own services, eligibility, service area, hours, credentials, and contact process. Collect the current site address, approved brand files, photographs you have permission to use, and examples of real customer questions. Note who can approve text in each language. For a regulated practice, identify who must review any professional claims before launch.
Make an inventory of what is ready, what needs revision, and what does not exist yet. Be candid about gaps. A proposal that assumes final bilingual copy and licensed photography will differ from one that includes writing, translation, review, and image sourcing. If your team has limited time to review material, say so: a realistic schedule needs room for approvals and corrections.
Avoid sending passwords or client records with an initial brief. It is enough to list the tools and accounts involved. Access can be arranged through the appropriate account controls after scope and responsibility are clear.
Say what a successful visitor journey looks like
Write a few observable checks that you can perform before accepting the site. For example: “A visitor can find the bookkeeping service from the main navigation, understand who it is for, and send an inquiry from a phone.” Add the French journey if it is in scope. Describe what confirmation the visitor receives and where the inquiry reaches your team.
Search expectations belong here, but keep them grounded. Google’s SEO Starter Guide recommends useful, well-organized content, descriptive titles, and links that help people and search engines understand pages. Ask how the proposed site will make your real services clear and how you will review page titles and descriptions. Search visibility is influenced by more than a website build; a proposal should explain its work without promising a ranking or a lead count.
Include an accessibility review in the acceptance checks. The W3C Web Accessibility Initiative’s planning guidance recommends setting goals and assigning responsibility for accessibility, including checking work delivered by suppliers. Ask which journeys will be tested with a keyboard and on a phone, how form errors will be explained, and who will fix issues found before launch. An automated scan alone cannot show whether a customer can finish a task.
Define ownership and the work after launch
A website is an ongoing business asset. Record who will register or control the domain, who will pay for hosting and other services, who can update content, and who will receive renewal notices. For a .ca domain, CIRA explains that registration and renewal go through a registrar. Ask the supplier to document the registrar and handover process so your business can keep control of the name it uses publicly. Check the corresponding process with your registrar if you use another domain ending.
Then ask how changes will be made after launch. Will your team edit service descriptions and hours? Will the designer make changes under an ongoing agreement? Who updates software, checks forms, maintains backups, and responds when a dependency breaks? These choices affect the total effort and cost even when the initial design looks simple. Put recurring charges and responsibilities in the proposal rather than discovering them after handover.
If you already have a site, list the pages, files, or URLs that must be preserved or redirected. Ask what happens to the existing site during the switch and who checks the important links afterward. A polished replacement is less useful if customers’ saved links stop working.
Compare proposals against the same brief
Send the same core brief to each prospective supplier. Ask each to identify assumptions, included deliverables, your responsibilities, review points, launch checks, and what happens when a requested change falls outside scope. Look for a clear explanation of how they will learn about your customers and content, not simply a gallery of visual styles.
A low initial quote may leave copywriting, bilingual review, photography, accessibility checks, or ongoing support with you. A broader proposal may include work you can comfortably do yourself. Neither is automatically the right choice. Compare the work and handover you will actually receive, then choose a scope you can approve and maintain.
You can start without every answer. A good brief can mark decisions as “to discuss.” The important distinction is between an open question and a hidden assumption. If the site needs a complex client portal, payment flow, or connection to internal software, ask for a discovery phase before requesting a fixed build estimate. That gives both sides a chance to define the workflow and the risks.
A brief you can copy
Use these prompts as a starting document:
- Business and audience: What do we offer, where do we operate, and whom do we serve?
- Visitor tasks: What should someone be able to understand or complete on the site?
- Languages and content: Which journeys need each language, what material exists, and who approves it?
- Features and connections: Which forms, booking tools, or internal systems matter?
- Acceptance checks: Which real tasks should we test on a phone and with a keyboard?
- Ownership: Who controls the domain, hosting, accounts, content, and renewal notices?
- After launch: Who handles updates, support, backups, and new requests?
- Open decisions: What do we need the designer to help us work through?
The brief is useful even if you decide to improve the current site instead of replacing it. It turns a vague design request into a list of decisions your business can make and test. If you would like help turning those decisions into a scoped website project, discuss your website with Red Comet.
