Write a useful brief for your co-op’s website

A website brief should explain what people need to accomplish and what your co-op can maintain. “A modern site that reflects our values” is a useful aspiration, but it does not tell a designer which pages to build or what success looks like.

Start with your audiences and the actions they need to take. A prospective member may need to understand eligibility, responsibilities and the joining process. A customer may need opening hours, a product list or a booking route. Existing members may need approved information. Put the most important journeys ahead of a long feature wishlist.

Describe audiences and actions

Choose three priority journeys for the initial project. For each, write the visitor's starting question, the information they need, the action they take and who handles the result. This connects design to the co-op's actual capacity.

• Joining: understand membership, check eligibility, apply or contact the membership lead.
• Buying or booking: understand the offer, see practical details and complete the purchase or enquiry.
• Finding information: locate a current policy, event, contact or approved member document.

Explain your co-op accurately in plain language. State what members own or influence according to your actual model; do not rely on the word “co-operative” to answer every visitor's question. Identify who approves claims about membership, governance and services.

Use this sample brief structure

Organisation and purpose: describe the co-op, the people it serves and why this project is needed. An illustrative community workshop might need visitors to understand facilities and book an induction, while the committee needs an easier way to update opening arrangements.

Initial scope: list the pages and journeys needed for launch, plus items deliberately scheduled for later. Specify any existing content, images or branding and whether the co-op has permission to use them.

Content ownership: name the people who draft, check and maintain pages. For each high-use page, record its review trigger: changed prices, revised joining rules, a new event or a change of premises.

Editing: describe tasks ordinary editors should complete without developer assistance. Examples include publishing an event, changing a contact, adding an accessible document and updating a short question-and-answer section.

Integration: list forms, payment services, mailing tools and any member system. State who receives submissions and how failed delivery is detected.

Operations: include hosting, domain control, backups, updates, support, documentation and exit requirements. Ask for clear responsibilities and current costs rather than an unexplained maintenance line.

Make accessibility a reviewable requirement

Ask the supplier to propose an accessibility target, testing approach and process for resolving issues. Include real tasks and users where practical. A claim that a theme is accessible does not prove the finished pages, forms and documents will be usable.

W3C's form guidance explains the need for labels associated with controls. In your brief, require clear field labels, understandable instructions and helpful errors. A prospective member should not lose their application because the form rejects an unexplained format.

The WAI Easy Checks cover useful preliminary checks such as keyboard access, headings and text alternatives, while explicitly stopping short of a comprehensive assessment. Ask how the supplier will test beyond basic automated results.

Agree acceptance and handover

1. A new visitor can complete each priority journey on a phone and supported desktop browser.
2. Form submissions arrive with the correct owner and a clear next step.
3. An editor can make the agreed routine changes using the documentation.
4. Organisational account, domain and content ownership are recorded.
5. The relevant backup and recovery process has been demonstrated.
6. Known issues, remaining content tasks and support responsibilities are documented.

If private member features enter the brief, use the member-portal decision guide to confirm the operational need. A public website and a secure member service have different ongoing demands. For WordPress projects, include the maintenance process in the brief from the outset.

Take your draft into a website and technology support discussion to turn the requirements into a practical delivery scope.