The decision for a small business
A brief helps the owner and developer agree what success means before design starts. It should define the audience, essential pages, required functions, existing brand assets, deadline assumptions and who approves content.
An illustrative small-business scenario
Consider this hypothetical situation: A shop owner supplies a logo but no product descriptions. A brief should establish who writes verified copy rather than making the developer invent product claims.
The point is not that every business has the same needs. For how to prepare a website design brief before hiring a developer, first identify the real decision, the person responsible and which evidence will show that the selected option worked.
How to plan it
Collect accurate company details, domain ownership information, preferred examples and the current customer enquiry process. Rank functions as essential versus optional, and name one approval contact.
Limits to understand
A design brief is not a signed quotation. New integrations, copywriting, migration, images and ongoing support need explicit scope and rights.
A practical next decision
A useful brief states business goals, target readers, required pages, branding assets, integrations, content owner and acceptance criteria. Supply examples of what you like without copying protected work. Decide who approves copy and who maintains the site after handover.
Write the problem before choosing a template
A useful website brief begins with the business problem, not a request for a modern-looking homepage. Explain what visitors currently struggle to understand and which decision the proposed website should support. For example, a service company may need customers to distinguish routine maintenance from emergency repair before calling. A brochure-style site and a booking application solve different problems even when both use attractive layouts. Record the desired customer action, the evidence that the action works and the person authorised to confirm requirements. Do not promise increased sales before a functioning site and reliable measurement exist.
Describe the audience in practical terms
Instead of writing that the site is for everyone, identify the people who actually make enquiries. A procurement officer may need company credentials and downloadable specifications, while a homeowner may need coverage, service steps and a phone number. Note the languages, typical questions and devices that matter, but distinguish observed customer behaviour from guesses. Avoid inventing demographic statistics or presenting a hypothetical persona as a research finding. The brief should help a developer understand what information must be easy to locate. If audiences have conflicting needs, ask whether separate service routes or clear navigation will resolve them.
Inventory pages by purpose
A request for five pages is incomplete until each page has a name, audience and purpose. Draft an inventory such as Home, Services, About, Contact and Privacy, then describe what belongs on each. A service overview with three distinct offerings may require deeper pages, while a focused business may need fewer. Count bilingual equivalents explicitly so the supplier does not assume that English and Malay share one content budget. Identify existing URLs that must be preserved and old content that should not be copied forward. This inventory supports meaningful scope comparison; page count alone does not reveal writing, translation or technical complexity.
Gather source material and approval owners
List the facts, photographs, product descriptions, credentials, policies and testimonials available to the project. For each item, record who supplies it, whether usage permission exists and who checks its accuracy. A designer cannot responsibly invent customer results, company certifications or service coverage to fill empty sections. Mark missing materials with an owner and a target date rather than disguising them as approved copy. Distinguish original photography, licensed stock assets and reusable supplier components. A clear content responsibility table prevents the project from stalling when both client and developer assume the other party will write the text.
State the business action on each page
A website brief should explain what a visitor can do after reading each important page. The action might be calling, emailing, requesting a quotation, downloading an approved brochure or comparing service scope. Do not automatically demand a complex form if a monitored phone or email route is more suitable. Specify where the action leads and who responds. A button label is not enough: an enquiry journey includes destination, confirmation and a way to recover from errors. Keep calls to action aligned with what the business can actually deliver. An unstaffed messaging channel is not a functioning support promise.
Separate essential features from later ideas
Make two clearly labelled groups: functions needed for the first accepted release and possible future improvements. A simple service site may need navigation, contact links and a working enquiry route, while customer accounts, payment processing or custom dashboards require different engineering and security work. Describe the behaviour of each essential feature, not just its name. A calendar icon could open an external booking page or represent a fully integrated scheduling system; those are not equivalent deliverables. Treat optional features as separately estimated until approved. This prevents attractive prototypes from quietly expanding the contract beyond the original budget.
Specify forms and where messages go
If an enquiry form is required, define fields, mandatory information, confirmation text, error handling, spam controls and the destination that receives submissions. Ask who owns the receiving mailbox and how successful delivery will be tested. MDN explains that client-side form validation improves user experience but is not a substitute for server-side checks when data is processed by a backend. Do not assume a visual form mock-up proves integration or safe handling of personal information. If the project excludes backend services, say so explicitly. The acceptance test should include an authorised submission and confirmation that the intended recipient actually receives it.
Plan English and Bahasa Melayu independently
For a bilingual Malaysian website, list which pages, navigation labels, forms, error messages and policy documents need English and Bahasa Melayu versions. Decide whether content is translated, locally adapted or written separately, and name the reviewer responsible for meaning and commercial accuracy. A language switch must lead to the corresponding information, not an unrelated homepage. Google's international guidance discusses separate language URLs and hreflang annotations when appropriate, but these technical signals do not certify translation quality. Ask how future updates will keep service terms consistent across languages. The brief should budget review time for both versions rather than treating Malay as an automatic afterthought.
Describe brand assets without inventing authority
Attach the approved logo, colour palette, typography guidance and examples of the intended tone. State which files are authoritative and who may approve changes. Reference websites can illustrate spacing, navigation or layout, but copying their text, imagery or branding is not an acceptable design brief. Distinguish inspiration from licensed assets and original work. If photographs include staff, customers or client sites, confirm permission and appropriate use before publishing them. The developer should know whether a supplied logo is final or only a draft. Do not let an attractive mock-up silently replace approved company identity or imply partnerships that do not exist.
Write mobile behaviour into the brief
The requirement should be more precise than responsive design. Ask for navigation that remains operable on a narrow phone, readable service terms, tappable contact controls and forms that work when the on-screen keyboard appears. Specify representative narrow and wide viewports, browser checks and whether portrait and landscape orientations matter. Test long Malay labels as well as English copy. Avoid fixing the layout for one fashionable device size. A responsive screenshot does not prove the customer can finish a task; include a test in which someone finds a service, reads an exclusion and sends a valid enquiry without hidden buttons or horizontal overflow.
Define accessibility acceptance rather than a badge
Accessibility should be planned before design approval, not added as a vague final request. W3C WAI recommends assigning responsibilities, setting goals and evaluating throughout the production process. Agree on a relevant WCAG target or selected test criteria, then specify keyboard navigation, focus indicators, meaningful headings, alternative text, readable contrast and labelled forms. Record who provides accessible content and who tests it. An automated scanner cannot prove all interactions work for people using assistive technology. Do not describe a plugin, theme or decorative badge as independent conformance certification. A written acceptance checklist is more useful than an unsupported accessibility promise.
Describe basic search discoverability
A design brief can request descriptive page titles, logical headings, crawlable internal links and an understandable URL structure. If the project involves replacing existing URLs, identify redirects and canonical choices for technical review. Google's developer guidance explains useful foundations for search, but no template or page count guarantees indexing or a particular ranking. Distinguish one-time technical setup from ongoing keyword research, content production and reporting. Provide a list of real services and customer questions rather than a pile of unrelated keywords. The developer should know what can be delivered at launch and what requires a separate continuing marketing plan.
List integrations and account ownership
Embedded maps, messaging links, appointment calendars, payment gateways and customer systems are different integrations with different dependencies. Describe what each connection must do, which account owns it and whether setup or subscription fees are excluded. A button opening a messaging application is not equivalent to a staffed customer-support system. A visual checkout screen is not proof that payments can be accepted safely. Identify who provides credentials through an approved secure process and who maintains the integration after handover. If a supplier proposes a different provider, ask for the operational and cost implications before approving a change.
Identify domain, hosting and maintenance boundaries
State who controls the domain registration, DNS, website hosting, email service and ongoing updates. These are separate components even if one supplier sells them together. A design contract should not silently authorise nameserver changes, mailbox migration or live deployment. Ask whether backups, software updates, security patches, content edits and incident response are included after delivery. Note who receives renewal notices and how access is handed over. If the business has a live website, document what must remain uninterrupted. A clear boundary between initial build and ongoing care prevents a low starting quote from concealing important operational responsibilities.
Set realistic stages and decision owners
A brief should identify discovery, content delivery, design review, development, testing and final acceptance as distinct stages. Name one person who consolidates business feedback and can approve scope changes. Note dependencies such as approved translations, image permissions and access to a safe test environment. A delivery date is not meaningful if the client has not supplied essential material or decisions. Agree on how revisions are counted and how late changes affect estimates. Keep production release permission separate from approval of a mock-up. A signed-off layout is not evidence that forms, navigation, performance and external integrations have passed their functional checks.
Use acceptance tasks rather than vague adjectives
Replace requirements such as fast, professional and easy to use with observable checks. Ask a new visitor to find a particular service, understand an exclusion, switch language and submit a test enquiry. Verify that the correct message reaches its intended destination, that mobile navigation remains usable and that important links work. Document browser, viewport and test-data assumptions so a failed case can be reproduced. Separate visual approval from integration testing and security review. If an item cannot be verified without a live external account, record that dependency instead of marking it passed. This makes handover evidence-based rather than impression-based.
Compare proposals using the same brief
Send the same approved inventory and acceptance requirements to each potential developer. Ask them to identify inclusions, exclusions, content responsibilities, revision limits, account ownership, licence costs and support after launch. A lower total may exclude bilingual writing, functional forms or testing that another proposal includes. Do not fill missing price information with guesses or assume that a package name describes identical deliverables. Keep unresolved questions visible until answered in writing. The useful output is a decision record showing what the business needs, what each supplier proposes and what still requires approval before work begins.