A Website Brief Checklist for Creative Businesses

Build the shared brief before choosing features

A useful website brief explains what your creative business needs the site to achieve, who it serves, what content it must present and how visitors should move from interest to enquiry or delivery. Start with shared requirements before choosing features, then add only the prompts relevant to your discipline.

For each item, mark it required now, desirable later or not needed, and name who will provide or approve it. Record unknowns rather than guessing.

• Goals: What should the website help the business achieve, and how will you recognise progress?
• Audience and services: Who needs to use the site, what do they need to understand, and which services should be clear?
• Content: What portfolio work, copy, images, case studies or documents are available, and who will supply them?
• Journeys and tools: What should visitors do next, and which existing tools or workflows must the site connect with?
• Constraints and decisions: What must be retained or changed, and who will answer open questions and approve the brief?

Set goals and visitor actions

State what the website needs to achieve before listing features. A clear goal helps a supplier judge which visitor actions matter and how the site should support them.

• Business outcome: What should improve as a result of the new or updated site? For example, should it explain your services more clearly, help suitable prospects decide whether to contact you, or make your work easier to present to a particular audience?
• Priority visitor actions: What should a prospective client be able to do? List the essential actions first, such as viewing relevant work, understanding how you can help, or sending an enquiry with enough context for you to respond. Then note secondary actions, such as signing up for updates or following a social channel, if these genuinely support the goal.
• What makes an enquiry useful: What information do you need to assess a request and decide what happens next? Note whether visitors should give a project type, budget range, location, intended use or preferred timing. Ask for details that help your team handle enquiries, and decide which questions to include.
• Current-site problems: If you have a site already, record specific examples rather than naming a solution. For instance, visitors may struggle to find a service, work samples may be difficult to organise, or an enquiry may arrive without the details your team needs. Say who encounters the problem and what happens as a result.
• How you will judge the outcome: Describe what you would expect to see or hear if the site is working better, such as more relevant enquiries or fewer requests for information already covered online. Treat these as intended outcomes, not promised results.

For each action, mark whether it is required now, desirable later or not needed, and name who will confirm the priority. This helps prevent secondary ideas from obscuring the main purpose of the site.

Describe your audience, services and position

Describe the people the site needs to serve, the work you want them to notice and the impression you want to leave. Give your supplier enough detail to shape the pages and language around your business, rather than relying on broad labels such as “businesses” or “creative clients”.

• Audience groups: Name the main types of prospective client or other visitor. For each, note what they need to understand before contacting you, such as the services you offer, relevant experience, your approach or how a project might proceed.
• Services and disciplines: List the services, disciplines, sectors or project types the site should present. Mark which are the priority, which support the wider offer and which should not be promoted. If services are aimed at different audiences, say which audience belongs with each.
• Position and approach: In your own words, describe what you want a prospective client to understand about your business. Note the qualities, working methods or kinds of work you want the site to convey. Add examples of language or existing material that express this accurately, and flag wording or impressions you want to avoid.
• Out of scope: Record audiences, services or project types the site should not target. This helps prevent a supplier from treating every part of the business as equally important or building pages for work you do not want to attract.

For each item, write down the page or content that could explain it, if known. Where your offer varies by audience, identify what each group should see first and what information would help them decide whether to enquire. This gives the supplier a practical basis for proposing a site structure and content, without asking them to guess at your priorities.

Inventory the portfolio and other content

Build a content inventory before deciding how the portfolio should work on the site. A supplier can use it to see what is ready, what needs attention and whether the content calls for simple pages, browsable categories or another approach.

For each project, campaign or example, record:

• What it is: project or campaign name, client or sector where it can be named, the discipline involved and a short description of the work.
• How visitors should find it: relevant services, disciplines, sectors or other categories to browse. Note where a project belongs in more than one category, and which examples should be prominent.
• What material exists: images, video, written explanation, project details, credits and any downloadable material. Note the file location and whether it is suitable for the website.
• What needs doing: mark each item as ready to use, needing an update, awaiting approval or needing to be created. Be specific about missing captions, project descriptions, images or other material.
• Who owns the next step: name the person responsible for supplying, checking or approving each item, and record any dependency on a client or collaborator.

Include more than portfolio pieces. Inventory the service descriptions, about information, team biographies, contact details, testimonials or other copy you want considered, as well as any PDFs or resources visitors should be able to access. Check the current website, shared folders, presentation documents and tools where content is stored; record where each item lives rather than assuming the supplier can find it.

Make the inventory useful for scoping, not just comprehensive. Mark each item as required now, desirable later or not needed. If an item is not ready, decide whether it must be completed before launch or can wait. That helps the supplier distinguish the site structure and content-management needs from work your business still needs to do.

A simple spreadsheet or document is enough. Use one row per item, with columns for its name, category, format, location, status, priority and responsible person. Add notes where a project needs a particular presentation or where several assets belong together.

Map visitor journeys and existing tools

Map the steps a visitor and your team actually follow, from looking at work to agreeing what happens next. This helps a supplier distinguish website requirements from processes that can stay in your existing tools.

• Enquiry or booking: Write down how a visitor moves from a relevant portfolio item or service page to contacting you. Note whether they should send a general enquiry, request availability, book a consultation or provide a project brief. List the information you need at that point, such as the type of work, intended dates or budget range, and say what should happen after submission: who receives it, who responds and where it is recorded.
• Files and project details: If a visitor needs to send reference images, a brief or other files, describe what they need to provide and who will use it. Note whether the website should collect the information or direct the visitor to an existing channel. Include any practical constraints, such as files being too large to send by email or information needing to reach a particular person.
• Review, approval and delivery: Describe any steps that happen after an enquiry becomes a project. For example, record who shares proofs or drafts, who gives feedback, who approves the final work and how completed files are delivered. Say whether visitors need to do anything on the website or whether these steps already happen through another tool or direct contact.
• Current tools and hand-offs: List the tools involved, such as email, a booking service, a customer record system, file storage or a client review platform. For each hand-off, note what information is entered, where it goes, who transfers or checks it, and whether the same details have to be entered more than once. Flag any existing content or records that may need to move from the current website or another system.
• What to ask the supplier: Mark which steps must happen on the website, which can remain in an existing tool and which could change. Ask the supplier to discuss required integrations, migration and workflow changes, including what happens if a hand-off fails or information is missing. Keep operational systems outside the website scope unless a connection or change affects the project.

For each journey, identify the person responsible at your end and mark the requirement as needed now, desirable later or not needed. That gives the supplier a practical basis for proposing a proportionate solution rather than assuming every step needs a new website feature.

Select the prompts that fit your creative discipline

Use only the prompts that match your work; they are options, not a standard feature list. For each, mark it required now, desirable later or not needed, and name who will provide the information or approve it.

• Photographers: image galleries, private client proofing or print enquiries.
• Designers and illustrators: project categories, case studies or licensing enquiries.
• Video producers: showreels, hosted films or project briefs.
• Agencies and digital studios: service teams, case studies or structured project enquiries.
• Architecture practices: project details, planning-stage information or practice credentials.

For photographers

Use these prompts where they fit your practice. For each, mark it required now, desirable later or not needed, and name who will supply or approve the information.

• Work to feature: Which photography disciplines, subjects or sectors should the portfolio show? Are there types of work you want to leave out?
• Project grouping: Should visitors browse by discipline, subject, sector, client or another category? Note any projects that belong in more than one group.
• How projects are presented: For each project, decide how many images are needed and whether captions, a short brief, your role, the process or the outcome should accompany them.
• Enquiry or booking request: What should a potential client be able to do, and what information do you need to assess the request, such as subject, location, intended use or timing?
• What happens next: Identify who receives the enquiry, who responds and where it is recorded. Say whether visitors need to request a booking or simply start a conversation.
• Image clearances: List any permissions, credits or client approvals still to resolve before images and project details can appear.

For designers and illustrators

For a design or illustration portfolio, brief the supplier on how visitors should find and understand different kinds of work, not just how many projects to display.

• List the disciplines, project types or sectors visitors should be able to browse separately. Note any work that belongs in more than one category.
• For each case study, say whether it needs a short account of the client brief, your contribution and the result as you describe it. Identify projects that need more context than a title and image.
• Record what will show each project clearly: for example, final artwork, layouts, sketches, process images, captions or explanatory text. Note where material is missing or needs preparing.
• Decide whether every visitor should use a general enquiry route or whether some work should invite a more specific project discussion. If specific, note what information would help you respond.

This helps the supplier plan a portfolio structure around how your work is commissioned and presented, rather than adding categories or case-study fields that do not serve your visitors.

For video producers

For each prompt, mark it required now, desirable later or not needed, and name who will supply or approve the information.

• Portfolio: List the production types and sectors visitors should be able to identify quickly. Note which projects best represent each.
• Project presentation: Specify the role of video, stills, captions and written context. Record what each example needs to explain, such as the brief, your contribution or the finished outcome.
• Viewing and delivery: Tell the supplier whether work is for public viewing, private review or delivery to clients. Note any access needs, preferred hosting arrangements or media delivery requirements to discuss.
• Enquiries: Map what a prospective client should do next. List the project details they should provide, such as production type, intended audience, timings or budget range, if relevant to your process.
• Files and hand-offs: If visitors need to send files or receive materials, describe what is exchanged, who handles it and which existing tools are involved. Ask the supplier to clarify what belongs on the website and what can stay in those tools.

For agencies and digital studios

For an agency or digital studio, use these prompts to explain how visitors should understand your offer and move towards a useful conversation. For each, mark required now, desirable later or not needed, and name who will provide or approve the information.

• Service navigation: Should visitors browse by discipline, service, sector or campaign type? Note where services overlap and what a visitor needs to understand before choosing a route.
• Case studies: For each example, list the client or sector, the original brief, the work delivered, your agency’s role and the outcome or materials you are able to share. Identify any missing details or approvals.
• Enquiries: What should a prospective client provide, such as their organisation, challenge, required services, budget context or timing? Say where the enquiry should go and who will review and respond.
• Client reviews: Record any stages where a client checks or approves published work or copy. Decide whether the website only needs to display approved material, or whether a specific review hand-off must be supported. A client portal is not an assumed requirement.

Clarify permissions, credits and approvals

Add a rights and approvals check to the content inventory, so the supplier can see which material is ready to publish and what still needs a decision. Complete these prompts for each portfolio item and any other asset the site will use, such as images, copy, video or client logos.

• Identify the work. Record its title or project name, the creator and any other people or organisations who contributed. Note where the current file is held and which version is intended for the website.
• Record ownership and permission. Note who owns the work now, whether permission to publish it on the website has been confirmed, and who checked that permission. Keep the status clear, such as confirmed, to check or not for publication; do not treat inclusion in an old portfolio or PDF as confirmation.
• Check commissioned work. Record who will check ownership and permission. If ownership or permitted use is unclear, name the person who will check it and obtain any advice needed. The website brief records the question; it does not resolve it.
• Specify credit and context. Record the exact credit line, names or links required, and whether the client or project can be identified publicly. Note any agreed wording or context that must appear beside the work, and who will verify it before publication.
• Name the people responsible. For each asset, state who supplies the final file, who checks names and factual details, who confirms permission and who gives final approval. These may be different people, so avoid assigning every decision vaguely to “the team”.
• Map the approval step. Describe how a draft reaches the approver, how feedback is returned and who confirms that changes are complete. If a client or another party must review work, record the hand-off and who will chase or resolve outstanding feedback. Flag any approval step that could change the content, design or build scope.
• Plan for updates. Name who will maintain, replace or remove assets after launch, and what should happen if permission changes or a project is no longer suitable to show. Mark each task as required now, desirable later or not needed, and identify its owner or approver.

Where an item is not cleared or approved, say so plainly in the brief. The supplier can then distinguish content that is ready from a dependency that needs attention, rather than assuming every supplied asset can be published.

Decide whether a template and existing tools are enough

Use the brief to decide what the website needs to do, rather than assuming that every requirement calls for a bespoke build. A template and the tools you already use may be enough if they let you present your work, explain your services and handle enquiries clearly.

For each requirement, mark it as required now, desirable later or not needed, then record who will provide or approve the information and who will maintain it.

• Check the essentials: Can your preferred approach organise and display the portfolio, explain your services and direct visitors to the right enquiry route? Note any specific content structure or presentation need that does not fit.
• Test the visitor journey: Write down what a visitor needs to do, what information they need to provide and where the enquiry goes next. If staff can handle the next steps in their existing process, the website may not need to reproduce that process.
• Identify the point of friction: Record where a template, current website or separate tool falls short. Be specific: for example, identify a hand-off or content update that staff cannot manage in the way the business needs, rather than adding a feature without explaining its purpose.
• Separate website work from operations: A portfolio and enquiry route may belong on the website; a wider production, project or client-management process may be better handled in an existing tool or scoped as a separate piece of work. Identify which staff use the process and what information must move between systems.
• Check readiness and responsibility: Note whether content, permissions and approvals are ready, how much staff time will be available to supply and review material, and who will look after updates and maintenance. A more tailored solution will not resolve missing content or unclear ownership.
• Compare the options against priorities: Review required-now items first, then weigh later enhancements against staff effort, content readiness and ongoing maintenance. Keep optional ideas visible without letting them obscure the core need.
• Ask for alternatives and trade-offs: Invite the supplier to explain what can be handled by a template and existing tools, what would need a tailored build, and what could remain outside the website. The brief should describe the problem and constraints; it does not need to prescribe the solution.

If the essentials fit an available approach and the remaining work can stay in tools you already use, a straightforward website may meet the need. Explore a more tailored build when a must-have portfolio structure, integration, migration or enquiry and review journey does not fit. Agree which requirements are in scope now, which are deferred and who owns each next step.

Turn the checklist into an agreed scope

Before agreeing the project, send the supplier your completed core checklist and only the discipline-specific prompts that apply. Use the handover to turn your priorities into a shared record of what will be delivered, what each person must provide and which decisions are still open.

1. Confirm the priority of each requirement. Mark every item as required now, desirable later or not needed. Ask the supplier to reflect those choices in the proposed scope, so a useful later enhancement is not mistaken for a launch requirement and an explicit exclusion is not left ambiguous.
2. Record what is included and excluded. List the pages, portfolio or case-study content, visitor actions and website functions that are part of the work. Note anything outside the project, including steps that will continue in an existing tool. If a requested feature is still being discussed, record the question rather than treating it as agreed.
3. Assign content and asset responsibilities. For each item, name who will supply the copy, images, video, project details or other material, and who will check it before publication. Record whether the material is ready, still being prepared or needs a decision. Agree how missing or late content will be handled before it affects the work.
4. Confirm permission and approval hand-offs. Name who checks that portfolio work can be published, confirms required credits and gives final approval. Where a client, collaborator or another party must review material, state who coordinates that review and how the supplier will know it is complete. Keep unresolved permissions visible rather than assuming they have been cleared.
5. Ask the supplier to surface assumptions and dependencies. Request a written list of points the proposal relies on, information still needed, decisions you need to make and issues that could change the agreed work. Discuss any proposed connection to another tool or transfer of existing website content, including what information must be available and who is responsible for it. Record the outcome of each discussion.
6. Agree decision-making and communication. Identify the person who can approve content, design and changes to the agreed scope, as well as the people who will contribute specialist feedback. Set out how feedback will be gathered and consolidated, so the supplier receives one clear response rather than conflicting instructions.
7. Clarify what happens after handover. Agree who will update portfolio items, manage routine website content and look after any connected tools. Record what guidance or access needs to be handed over and who to contact for ongoing maintenance, if that is part of the arrangement. Make sure someone in the business accepts responsibility for keeping the site current.
8. Decide how you will review success. Return to the goals in your brief and agree what evidence you will look at, who will review it and when. Measures should relate to the outcomes you chose, such as the quality of enquiries or whether visitors can find the information they need. Treat the review as a way to decide what to improve, not as an assumed result of the build.

Keep the completed checklist with the supplier’s proposal and the final agreed scope. A custom build is not necessary where a suitable template and your existing tools meet the brief.