Working With a Web Agency: Roles, Feedback and Sign-Off

Agree who decides

If you are still comparing agencies, start with our guide to choosing a web developer. Before work starts, name one person on your side who makes the final call on scope, design and content. The GOV.UK Service Manual, which sets out how UK government teams build digital services, describes this role in its page on what each role does in a service team. The service owner "must have the decision-making authority to deliver on all aspects of a project". The product manager is the one who will "prioritise user stories for each work sprint".

A small business does not need those titles, but it needs the function. When several colleagues send comments directly, the developer has to guess which opinion wins. A simple split:

• Decision-maker: one person who approves designs, settles disagreements and signs off.
• Contributors: colleagues who supply content, facts and comments, through the decision-maker.
• Agency contact: one named person at the agency who receives feedback and replies on progress.

Agree how quickly each side will answer questions; our guide to how long a website takes to build covers where time usually goes.

Start with discovery

Discovery is the first stage, where the agency learns about your business, your customers and your constraints before designing anything. The Service Manual's page on how the discovery phase works says "you should not start building your service in discovery". It also advises reframing a ready-made solution as "a problem to be solved".

So come to discovery with the problem, not just the design you have in mind:

• who your customers are and what they come to the site to do;
• what is not working today, with examples;
• constraints: a launch date, systems the site must connect to, legal requirements;

For an app or web application, a written brief helps the agency estimate; see our guide to writing a web app project brief.

Write down what "done" means

User stories are a simple way to write down what was agreed. The Service Manual's guide to writing user stories says each one should state "the person using the service (the actor)", "what the user needs the service for (the narrative)" and "why the user needs it (the goal)", usually in the form "As a… I need/want/expect to… So that…".

Each story can carry acceptance criteria: "a list of outcomes that you use as a checklist to confirm that your service has done its job". They are "often written as a list that begins with 'it's done when…'". For a booking page, that might be:

• it's done when a customer can choose a date and time on a phone;
• it's done when the customer gets a confirmation email;
• it's done when the booking appears in your team's calendar.

Agree these before the work is built. They become your sign-off checklist, and show when a new idea is a change rather than a fix. How they fit into the contract is covered in our software development contract guide.

A regular rhythm of check-ins

The principles behind the Agile Manifesto, published in 2001, say "Business people and developers must work together daily throughout the project" and "Working software is the primary measure of progress". Daily contact is more than most small projects need, but short, regular check-ins on real work beat a long silence and a big reveal.

The Service Manual's agile tools and techniques page describes the "show and tell", a regular meeting where the team demonstrates its work, and where stakeholders can be invited to see "the user stories you've completed". Ask your agency for a short call every week or two showing what was built, what is next and what they need from you.

Feedback that can be acted on

Clear feedback is the part of a project the client controls most:

• Collect first, then send once. Gather your colleagues' comments, settle conflicts between them, and send one consolidated list per round.
• Be specific about where. Give the page address, the section, and the device and browser you used.
• Describe the problem, not only the fix. "Customers won't know this button books a call" helps more than "make the button red".
• Separate bugs from preferences and new ideas. Something that breaks an acceptance criterion is a bug. A different shade of blue is a preference. A new page is a change request.

Ask how many feedback rounds each stage includes.

Reviewing on the staging site

A staging site is a private copy of the new site where you can click through work in progress. Review there, not on design images alone: real content, forms and phones show problems a static image hides.

When you review, go through it the way a customer would. Open it on your own phone. Follow each user story from start to finish, send each form, and check that the emails arrive at the right inbox. Our guide to testing a website before launch lists the checks in more detail.

Handling change requests

New ideas during a project are normal. One of the Agile principles is to "welcome changing requirements, even late in development". What causes trouble is change that nobody writes down. A simple routine:

1. Write the request down, as a new user story if it is large.
2. Ask the agency what it affects: cost, launch date, other features.
3. Decide: add it now, swap it for something of similar size, or move it to a list for after launch.
4. Confirm the decision in writing, so both sides' records match.

Sign-off

Sign-off is the point where you confirm the work meets what was agreed. With acceptance criteria written down, it is a checklist rather than a debate: tick each "it's done when…" and list anything that fails. Sign off in writing, by stage or for the whole project, as your contract sets out.

Keep "must fix before launch" separate from "nice to have later". A small issue need not hold back launch if both sides agree a date to fix it.

Handover: logins, domain and accounts

At the end of a project, make sure your business can run without the agency. The most important item is the domain name. ICANN, which oversees domain names, sets out registrants' benefits and responsibilities: the registrant "will assume sole responsibility for the registration and use of your domain name", must "keep your Registrar account data current", and, with automatic renewal, "must also keep your payment information current". That only works if the domain is registered to your business and you can log in to the registrar account. Our guide to domain names explains how to check. To check each account role by role, use our audit of what your business should own when a website is built.

Ask for a written list of everything the site depends on, with who owns each account and how you log in:

• domain registrar and DNS provider;
• hosting, and where backups are kept;
• the content management system, with an administrator login for your business;
• email sending, analytics, Search Console, payment and other connected services;
• code repository, licences for paid themes, plugins and fonts;
• a short guide or walkthrough on editing content.

Store the logins in a password manager your business controls. For what comes next, our website maintenance checklist covers the ongoing work.

A checklist

• One decision-maker on your side and one contact at the agency are named.
• Discovery starts from the problem and your customers, not a finished design.
• Main features are written as user stories with "it's done when…" criteria.
• Feedback is consolidated, numbered and sorted into bugs, preferences and changes.
• Changes are written down with their effect on cost and dates before they are approved.
• Sign-off is in writing, against the acceptance criteria.
• The domain and every account are in your business's name, with logins you hold.

Frequently asked questions

How many people should give feedback to the agency?

One person on your side should send feedback and make the final decisions. Colleagues can comment, but through that person, so the agency gets one consolidated list instead of conflicting requests.

What are acceptance criteria?

A short list of outcomes that show a feature works, often written as "it's done when...". The GOV.UK Service Manual describes them as a checklist to confirm the service has done its job. Agree them before the work is built and test against them at sign-off.

What is a staging site?

A private copy of the new site where you can click through and test work in progress before it goes public. Review on it with your own phone, real content and real forms, not only on design images.

How should we handle new ideas during the project?

Write each one down, ask the agency what it changes in cost and dates, then decide: add it, swap it for something of similar size, or keep it for after launch. Confirm the decision in writing.

What should we get at handover?

A list of every account the site depends on, with logins your business holds: domain registrar, DNS, hosting and backups, the CMS admin, analytics, email and payment services, the code repository and licences, plus a short guide to editing content.

Planning a new website? We start with discovery and a plan, review designs on phone and desktop, build on a private staging site you can click through and comment on, check speed, forms and accessibility before launch, and finish with a short handover so your team can edit content. See our website development service and all our services, or email [email protected].