What to Ask Before Hiring a Web Designer
Two proposals can promise a “complete website” and include very different amounts of work. One may cover design, copywriting, development and training. Another may assume your team will supply finished content and manage the site immediately after launch.
Choosing a web designer becomes easier when you understand those differences. The most useful questions to ask a web designer reveal what they will deliver, what they need from you and how the website will be supported over time.
What should the website help visitors do?
Before discussing colours or layouts, explain your organisation’s goals. A service business might need qualified enquiries. An association might need visitors to find resources, join or register for events.
Ask how the designer would translate those goals into a website structure. Which information should visitors see first? What steps should they take to complete an enquiry or registration?
A useful initial discussion should cover your audience, existing website, budget, internal resources and essential features. Agree on priorities so that optional additions can be priced separately.
What exactly does the proposal include?
“Website design” can cover anything from visual mock-ups to a fully built and populated site. Ask for deliverables that you can identify and review.
Pages, features and technical work
Clarify the difference between the number of pages and the number of unique layouts. Ten service pages might share one reusable template, while a homepage, directory and booking page each require different design and development work.
The proposal should specify:
- Pages and content: which pages will be created and how much content will be uploaded.
- Functionality: forms, search, bookings, payments, member areas and external integrations.
- Mobile layouts: how the site will adapt to different screen sizes.
- Testing: which browsers, devices and visitor journeys will be checked.
- Launch work: hosting setup, domain connection and any migration from an existing site.
If you are replacing a website, ask who will preserve important URLs or create redirects. Also clarify what “SEO included” means: page titles and search engine settings are different deliverables from keyword research and ongoing content work.
Revisions, milestones and approval
Ask how many design concepts and revision rounds are included, when feedback is required and how additional changes are priced.
A revision round also needs a definition. Does it mean one consolidated set of comments from your organisation? Can you request structural changes after approving a layout?
Request a schedule with clear review points and payment milestones. It should show dependencies, including when you must supply content, access details and approvals.
Can you explain your role in these portfolio projects?
A portfolio is more useful when the designer explains the brief, their contribution and the decisions behind the finished work.
Choose two or three relevant examples and ask:
- What problem was the client trying to solve?
- Which parts did you personally design or develop?
- How did the budget or technical requirements influence the result?
- What evidence shows whether the project met its goals?
Open the live websites and try a realistic task on your phone. Find a service, locate contact details or complete part of a form. Consider whether the experience makes sense for its audience.
Relevant experience can involve similar content, workflows or organisational needs; it does not have to come from your exact industry.
Who will write, supply and upload the content?
Content responsibilities deserve their own discussion. “Client to supply content” could mean sending rough notes, delivering edited documents or entering everything into the website yourself.
Establish who will handle copywriting, editing, photography, image selection, translations and content entry. If existing material will be reused, ask who reviews it and decides what needs updating.
For example, ask: “Does your price include writing and uploading our service pages, or will our team provide finished text?”
Agree on delivery dates, formats and the person responsible for approval. Also clarify who checks image licences, factual accuracy and any specialist wording your organisation requires. A sample page prepared early can help everyone understand the expected length and quality.
How will accessibility be designed and tested?
Ask which accessibility standard, version and conformance level the designer proposes to work towards. Have that target recorded in the scope, along with the pages and features covered by testing.
The European Commission’s guidance on web accessibility highlights early and regular testing. Ask when accessibility reviews will happen during your project.
Request practical details: will checks cover keyboard navigation, visible focus, text contrast, form labels, error messages and screen reader use on important journeys? How will third-party booking or payment tools be assessed?
Clarify what evidence you will receive, who fixes identified problems and whether further testing is included after those fixes. Training should also explain how your team can maintain accessibility when adding images, headings, documents and other content.
Who owns the work and controls the accounts?
Ask for written terms explaining ownership of the completed design, custom code, content and editable source files. Identify any third-party themes, fonts, images or software that remain subject to separate licences.
Account control matters too. Confirm that your organisation will have appropriate access to its domain registration, hosting, content management system and analytics, with recovery details connected to an organisation-controlled email address.
Ask what happens if you later move to another provider. What can be exported? Which files and documentation will you receive? Are there transfer fees or platform restrictions?
These questions help you understand the practical costs and responsibilities of running the website beyond the initial project.
What can our team update, and what support is available?
Request a demonstration of common editing tasks. Your team may need to publish news, change staff details, add services or update navigation. Confirm which tasks the proposed system will support and what training is included.
Then separate the initial defect-fixing period from ongoing maintenance. Ask how each service is defined and priced.
A support agreement should explain who handles:
- Software updates and checks after updates.
- Backups, retention and restoration.
- Website monitoring and technical problems.
- Content changes and new development.
- Support requests, response times and urgent issues.
A promised response time tells you when someone will acknowledge a request; ask separately how resolution is handled. Confirm any support-hour limits, renewal costs and cancellation terms.
How can you compare proposals fairly?
Give each shortlisted designer the same brief, then compare their written answers. A simple table can expose differences that a headline price leaves unclear.
| Area | What to compare |
|---|---|
| Scope | Pages, layouts, features and exclusions |
| Content | Writing, images, migration and upload responsibilities |
| Quality checks | Mobile, browser, accessibility and functional testing |
| Handover | Training, documentation, account access and files |
| Costs | Project fee, recurring charges and additional-work rates |
| Support | Defect period, maintenance coverage and response terms |
Ask each designer to price missing essentials and explain assumptions. Where a proposal offers optional work, decide whether you need it for launch or can schedule it later.
Before committing, have the agreed answers added to the proposal or contract. You should be able to identify what will be delivered, who is responsible for each part, how completion will be checked and what happens after launch.