What to prepare before starting a website project

Start with an editable brief

You do not need finished copy or a technical specification to begin a conversation. You need enough information to explain the job and identify what remains unknown. A short, honest brief is more useful than a long document filled with guesses.

• Download the blank website project brief
• Download a completed fictional example

Both files are editable Markdown: open them in a text editor or copy their contents into your preferred document. Keep one working copy, replace the prompts and date each substantial revision. Put unanswered questions in the decision log with an owner and a due date.

For a guided version, use the Website Project Brief & Page Planner. Add your project decisions and page inventory, then download a Markdown brief, CSV page list or JSON plan to reopen later. The planner keeps unsaved work only in the current browser tab.

Define the visitor and the main action

Describe who needs the website and what they need to accomplish. “Everyone who might buy” is too broad to guide a page. A more useful audience might be people comparing a service, readers looking for a particular topic or returning customers checking preparation instructions.

Start with real questions from inquiries, support conversations or your current website. The Government Digital Service's guidance on defining user needs recommends understanding users and their operational needs before selecting technology. For a small website, that can begin with a few actual conversations and a written list of recurring tasks.

Choose a primary action such as requesting a quote, finding an article or registering for an event. Name the information visitors need before taking that step. Secondary actions can support it, but each page should have a reason to exist.

Give every page a job and a content owner

Make a page inventory before deciding on the navigation. Record each page's purpose, intended action, content owner and readiness. A page count alone cannot show whether the material exists or whether the site supports the visitor's whole task.

For an existing site, add the current URL and mark whether to keep, revise, merge or remove the page. Record valuable downloads and other sites or campaigns that link to it. Read the URL-change guide before deciding that every page needs a new address.

Gather usable content and list the gaps

Collect the service facts, contact details, original logo files, photographs, examples of work and any existing copy worth keeping. Record which files are approved for public use, which need permission and which are merely references. A folder of unlabeled images does not explain where they belong.

For each missing item, specify who creates it, who checks the facts and when it is needed. If copywriting, photography or migration is part of the requested work, say so explicitly. Include the amount: six service pages and 80 existing articles are very different content jobs.

Share a few design references with a sentence about each useful detail: readable type, a clear project gallery or a helpful comparison. Avoid asking to copy another business's wording, brand or artwork. Note the brand assets and rules you already have, and which need development.

Use the Content Brief Generator to outline an individual page after its purpose is settled. It builds an editable structure from the details you supply; it does not research your business or produce verified facts. The image preparation guide covers preparing actual files for publication.

Describe features as tasks people can complete

“A contact form” leaves several decisions open. Describe what the visitor enters, where the request goes, who follows up and what happens when delivery fails. For a booking feature, explain whether visitors request a time or reserve an available slot, and whether payment is involved.

List the systems a feature depends on, who controls those accounts and which details need investigation. Avoid choosing an integration solely from a screenshot. The quote should account for the real workflow, provider requirements and ongoing charges.

The Form & Intake Planner helps arrange questions, required fields and conditional sections, then export a JSON plan or Markdown brief. Its preview does not send submissions or connect to your inbox. Add the delivery and follow-up decisions to the project brief.

Include accessibility in the brief and review plan from the start: navigation, forms, images, content and any external widgets all need attention. W3C's planning guidance treats accessibility as work to assign, evaluate during development and sustain after launch.

Connect budget and timing to actual dependencies

Share an available range or spending limit, and say whether it covers only the build or also writing, images, migration and recurring services. Separate one-time project work from domain, hosting, software and maintenance costs. If the budget is unsettled, identify who can set it and what they need to decide.

Explain the reason behind a requested date. A printed campaign with a fixed distribution date creates a different constraint from a preferred launch month. Work backward through content delivery, access, design approval, build review, testing and launch. Give the builder dates for your contributions as well as a target for theirs.

Choose one person to collect feedback and confirm decisions. Other reviewers can contribute, but contradictory comments need resolution before another revision. Agree how new requests affect scope, cost and schedule instead of treating every idea as part of the original launch.

For Sample Catalog Studio, the gallery cannot be approved until image permissions and selections are complete. If those materials arrive late, the decision is whether to change the launch scope or move the date. Quietly replacing them with unapproved images is not a workable shortcut.

Know who controls the accounts

List the registrar for your domain name, website hosting, editor or CMS, business email and any booking, payment or form service. Record the account owner, renewal responsibility and whether access has been confirmed. Keeping an existing domain does not require moving email; DNS records direct these services separately, so record both before a website change.

Your business should retain control of important accounts wherever practical, with appropriate access granted to the people doing the work. ICANN's registrant guidance explains the responsibility to keep registrar account information current, including payment details when using automatic renewal.

Put account names and access tasks in the brief, not passwords, recovery codes or secret keys. Decide how invitations or secure access will be arranged separately. Ask what source files, editable assets, instructions and licenses are included at handoff, and who handles updates after launch.

If people need to publish repeatable content, work through when a website needs a CMS before choosing the platform. Use the website handoff checklist to turn the agreed ownership and access requirements into checks at delivery.

Check that the brief is ready to discuss

• The audience and main action are specific enough to guide page decisions.
• Each launch page has a purpose, a content owner and a readiness status.
• Required features describe the full task, including what happens afterward.
• The budget, date constraints, approver and review process are visible.
• Account ownership and access gaps are recorded without credentials.
• Open questions and later ideas are separated from essential launch work.

You can start with unresolved questions. The useful distinction is between a known requirement, an assumption and a decision that still needs an answer. Once scope is agreed, use the business-page publishing checklist to review the actual pages.

For help turning the brief into a working website, explore Plainview's website planning, design and development. Share the main priorities and open questions when you start a project conversation.