Website Design Brief Checklist for Hobart Businesses

A useful website design brief tells a web designer what the business needs the website to achieve, who it must help and what must be delivered—not how every screen should look. For a Hobart business, the best brief is usually a clear two-to-five-page working document covering goals, audiences, content, functions, brand requirements, technical constraints, responsibilities, budget range and timing.

You do not need to know design terminology or choose a platform before speaking with an agency. You do need to explain the business problem, the customer journey and the practical limits. This checklist will help you prepare enough detail for more accurate conversations and comparable proposals.

What is a website design brief?

A website design brief is a project summary shared with potential designers or developers. It creates a common starting point for discovery, scoping and quoting. It is not the final specification: research may reveal better page structures or simpler ways to deliver a feature.

A strong brief answers three questions early:

• Why does the project exist? State the business problem or opportunity.
• Who must the website help? Describe priority customers and their main tasks.
• What would a successful result look like? Name measurable outcomes and required capabilities.

DanSol’s Hobart web design and development service covers planning, design and implementation. A focused brief helps the first conversation concentrate on the project rather than reconstructing basic information.

Website design brief checklist

1. Business background and project reason

Begin with a short description of the business: what you sell, where you operate, how customers currently find you and who will manage the website. Then explain why the project is happening now.

Useful reasons are specific. “Our website looks old” gives little direction. “Mobile visitors cannot easily compare our three services or request a quote, and staff cannot update project examples” identifies two problems that can be investigated.

If there is an existing website, say whether the project is expected to improve it or replace it. Do not decide on appearance alone. DanSol’s guide to choosing between a website redesign and rebuild explains the technical and operational factors that should influence that decision.

2. Goals and measures of success

Choose one primary goal and two or three supporting goals. A local service business might prioritise qualified enquiries; an accommodation operator may prioritise direct bookings; a retailer may need profitable online sales and fewer delivery questions.

Translate broad ambitions into evidence you can review. Examples include:

• more completed quote requests from the right service areas;
• fewer phone calls about information that should be clear online;
• a higher proportion of bookings completed on mobile;
• staff being able to publish approved content without developer help;
• fewer checkout, form or booking failures;
• clearer tracking of enquiries, sales or appointment requests.

Avoid promising a fixed Google ranking or an arbitrary traffic figure. Record a baseline where possible and agree on how important actions will be measured after launch.

3. Priority audiences and customer tasks

Describe real customer groups without inventing elaborate personas. Include location, situation, common questions and what each group needs to do on the website.

For example, a Hobart building consultant might serve homeowners planning renovations, commercial property managers needing compliance advice and interstate owners coordinating local work. Those visitors may need different evidence, terminology and contact paths.

List the top tasks in priority order. These may include checking service areas, comparing services, viewing completed work, confirming accessibility, booking a time, requesting a quote or finding an urgent phone number. A design should make the most important tasks obvious on a small screen as well as a desktop.

4. Scope, pages and content

List the pages you expect, but allow the designer to recommend a better structure. A typical service website may need a homepage, individual service pages, about page, project examples, frequently asked questions, contact page and privacy information. Ecommerce, events, memberships or multilingual content require additional planning.

For every proposed page, note:

• the customer question it should answer;
• the action it should support;
• whether suitable copy and images already exist;
• who will write, review and approve the content;
• whether existing content must be migrated or retired.

The Australian Government’s business website guide recommends planning site structure and considering branding, content management, hosting and ongoing promotion. Treat content as project work with an owner and deadline—not as material that will somehow appear near launch.

5. Required features and integrations

Separate essential functions from optional ideas. Describe the outcome rather than prescribing a plugin. “Customers need to choose a service, see available times and receive a confirmation” is more useful than “install a calendar plugin”.

Possible requirements include:

• enquiry, application or quote forms;
• appointments, classes, accommodation or event bookings;
• online payments, deposits or product sales;
• email marketing, CRM or accounting integration;
• staff directories, project portfolios or document downloads;
• customer accounts, memberships or restricted resources;
• analytics, conversion tracking and consent controls.

Name systems already used by the business and who controls each account. If the right enquiry path is uncertain, compare the operational trade-offs in DanSol’s guide to online booking and contact forms for Hobart businesses.

6. Brand and visual direction

Provide the current logo files, brand colours, typefaces, photography and any brand guidelines. Explain what should remain recognisable and what may change. If the brand is being updated at the same time, state which work depends on the other.

References are helpful when you explain why. Instead of listing three websites you “like”, identify the useful qualities: clear service comparison, restrained use of colour, strong project photography or simple mobile navigation. Avoid asking to copy another organisation’s design.

State whether original photography, illustration, iconography or video is available or must be created. Confirm permissions for customer images, testimonials and case-study details.

7. Accessibility and inclusive use

Include accessibility from the beginning. State any required standard, procurement policy, customer needs or testing expectations. Consider keyboard use, colour contrast, text resizing, form labels, error messages, captions, alternative text and plain language.

The W3C Web Accessibility Initiative’s planning guidance recommends setting goals, scope and responsibilities early, then budgeting for reviews, training and testing. This reduces the risk that early design decisions create barriers that are expensive to repair later.

Automated checks are useful but cannot replace informed review and testing of real tasks. Ask the proposal to explain what will be checked, when it will be checked and who will fix issues discovered before launch.

8. Search, URLs and migration requirements

If an existing website receives useful enquiries or search traffic, include its important pages in the brief. Provide access to relevant analytics and Google Search Console if available, and note any pages, downloads or campaign addresses that must continue working.

Ask how existing URLs will be inventoried, retained or redirected. A new design should not casually remove useful service content or change every address. Also identify duplicate, outdated or legally required material that needs careful treatment.

Include practical search requirements: descriptive page titles, one clear main heading per page, indexable content, internal linking, image alternative text, an XML sitemap where appropriate and a post-launch check. DanSol’s website improvement checklist for Hobart small businesses provides a useful pre-project review.

9. Technical constraints, access and ownership

Record the current domain registrar, hosting provider, content management system, email platform, DNS manager and important third-party services. Do not place passwords in the brief. Instead, state who can provide secure access when required.

Clarify ownership before work begins. The business should understand who will own the domain, website content, design assets, source files, licences and accounts. Ask whether any software requires ongoing fees and whether the site can be moved to another provider.

Also note security and operational expectations: backups, staging, software updates, administrator accounts, multi-factor authentication, monitoring and the process for urgent support.

10. Budget, timing and responsibilities

A realistic budget range helps a provider recommend an appropriate scope. If the budget is not fixed, identify the essential outcome and ask for staged options. Comparing proposals is difficult when one includes content writing, photography and migration while another covers design and development only.

List immovable dates and the reason for each. A trade event, seasonal booking period or office relocation may matter; an arbitrary launch date may not. Include time for content approval, integration setup, testing, staff training and corrections after stakeholder review.

Name one person with authority to consolidate feedback and approve work. Record which party is responsible for copy, images, legal review, account access, data migration, product entry and testing. Delayed client inputs can affect the schedule just as much as development work.

A practical Hobart website brief example

Imagine a family-run plumbing business serving Greater Hobart. Its website works on desktop but makes emergency and planned services difficult to distinguish on mobile. Staff receive enquiries from outside the service area and cannot add completed project photos.

A concise project summary could say:

Our primary goal is to help Greater Hobart customers choose the correct service and contact us with the information needed to respond. The site must make emergency contact prominent, explain service areas, support accessible quote forms, show approved project examples and allow two trained staff members to update content. We want to retain useful service URLs and measure completed calls and forms. Existing branding will remain, while photography and page layouts need improvement.

That summary gives a designer room to solve the problem while setting clear boundaries. The full brief would add content responsibilities, integrations, budget range, timing and ownership.

How to compare proposals against the brief

Ask each provider to show how its proposal responds to the same requirements. Compare:

• what discovery and research are included;
• the number and type of page templates;
• content writing, editing and migration responsibilities;
• the treatment of forms, bookings, payments and integrations;
• accessibility and device-testing methods;
• SEO migration, redirect and launch checks;
• training, documentation, warranties and ongoing support;
• third-party licences and recurring costs;
• ownership, account control and handover deliverables;
• assumptions, exclusions and change-request process.

The cheapest total is not necessarily the smallest long-term cost. A proposal that leaves content, migration or integration work undefined can produce expensive surprises later.

Frequently asked questions

How long should a website design brief be?

For many small businesses, two to five focused pages plus supporting files are enough. A complicated store, booking platform or membership site may need a longer requirements document. Clarity matters more than length.

Do I need to choose WordPress or another platform first?

No. Explain the required outcomes, current systems, staff capability and budget. A provider should be able to recommend a suitable platform and explain the trade-offs. If a platform is mandatory, state why.

Should the brief include examples of websites I like?

Yes, when you explain the relevant quality. Identify specific strengths such as navigation, product filtering or readability. References should communicate direction, not request a copy.

Can an agency help write the brief?

Yes. Discovery workshops often turn an initial outline into a detailed scope. Before paying for discovery, confirm what deliverable you will receive and whether it can be used to compare implementation options.

Does a detailed brief guarantee a fixed price?

No. Unknown integrations, incomplete content and technical issues can still affect scope. A good brief reduces uncertainty and helps assumptions become visible, but the proposal and contract should explain how changes are handled.

Use the brief to start a better conversation

A website design brief should make priorities visible without attempting to design the solution in advance. Define the business problem, customer tasks, required functions, content responsibilities, accessibility expectations, technical constraints, ownership, budget and timing. That gives both the business and the designer a firmer basis for decisions.

When the outline is ready, share it with DanSol to discuss a practical website scope for your Hobart business. A first review can identify missing information, risks and opportunities before design work begins.

Last reviewed: 14 October 2026.