How to Prepare for a Website Project Without Writing a 20-Page Brief

You do not need to become a web designer before hiring one. You do need to explain what the business does, what the website should help accomplish, and which facts the developer cannot responsibly guess.

A useful brief is a starting point for decisions. It can be short enough to write between other responsibilities, provided it contains the right information. Twenty pages of vague preferences are less helpful than one page of clear priorities and a folder of genuine assets.

Here is what to prepare, what can wait, and how to keep the project moving after the first conversation.

Bring the business context. Your developer can help turn it into pages, design, and functionality. You should not have to specify the technical solution before discussing the problem.

1. Choose the main outcome

Finish this sentence: “When the website is working well, more of the right people will _____.” The answer might be request an estimate, book an appointment, visit a store, understand a service, or buy a product.

Choose one primary outcome and identify any secondary ones. If the project must equally prioritize hiring, wholesale sales, retail shopping, events, and general brand awareness, discuss how those audiences should be separated. A single opening screen cannot make every path equally prominent.

Then define the quality of the outcome. A contractor may want inquiries for larger residential projects within a particular service area. A studio may want event requests with dates and approximate group size. That detail changes the content and form design.

2. Describe the customer in practical terms

You do not need a fictional persona with a favorite coffee order. Describe the person, the situation, and the questions they need answered before they take action.

For example: “Homeowners in our service area who need a driveway replaced. They want to see similar work, know whether we handle preparation, and understand how to request an estimate.” That is enough to begin shaping a useful page.

Collect questions from actual conversations. What do customers ask repeatedly? What assumptions create confusion? What makes a project a poor fit? Those answers often become the most valuable service copy and FAQs.

If you serve different audiences, explain their differences. A commercial buyer may need capabilities and procurement details while a homeowner needs process and reassurance. The site can support both when the paths are intentional.

3. List the essential tasks

Describe functionality as tasks people must complete. “Customers should request an appointment and receive confirmation” is more useful than “we need something interactive.” “Staff should update product descriptions without a developer” identifies a real editing requirement.

For each task, say who uses it, what information goes in, and what should happen afterward. Include existing tools the workflow depends on, such as scheduling, accounting, payment, email, or customer management systems.

Separate needed at launch, useful soon, and possible later. A clear first release can be complete without including every future idea. Ask your developer which future needs affect today's foundation and which can safely wait.

An effective brief records decisions and questions, not a finished website specification. Image: Unsplash; license.

4. Assemble a small, organized asset folder

Gather the materials you already have. Avoid delaying the conversation because everything is not polished yet. Identifying a missing logo file or a photography gap early is useful progress.

Use originals when possible. A logo copied from a screenshot can be difficult to reproduce cleanly. Photos sent through messaging apps may have been compressed. Tell the developer which materials are approved for publication and which need permission or replacement.

For project photos, add a short note explaining the work and what the image shows. A developer cannot reliably identify the service, location, material, or project sequence from a filename like “IMG_4821.”

5. Share references with reasons

Three useful references are often enough. For each one, point to something specific: the menu is easy to browse, the service explanation is clear, the photography feels appropriate, or the booking path is simple.

Explain dislikes the same way. “This menu covers the content on my phone” gives a concrete concern. “I hate modern websites” leaves too much room for interpretation.

References communicate preferences; they are not permission to copy another business's branding, photography, or text. Your project should use your own material and a design appropriate to your audience.

If a visual preference conflicts with the main task, discuss the tradeoff. A dramatic opening video may support one brand, while another business needs immediate access to a menu or phone number. Tie decisions back to what the customer came to do.

6. Identify accounts without sharing passwords in a brief

Make a list of the domain registrar, hosting provider, existing CMS, analytics property, email service, and any essential integrations. Note who currently has administrative access and whether you can sign in.

Do not paste passwords, recovery codes, or payment details into the planning document. Arrange access through appropriate invitations or another agreed secure method. Access can be provided when the work requires it.

Flag anything uncertain. “The former developer may control the domain” is important information. Discovering that during planning is easier than discovering it on launch day. Domain and email changes need particular care because a website migration can affect more than the website.

7. State the budget and deadline honestly

A budget range helps determine a feasible scope. It does not require you to know the final price in advance. Explain whether it covers only the build or also photography, copy, subscriptions, and ongoing support.

For a deadline, distinguish a preference from a fixed event. “We would like it soon” differs from “our trade show opens on this date.” If a fixed date matters, identify what must be ready and what could follow later.

Ask what the schedule depends on: content delivery, access, review time, approvals, or third-party work. A fast development phase cannot compensate for several weeks waiting on the correct menu or product list.

Review the current service packages as a starting point, then discuss the actual scope. For support and recurring responsibilities, read the website maintenance guide.

8. Choose a decision-maker and review process

Name the person who can approve content, design, and scope. Other people can contribute, but somebody needs to reconcile conflicting feedback and make the final call.

Agree on how feedback will be collected. A single organized set of notes is easier to act on than scattered texts, emails, and comments describing different versions. Include the page, the issue, and the intended result.

For example: “On the patio service page, the estimate button is difficult to find after the gallery. Please make the next step obvious there.” That describes a user problem while leaving room for the developer to choose an appropriate solution.

Avoid waiting until final review to introduce a major requirement. If online deposits are essential, mention them at the start. If they become important later, ask how they affect scope and schedule.

Copy this short brief

Use these prompts as a one-page starting document. Bullet-point answers are fine.

• Business: What do we do, and where do we operate?
• Primary audience: Who should use the site, and what are they trying to do?
• Main outcome: What action matters most?
• Current problem: What makes the existing situation difficult?
• Launch essentials: What pages and tasks must work on day one?
• Existing tools: What systems must the site connect to?
• Available materials: What copy, photos, reviews, and brand files do we have?
• References: Which three examples help explain our preferences, and why?
• Constraints: What budget range, deadline, or access issue matters?
• Approvals: Who decides, and who supplies the missing information?

Mark unknowns explicitly. “Need help writing service copy” is actionable. Pretending the copy is ready can create an avoidable schedule problem.

Prepare for launch while planning the project

Decide who will receive form submissions, update business details, renew accounts, and request support. Ask how you will learn to edit the parts you are expected to maintain.

Clear ownership keeps approvals and post-launch responsibilities moving. Image: Unsplash; license.

Agree on a launch checklist: important pages reviewed, contact details verified, forms tested end to end, account access confirmed, and recovery arrangements understood. Your developer should help define the technical checks.

The strongest preparation is a short, honest picture of the business and the decisions ahead. Bring that, a few real assets, and a willingness to answer questions. There is enough to start a productive conversation about your website project.