How to choose a web design agency: a practical shortlist guide

1. Write a useful brief before collecting names

Begin with the work the website must do. List the people it serves, their main questions and the actions you want them to complete. “Generate enquiries” is too broad on its own. A commercial contractor might need facilities managers to understand maintenance coverage, review relevant projects and request a site visit. A retailer has different needs around product choice, stock and payment. Those differences should shape the shortlist.

Include what already exists. State whether the project involves a new site, a rebuild or a change to an established store. Mention content you intend to retain, external systems it connects to and who currently controls the domain. Suppliers do not need passwords at this stage. They need enough context to identify dependencies and avoid pricing a simple brochure site when the real job includes a complicated migration.

Explain practical constraints honestly. If your team can supply product information but not finished copy, say so. If launch depends on a trade event, explain the date and whether a smaller first release is acceptable. A useful budget discussion describes a realistic investment range and asks what can be delivered within it. Hiding every constraint can produce proposals that are difficult to compare and impossible to schedule.

Keep requests proportionate to the selection stage. A short written response and a conversation may be enough to identify the strongest fit. Asking several teams to design a complete homepage without a contract can reward polished presentation over careful diagnosis. You want to understand the proposed thinking and delivery method, not collect speculative design work.

• Define three customer tasks and one internal editing task.
• Name a decision maker and the people who supply content.
• Separate essential launch requirements from later improvements.
• List known connections, existing content and genuine deadline constraints.

2. Treat reviews and rankings as starting points

A search for top rated web design companies can help you discover names, but it does not establish which team suits your project. Review platforms, award lists and editorial lists use different selection methods. Some mix paid visibility with other signals. Look for the underlying evidence rather than treating a position on a page as an independent assessment of delivery quality.

Read reviews for specific experiences. Did the agency explain decisions, meet agreed responsibilities and remain helpful after launch? Were difficulties acknowledged and resolved? A brief compliment tells you less than an account of a project with similar complexity to yours. Check the date and context, because an agency’s staffing and service focus may have changed since a particular review was written.

Look for patterns without overinterpreting small samples. One unhappy review may involve a disputed scope, while a series describing the same communication problem deserves a direct question. Equally, a long list of excellent reviews does not prove experience in wholesale pricing, booking integrations or a large content migration. The evidence needs to match the risk you are asking the agency to manage.

If references are available with the client’s permission, ask focused questions. What did the client have to supply? How were changes handled? Could their own team manage the finished website? Were recurring responsibilities clear? Avoid asking another business to disclose confidential commercial details. Their account is one perspective, so compare it with the proposed process and the actual website.

Keep a short evidence note for each candidate: the source, what it supports and what remains unverified. This is particularly useful when several directors have discovered different agencies through personal recommendations. It turns “I have heard good things” into a starting point for a fair discussion.

3. Inspect working projects and ask what the agency actually did

Open live projects on your own phone. Find a service, locate a contact route or browse products without coaching. Look at interior pages, not just the homepage. A portfolio image can show visual direction, but it cannot demonstrate how menus behave, whether forms make sense or how a large amount of content is organised. Choose examples that resemble your operational needs rather than your preferred colour scheme.

Ask the agency to describe its role in each relevant example. Did it handle research, content, design, development and support, or one part of the work? Was the site built by the same team you would work with? Were the photographs and brand supplied by someone else? Clear attribution makes a portfolio more useful and avoids assigning credit for work outside the agency’s scope.

Ask about a constraint or compromise. A credible project discussion can explain why a particular feature was omitted, how a content problem was solved or what had to be phased. You learn more from that explanation than from a list of technologies. The aim is to understand how the team reasons when time, information or budget is limited.

Published outcomes should come with context. If a case study reports more enquiries, ask what was measured, over what period and what else changed. Advertising, seasonality and changes in the business can affect results. A responsible agency should distinguish an observed improvement from a claim that its design caused every part of it.

Hypothetical shortlist example: a small manufacturer compares one agency with striking restaurant websites and another with clear technical product catalogues. The manufacturer still needs to inspect communication, content and support arrangements. However, the catalogue examples provide a more relevant starting point for questions about filters, documents and product variants. Sector familiarity helps only when it translates into the tasks your website must support.

Our web design work for Belfast businesses explains the questions we use to connect a website with the business behind it.

4. Understand the team and communication arrangements

Find out who will manage the work, who will make design decisions and who will build and test it. A small agency may combine roles; a larger one may use specialists. Neither structure is automatically better. What matters is that the responsibilities are clear, the required skills are available and someone remains accountable when work crosses between roles.

Ask how external collaborators are used. Freelancers and specialist partners can be valuable, but the arrangement should be explained where it affects continuity, access or support. You do not need personal employment details. You need to know who owns delivery, who reviews the work and how the agency handles absence or a change in personnel during the project.

Agree how you will keep in touch. Weekly or fortnightly updates may suit one project, while another needs short meetings at agreed review stages. Decide where decisions are recorded and who gathers feedback from your team. A design review becomes expensive if three people send contradictory instructions through different channels and nobody has authority to settle them. Give the agency one agreed response, with any unresolved question clearly marked, so it knows which changes to make.

Ask what happens when your team misses a dependency. A useful delivery plan explains how late content or approvals affect scheduling and which work can continue. This is a better sign than a timetable that assumes every input arrives perfectly. Equally, ask how the agency reports delays on its own side and what information you will receive when a date is at risk.

• Who is the named contact and who covers their absence?
• Who approves design, content and technical decisions on each side?
• Where are decisions, revisions and unresolved questions recorded?
• What needs a meeting, and what can be approved in writing?
• How will either side raise a risk before it becomes a missed milestone?

5. Establish who will prepare and approve the content

Content is a delivery responsibility, not a detail to add after design. Ask whether the quotation covers structure, copywriting, editing, data entry and photography. Those are different tasks. An agency may provide excellent page layouts while expecting you to supply every final word. That can work well if the expectation is explicit and your team has the time and knowledge to meet it.

For each page type, identify a source and an approver. Service information may come from an operational manager; product specifications may come from an existing catalogue; project evidence may need client permission. Do not let a draft become public merely because it filled a space in the design. Agree how placeholders, unverified claims and missing permissions will be flagged and resolved.

Ask how the agency handles content that does not fit the first layout. A real project description might need a diagram, a longer explanation or downloadable documents. Good planning tests representative content early. A design that works only with a short invented headline can create avoidable rework when the actual business information arrives.

For a Belfast or Northern Ireland business, local relevance should come from accurate service coverage, useful examples and genuine experience. Repeating place names across pages with almost identical content is not a substitute for explaining what customers need to know. Ask who decides which pages deserve separate treatment and what evidence supports each one.

Before launch, plan a final content check with someone who knows the business. Review telephone numbers, addresses, opening times, service limitations and the recipient of every form. The agency can check presentation and links, but it cannot independently verify every operational fact. Put those factual approvals in the same delivery plan as design approvals.

6. Ask for demonstrations of editing and testing

Ask to see an editor perform the changes your staff expect to make: update an opening time, add a project, replace a document and change an image. A demonstration on a comparable site can be enough during selection. Before handover, repeat it on your actual website using an appropriate staff account. The purpose is to check that everyday work is achievable without relying on hidden developer knowledge.

Agree which accessibility requirements will be checked, which pages and components will be reviewed and how any problems will be recorded. The World Wide Web Consortium’s Easy Checks includes introductory checks such as using a keyboard, enlarging text and reading form labels. The organisation explains that these checks do not amount to a complete accessibility assessment. Ask what further review the agency proposes for your site. A single automated score should not be presented as proof that every visitor can use every part of it.

Ask how testing reflects your important journeys. A contact site needs form receipt and error handling checks. A shop needs payment, stock and fulfilment scenarios. A booking site needs clear availability and confirmation behaviour. The appropriate depth follows the consequences of a failure. “We test on mobile” leaves too many important questions unanswered.

For search work, distinguish setup from an ongoing programme. Ask whether the scope includes a page inventory, address mapping, titles, crawl checks and reporting access. If existing web addresses change, Google’s guidance on moving a website provides a useful reference for planning and monitoring. No agency can responsibly guarantee a particular search position after launch.

Finally, ask how defects are handled before release. You should understand which issues prevent launch, who can accept a known limitation and how deferred work is recorded. A named acceptance process makes a technical discussion easier for the business to participate in.

7. Compare proposals line by line, not just at the total

Build a small comparison sheet using the same headings for every proposal. Mark an item as included, excluded, optional or unclear. Do not assume an absent item is included because it sounds essential. Ask each agency to explain unclear points in writing so the final comparison reflects the actual offer rather than your best interpretation of a presentation.

Separate the initial project from recurring costs and optional improvements. Hosting, software licences, maintenance, content support and further development may be supplied by different parties. Ask who invoices for each part and what happens if you stop using it. You do not need to predict every future change, but you should understand which commitments keep the site operating.

Look at revision and change arrangements. A fixed price still needs a clear scope. Ask how many review stages are planned, what counts as a correction and how new requirements are estimated. If a proposal depends on assumptions about page numbers, product data or integrations, test those assumptions before treating the total as comparable with another quote.

Hypothetical comparison: one proposal includes importing an existing project library, while another includes designing a project template but expects your team to enter the content. Those offers may both be reasonable. The difference matters because it changes internal workload and the realistic launch date. Record it explicitly instead of labelling one supplier expensive and the other good value.

Ask shortlisted agencies to state what they need from you during the first month. Compare the requested interviews, content decisions, account access and approval time with your actual availability. A highly collaborative process may be a good fit, but it still needs time from the business. If one proposal assumes two days of internal work and another assumes several weeks, resolve the difference. It may reflect different scope, different assumptions or a misunderstanding about who prepares the content. The answer affects both cost and the credibility of the delivery timetable.

Before appointing a team, ask it to explain one difficult requirement back to you. Choose something specific, such as routing an enquiry to the right department or preserving a technical document library. Listen for the business outcome and the unresolved questions rather than a recital of software names. This is a useful check that the written brief has been understood. It is also an opportunity to discover where your own wording is ambiguous before the ambiguity becomes a signed assumption in the proposal.

Use a structured clarification note after selection conversations. List the question, the agency’s answer, any resulting scope change and whether the point is closed. Share the relevant clarification with every remaining candidate when it changes the common brief. This keeps the comparison fair and prevents the final choice depending on information one supplier never received. Keep commercial details confidential between suppliers. Fair comparison means equal access to your requirements, not circulating one agency’s proprietary approach or pricing to another.

Finally, ask how the proposal will be incorporated into the agreement. If a promise appears only in a presentation, make sure the final scope reflects it. Check that revised inclusions have not disappeared when a new version is issued and that superseded versions are clearly identified. A short version history can help a busy decision maker follow what changed. Both sides need a clear written account of the work being approved, without having to piece it together from earlier conversations. Ask the final decision maker to check that version before approval.

8. Clarify ownership, accounts and an eventual handover

Ask who will register and control the domain, hosting, analytics and other important accounts. Where practical, the business should retain appropriate control of its own accounts and grant the agency the access it needs. Agree how access will be documented and removed when people leave. Never send shared credentials around a selection group simply to make a proposal easier to prepare.

Ownership is more detailed than the sentence “you own the website”. Ask what rights you receive to the design, custom code, supplied content and commissioned assets. Some parts may be licensed from third parties rather than transferred. Ask what remains usable if an agency relationship ends and which subscriptions must continue. These are matters to clarify in the agreement, with professional advice where necessary.

Discuss exports and backups in practical terms. Can the business obtain its content and customer data in a useful format? Who keeps recoverable copies, and who is responsible for restoring the site? A folder of files is not always enough to recreate a working service. Ask the agency to describe a realistic handover rather than promising that everything is portable without conditions.

Prepare a simple handover inventory: account name, business owner, agency role, renewal owner and recovery contact. Store actual access details in a suitable secure system, separate from an ordinary project document. Include training recordings or written guides for routine editorial tasks and explain where staff should report problems.

An exit discussion does not mean you expect the relationship to fail. It tests whether responsibilities are clear enough to survive staff changes, new suppliers or a later business sale. Ask what assistance is available, how it is scoped and whether there are dependencies that would make a future move more involved.

Ask a less common handover question: what can our next supplier reasonably understand without your team explaining it live? The answer might include a content structure guide, a list of external services and a record of significant custom behaviour. Documentation does not need to describe every line of code. It should explain the decisions and dependencies that would otherwise be rediscovered at the business’s expense. Ask who updates that material when the website changes after launch.

If you are moving from another supplier, the website takeover process provides a useful starting point for access and handover.

9. Choose the support arrangement alongside the build

Ask what happens when something goes wrong after launch. Who receives a report, during which hours and how is urgency assessed? A response target is different from a guaranteed resolution time. Make sure you understand the distinction and the information you need to provide when reporting a problem. A broken payment flow needs different handling from a request to replace a photograph.

Distinguish routine maintenance, fault investigation and new work. Maintenance may cover defined updates and checks; it does not necessarily include unlimited changes or every issue involving another supplier. Ask for examples of included and excluded tasks that resemble your likely needs. This is more useful than comparing package names whose contents differ.

Consider your internal capacity. A business with an experienced marketing team may want technical care and occasional development. Another may need help keeping service information accurate and publishing projects. Be clear about the ongoing work you can realistically own. A website can become outdated despite good technical maintenance if nobody is responsible for content.

Use agreed criteria to make the final decision. For example, assess relevance of experience, clarity of scope, content support, testing, account control and ongoing fit. You can use scores as an aid to discussion, but avoid pretending that small numerical differences create scientific certainty. Record the reasons for the choice and the questions resolved before appointment.

If the preferred team is strong creatively but unclear about a critical connection, resolve that point before signing. A short paid investigation may be more sensible than a confident fixed estimate built on incomplete information. The important thing is that the uncertainty has a clear owner, purpose and decision point.

Also clarify how support works while a third party investigates. If a payment provider, hosting company or booking service is involved, which team coordinates the issue and keeps you informed? An agency may not control the final resolution, but it can explain the boundary of its responsibility. Record where you must hold your own support account and where the agency acts for you. This turns a broad promise of ongoing help into a process staff can actually follow.

Compare the proposed support arrangement with the responsibilities described in our WordPress maintenance service.

10. Use a worked shortlist and appointment checklist

Hypothetical example: a Northern Ireland engineering supplier needs a clearer service site, a searchable project library and an enquiry form that routes by request type. It has useful project photographs but inconsistent descriptions. Two managers can approve content, and a new brochure is due in four months. This is an illustrative brief, not a Podium client story.

The business sends the same brief to three agencies and asks each to explain a similar project, its content process, the proposed editor and how enquiry routing will be tested. One response focuses mainly on visual design. Another includes content interviews and migration but needs a separate review of the existing form connection. The third expects the business to supply all finished copy. The selection meeting records these differences before discussing price.

The business then asks its preferred candidate for a revised scope that names the page types, project import rules, content approvers and enquiry acceptance checks. It agrees that a labelled test enquiry for each request type must reach the correct recipient. It also asks an administrator to add one project during training and records any difficulties before final handover.

The written comparison gives the business a reason for its choice that colleagues can understand. The agency is appointed for a defined job, with the information it needs and the review dates agreed. When somebody proposes a new feature during development, both sides can compare it with that first release. They can then decide whether to include it now, replace another requirement or leave it for later, with any effect on cost and timing made clear.

Podium’s website service is the relevant next step if you want to discuss a scoped project. Bring the brief, the important constraints and any unresolved questions. A useful opening conversation should help establish what needs investigation and whether the working relationship is a sensible fit.

• Confirm the final scope and all assumptions in writing.
• Check factual content and permission responsibilities.
• Name the acceptance reviewers and launch decision maker.
• Confirm recurring costs, account control and handover material.
• Agree the first review after launch and support contact.