How to choose a government website partner in Australia

Choosing a partner for a government website is a bigger decision than it looks on a procurement form. The firm you appoint decides whether people can find and finish what they came to do, whether the site stands up to an accessibility review, and whether your own team can keep it current once the project ends.

This guide is for Australian government and public sector teams getting ready to brief, shortlist or appoint that partner. It covers the kinds of firms you'll meet, what makes government work different, how to compare proposals, and the questions and red flags worth knowing before you decide.

Most guides tell you to judge partners on their platform and their portfolio. Those things matter. But what decides whether a government site works is simpler: does your partner find out what your users need, design for it, and prove it works before launch? That's where this guide puts most of its weight.

Key takeaways

• Judge partners on how they'll learn about your users and test with them, as well as what they'll build on.
• Bringing in a specialist human-centred design partner early gives the build a clearer brief and fewer surprises.
• Commonwealth services now sit under the DTA's Digital Experience Policy, which expects regular usability testing with real people alongside automated checks.
• WCAG 2.2 AA is fast becoming the minimum for accessibility. It's cheaper to design it in than to fix it later.
• Templates, AI tools and stakeholder assumptions all speed up delivery. Ask who checks them against real users.
• The cheapest proposal is often the one with research, testing or content migration taken out.

Who builds government websites in Australia

Most proposals you receive will come from one of three kinds of firm. Knowing which one you're reading makes them much easier to compare.

Large systems integrators deliver websites as part of bigger technology and transformation programs. They bring scale and managed infrastructure, and they suit multi-year federal programs with budgets to match.

Platform specialists work inside one content management system and the whole-of-government setup around it. They know that platform and its hosting rules inside out, and they're a good fit when the platform decision has already been made.

Full-service web agencies design and build, usually across a few platforms, and many offer ongoing support. The good ones become long-term partners.

All three are judged mostly on what they build and what they build it on. Design is part of most offers, but it tends to start from the platform's templates and component library, so the technology quietly shapes the experience.

Bringing in a human-centred design partner early

That's why many government teams, and many of the agencies building for them, bring in a specialist human-centred design consultancy at the start. It's a common way to run these projects, and it makes the rest of the project easier.

The design partner does the thinking that has to come first. We find out how people actually use the service, where they get stuck and what they need to get done. Then we turn that into an experience strategy, designs tested with real users, and clear outcomes for the build. The build team gets a brief grounded in what real people do, so fewer surprises turn up halfway through and fewer fixes are needed after launch.

It doesn't mean managing another vendor. Behavjor regularly partners with development agencies of every size, from small specialist studios to the largest integrators. We've worked across the platforms government relies on, including GovCMS (Drupal), Umbraco, Kentico and SharePoint. With large corporate clients we also work alongside teams on enterprise platforms such as Adobe Experience Manager and Sitecore. Where a project calls for something lighter, such as a fast, easy-to-edit content site or a commerce build, we also work in WordPress, Webflow and Shopify. We have our own development team, so we know how build teams work and what they need from design. We fit in wherever helps most:

• alongside your chosen agency
• inside your own digital and project teams, as their experience design lead
• as the single partner for a focused site we design and build ourselves

Whichever way it runs, the technology choice follows the evidence. An AI mock-up or a design system tied to a platform will give you screens quickly. It can't tell you which screens your users need.

What makes government websites different

Everyone has to use them. If a bank's website frustrates you, you can change banks. If you can't work out how to renew a licence or whether you're eligible for support, there's nowhere else to go. Government sites have to work for people of every age and ability, on whatever device they have, including an old phone on a patchy connection.

Accessibility is an obligation. The Australian Human Rights Commission's April 2025 guidelines under the Disability Discrimination Act point to WCAG 2.2 AA as the minimum, and they apply well beyond websites, to apps and AI-driven services too. Many tenders still specify WCAG 2.1 AA, so check what yours asks for.

Policy now expects real user testing. For Commonwealth agencies, the Digital Experience Policy took effect on 1 January 2025 with four standards covering service, inclusion, access and performance. Existing services were due to meet the Digital Service Standard by 1 July 2025 and the Digital Inclusion Standard by 1 January 2026, with compliance reporting for services above 50,000 visits or transactions a year. The DTA's checklist asks for regular usability testing with people of different abilities, ages and cultural backgrounds, and for automated accessibility testing alongside testing with real people. Plenty of proposals still don't price that in.

Content teams are small. One or two people often look after hundreds of pages. If every change needs a developer, the site falls out of date fast.

Accountability is public. A broken form or a confusing eligibility page can turn into complaints, a ministerial brief or a news story.

Decisions take time. Stakeholder consultation, approval gates, security reviews and procurement rules all add weeks that commercial projects don't have. A good plan includes them from day one.

How to evaluate a government website partner

Public sector experience you can check

Ask for named government clients and work you can see or verify. Vague claims of government experience deserve a raised eyebrow. Ask for a reference you can actually call.

Look for experience close to your own situation. A national health information service, a major transport project and a central policy agency all serve the public, but their users and approval chains are very different. Behavjor's public sector work includes the Digital Transformation Agency, Healthdirect and Sydney Metro. If you'd like to know more about that work, get in touch and we'll happily talk it through.

How they'll learn about your users

This is the criterion we'd give the most weight. Ask what research they'll do in discovery, who they'll speak to, and how they'll reach people who are usually missed: older people, people with disability, people with limited English, people in regional areas. Ask how what they learn will change the design.

A strong answer names methods, numbers of participants and a plan. A weak answer offers personas and a stakeholder workshop and moves straight to design.

How they'll test before launch

Ask how and when they'll test with real users: navigation tests before design, usability testing on prototypes, and testing with assistive technology before go-live. Ask what happens when testing shows something isn't working. If there's no time or budget in the plan to act on findings, the testing is for show.

Accessibility from the start

Ask who owns accessibility on their team, how they test with screen readers and keyboard-only users, and whether they'll design to WCAG 2.2 AA. If accessibility appears in the proposal only as a final audit, expect to pay for fixes later.

How they handle shortcuts and assumptions

Every project uses shortcuts. Templates, component libraries, AI tools and stakeholder opinions all save time, and all of them carry assumptions about who your users are and how they behave. That's fine if someone checks those assumptions against real people.

AI is the newest of these shortcuts. Federal guidance allows public generative AI tools for everyday work with OFFICIAL information, with clear limits: no sensitive or personal information goes in, outputs must be checked, and people stay accountable for the result. That guidance also counts contractors and consultants as staff. So ask any partner where they use AI and who checks what it produces. One reason to ask: WebAIM's 2026 review of the top million home pages found detectable WCAG failures on 95.9% of them, up from 94.8% the year before, and named AI-assisted coding as a likely contributor.

An editing experience your team can use

Your team will run this site long after the partner moves on. Ask how they'll design the editing experience, what training they'll provide, and whether they'll test the editing tools with the people who'll actually use them.

Platform advice that follows the evidence

Platform matters, especially for hosting and security. It works best when it's chosen once the outcomes are known. A partner who recommends the same platform for every client is selling what they know. Ask why they're recommending a platform for you, what it means for your editors and your security review, and what they'd do if your agency required something else.

Delivery that fits government

Look for phases procurement can approve, discovery that brings your stakeholders in early, and documents that still make sense when they're forwarded to an executive. Ask how they handle change requests halfway through a project. That answer often tells you more than their case studies.

A way to show it worked

Government briefs often leave the success measure blank. Ask how the partner will set a baseline before work starts and show the improvement after launch. Task success measured with real users is far more convincing than a satisfaction score from internal staff.

Health, transport and policy websites

Some parts of government bring their own pressures.

Health information carries clinical risk. Content has to be accurate and signed off by the right people, and the person reading it may be unwell, worried or caring for someone else. Plain language is part of keeping people safe.

Transport and infrastructure sites deal with change and disruption. People want to know what's different, how it affects their trip today and what to do instead, often on a phone while they're on the move. Information has to stay accurate as plans shift.

Central policy and whole-of-government work sets patterns other agencies follow, so mistakes spread. It relies on standards and governance as much as on page design.

Questions to ask before you shortlist

• Which public sector clients can you name, and can we speak to one of them?
• Who's leading the experience design, and how will they work with the build team?
• What research will you do in discovery, and how will you include people who are usually left out?
• When will you test with real users, and how will findings change the design?
• Who on your team owns accessibility, and how do you test with assistive technology?
• Where will you use templates or AI tools, and who checks the results?
• Why are you recommending this platform for us?
• Who will actually do the work, and how senior are they?
• How will we know, after launch, that the new site works better?

Red flags

• No named public sector clients you can check.
• Design that starts from the platform's templates rather than from your users.
• Accessibility listed only as a final audit.
• "User research" that turns out to be a workshop with your own managers.
• No time in the plan to act on testing results.
• The same platform recommended for every client.
• The lowest bid. Cheap proposals usually drop research, testing or content migration, which are the parts that decide whether the project succeeds.
• Senior people at the pitch, junior people on the job.

How we work on government projects

Behavjor is a behaviour-led design and research consultancy in Sydney, with 25 years of experience behind it. A principal leads every project. We start by finding out how people actually use a service and setting a baseline we can measure against. We design with those people in mind and test with them, including people with disability and people who rarely get asked. Then we hand the build team a brief they can deliver with confidence, and we stay involved through build and launch so the experience holds up.

We work as the experience lead alongside your development agency or your own team, or design and build focused sites ourselves. We use modern tools, AI included, wherever they make us faster. Decisions about what your users need are based on evidence from real people.

Frequently asked questions

Which accessibility standard applies to Australian government websites?

Commonwealth services under the Digital Experience Policy must meet the latest version of WCAG. The Australian Human Rights Commission's 2025 guidelines point to WCAG 2.2 AA as the minimum. Some tenders still cite WCAG 2.1 AA, so check what your agency requires, and design to 2.2 AA where you can.

Do we need user research if we're only moving to a new platform?

A platform move is the cheapest time to fix what's broken, because templates are being rebuilt and content is being moved anyway. Even a small round of research and a usability baseline will show you what to fix first and give you a result to report after launch.

Can government suppliers use AI to build websites?

Federal guidance allows public generative AI tools for everyday work with OFFICIAL information, and it applies to contractors as well as employees. Sensitive and personal information must stay out, outputs must be checked, and people remain accountable. Your agency may have its own rules, so ask your partner how they comply.

How long does a government website project take?

Longer than the build alone suggests. Stakeholder sign-off and content migration often take more time in government than teams plan for. A good partner builds them into the plan from the start.

Do the same rules apply to councils and publicly funded organisations?

The Digital Experience Policy covers Commonwealth agencies. States and councils have their own standards, and the Disability Discrimination Act applies to public-facing services in every sector. If you're publicly funded, plan for the same accessibility standard.

Planning a government website?

If you're working through a brief or comparing proposals, we're happy to talk it through.

‍

References

Australian Human Rights Commission, New guidelines to help providers of digital tech meet accessibility obligations, April 2025. humanrights.gov.au

Deque, Three major accessibility updates in Australia, and what they mean for your organization in 2026. www.deque.com

Digital Transformation Agency, Updates to the Digital Experience Policy and suite of standards, 16 December 2025. www.dta.gov.au

Digital Transformation Agency, DX policy checklist: existing services, June 2025. www.digital.gov.au

Digital Transformation Agency, DTA releases new guidance on Australian Government use of public generative AI tools, 13 October 2025. www.dta.gov.au

King & Wood Mallesons, Not sensitive? Less caution in new policies and guidance on public Gen AI use in Government. www.mallesons.com

WebAIM, The WebAIM Million: the 2026 report on the accessibility of the top 1,000,000 home pages. webaim.org

Photo by Vitaly Gariev on Unsplash.