GOVERNMENT
Clear direction.
Better public
experiences.
Start with the task.
Design for the person.
Public websites connect people with services, information, and the teams responsible for them. We organize those connections around recognizable needs—with thoughtful design and practical publishing workflows behind every page.
EXPLORE THE PUBLIC JOURNEY PUBLIC EXPERIENCE / CONCEPT01 — 03What do you
need to do?
01Find a service02Understand the steps03Find a documentTHE DESIGN RESPONSEFamiliar language. Useful routes.
Organize around public needs rather than requiring visitors to understand the internal department structure.
EXPLORE THIS APPROACHFOLLOW THE TASK, NOT THE ORGANIZATION CHART
Every handoff
should make sense.
Before startingAt a handoffWhen a task is unclearTHE VISITOR’S QUESTIONWhat do I need before I begin?
ORIENT → UNDERSTAND → CONTINUEBefore starting
Explain the purpose, relevant requirements, and the expected process using approved information. Make practical details visible before sending someone into a form or another service.
What we clarify together
Eligibility information, required documents, responsible content owners, and the destination of the next action.
At a handoff
Make transitions to existing portals or external services understandable. Identify the destination and explain what the public website does—and what happens in another system.
What we clarify together
Service ownership, links, explanatory content, accessible alternatives, and the handling of unavailable destinations.
When a task is unclear
Offer a useful assistance route when a visitor cannot identify the right service or complete the intended task. Avoid forcing people through a single path that cannot accommodate their situation.
What we clarify together
Contact ownership, practical alternatives, navigation recovery, and guidance maintained by the responsible team.
GOVERNMENT / PUBLIC NEEDS INTO CLEARER EXPERIENCES
Public information.
Thoughtfully connected.
A public website connects people with services, information, and the steps they need to take. Averane helps shape those needs into a clear experience—while considering the teams, systems, and responsibilities behind it.
Explore the decisions behind the experience, then collect the priorities and requirements you want to discuss with our team.
Explore all industries01 / PUBLIC SERVICE DISCOVERY
Start with the task.
Help people find their way.
People often arrive at a public website with a specific need—not an understanding of the organization behind it. Averane helps shape service navigation around recognizable tasks and useful information.
Make the structure understandable.
We consider common service requests, different audiences, and the terminology people use. Department information still has a place, but visitors should not have to learn an internal structure to find a relevant service.
- Task-led navigation and service categories
- Audience needs and useful entry points
- Consistent service descriptions and ownership
EXPLORE THE EXPERIENCE / PUBLIC SERVICE DISCOVERY
PUBLIC SERVICE DIRECTORY01By taskA recognizable need02By audienceA relevant route03By serviceA useful next stepTASKSName the need in familiar language.
Identify common tasks with your team and organize useful entry points around the actions people want to take.
Common needs → recognizable labels → useful routes
Include this topic in my briefOriginal planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Build around recognizable needs
Visitors may know the task but not the department. Discuss audience language, common requests, and how service categories relate before deciding on navigation.
Make service pages practical
A useful structure can connect service descriptions, eligibility, required information, contact details, and the next step. Exact content and requirements come from the responsible team.
Account for cross-department journeys
Some tasks touch several teams. Define how related pages connect, where ownership sits, and how shared information is kept consistent.
02 / PROCESS GUIDANCE
Explain the steps.
Reduce the uncertainty.
A service page should help someone understand what to prepare, where to go, and what follows. We connect clear instructions with the relevant systems, forms, and contact routes.
Plan the handoff as carefully as the page.
Some processes belong in specialist or existing government systems. We review the intended journey and dependencies before deciding whether the website should explain, link to, or integrate with a service.
- Approved process information and prerequisites
- Clear links to appropriate forms or systems
- Useful confirmation and contact guidance
EXPLORE THE EXPERIENCE / PROCESS GUIDANCE
GUIDED JOURNEY / CONCEPTWhat do I needbefore I start?01Prepare02Proceed03Follow upPREPARE
Explain what someone needs before starting.
Present approved prerequisites, relevant documents, and instructions in a clear sequence. Avoid making visitors discover important requirements halfway through.
Requirements → preparation → starting point
Include this topic in my briefOriginal planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Explain before asking people to act
Identify what visitors should understand or prepare before beginning. Clear expectations can prevent unnecessary backtracking when a process requires documents or continues elsewhere.
Name the handoff
Clarify whether a link opens a form, a portal, a document, or another service. The public website should make the transition understandable without suggesting it controls every downstream step.
Plan the incomplete journey
Consider unavailable systems, unanswered questions, and tasks that require offline assistance. Agree appropriate alternatives and who maintains that guidance.
03 / DOCUMENTS & INFORMATION
Make information findable.
Keep its context attached.
Documents, notices, meetings, and updates can become difficult to navigate as a website grows. We plan content types, labels, and relationships so people can find useful information and understand what they are viewing.
A file needs more than a download link.
Document titles, dates, formats, and context can help visitors make a useful choice. We discuss search, filtering, content ownership, and review needs with the organization before defining the build.
- Document and notice structure
- Useful titles, metadata, and relationships
- Search, filtering, and content review planning
EXPLORE THE EXPERIENCE / DOCUMENTS & INFORMATION
INFORMATION LIBRARY CONCEPTDOCUMENTNOTICEUPDATEOrganizeFindReviewORGANIZEUse a structure that can grow.
Identify the content types and metadata needed to distinguish documents and updates. Define how related material connects.
Content types → meaningful labels → relationships
Include this topic in my briefOriginal planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Describe the resource
Titles, dates, subjects, formats, and relevant context help people decide whether a document is useful. Avoid relying entirely on filenames or upload dates.
Plan findability as the library grows
Discuss categories, search, filters, and relationships between documents and service pages. Choose features around the volume and nature of the material.
Treat ownership as part of the structure
Identify who reviews, replaces, archives, and checks published material. Document accessibility and records requirements need an agreed review process with the organization.
04 / EDITORIAL WORKFLOWS
Give the team a clear way
to keep the public informed.
A public website may have many contributors and different approval needs. We shape content structures and editing workflows around those responsibilities so consistency does not depend on one person remembering every detail.
Match publishing controls to the organization.
Roles, reusable layouts, review steps, and handover requirements should reflect the selected platform and the people using it. We discuss practical constraints and available capabilities before promising a workflow.
- Contributor roles and publishing ownership
- Reusable service and information layouts
- Review, training, and documentation needs
EXPLORE THE EXPERIENCE / EDITORIAL WORKFLOWS
EDITORIAL WORKFLOW / CONCEPTCONTRIBUTORDraftREVIEWERApproveOWNERMaintainDRAFTMake a consistent starting point.
Define the fields and reusable layouts contributors need for recurring content. Provide useful guidance within the agreed editing experience.
Content model → contributor guidance → draft
Include this topic in my briefOriginal planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Give teams clear roles
Discuss who can draft, review, publish, and maintain shared content. Permissions should reflect actual responsibilities rather than giving every editor the same access by default.
Use patterns that support consistency
Reusable service, department, notice, and resource templates can make recurring work more manageable. Define fields around the information each type needs.
Prepare for ongoing maintenance
Agree how content is reviewed, outdated information is identified, and changes are communicated. Training should cover the real tasks your teams will perform.
05 / ACCESS & USABILITY
Different people.
A considered experience.
Public information needs to be usable across different devices, abilities, and levels of familiarity. We bring those needs into the design conversation and define the project’s accessibility requirements with your team.
Build clarity into the interaction.
Readable content, meaningful headings, keyboard operation, visible focus, and understandable feedback are considered together. Any required standards, specialist review, or formal testing must be identified and scoped for the project.
- Responsive layouts and clear content hierarchy
- Keyboard, focus, labels, and feedback
- Defined accessibility requirements and testing scope
EXPLORE THE EXPERIENCE / ACCESS & USABILITY
Informationwith direction.01Read02Navigate03RespondREAD
Make content easier to understand.
Plan a clear hierarchy, useful labels, and readable layouts. Discuss language needs, document formats, and the organization’s content requirements.
Content hierarchy → readability → relevant formats
Include this topic in my briefOriginal planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Consider different ways of navigating
Review representative journeys across agreed screen sizes and input methods. Keyboard operation, focus visibility, labels, and understandable feedback belong in the implementation discussion.
Make the words useful
Plain-language explanations, meaningful links, and clear headings help people find their way. Multilingual content and translation responsibilities should be planned where required.
Define the assessment scope
Identify applicable accessibility requirements with the organization and agree testing, specialist review, and remediation responsibilities. A visual redesign is not itself a compliance determination.
06 / TECHNICAL STEWARDSHIP
Plan the responsibilities
behind the public experience.
A website depends on the platform, service providers, integrations, and people who maintain it. We make those connections part of planning so hosting, changes, and support have clear ownership.
Keep the boundaries visible.
Procurement, information handling, security, hosting, and integration requirements need to come from the organization and be agreed before implementation. A polished interface is not a substitute for that work.
- Platform and provider responsibilities
- Integration, access, and information-handling requirements
- Migration, handover, and support planning
EXPLORE THE EXPERIENCE / TECHNICAL STEWARDSHIP
WEBSITEOWNERSHIP01RequirementsAgree the conditions02DependenciesMap the connections03HandoverDefine the ownersREQUIREMENTS
Define the conditions the work must meet.
Discuss procurement constraints, technical requirements, review responsibilities, and any specialist approvals before confirming an approach.
Constraints → requirements → agreed scope
Include this topic in my briefOriginal planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Establish requirements early
Procurement, security, hosting, integrations, access, and content migration can affect delivery. Surface those conditions before choosing an implementation approach.
Make responsibilities explicit
Domains, accounts, publishing, application maintenance, and external systems may have different owners. Document the boundaries and the route for resolving questions.
Plan a deliberate transition
Inventory relevant pages and dependencies, map agreed URL changes, and define release checks. Handover and ongoing support should have clear scope and ownership.
A CONNECTED APPROACH
The public experience matters.
So do the people maintaining it.
Design around your audiences
Give residents, businesses, visitors, and other audiences useful paths into the services and information they need.
Build around your operation
Connect content, tools, and publishing responsibilities to the people who will use and maintain the website.
Plan for what follows
Discuss hosting responsibilities, maintenance, handover, and future improvements so the organization knows what comes next.
QUESTIONS WORTH ASKING
Clarity before we begin.
Can you improve an existing public-sector website?
We can discuss a review of the current content, platform, requirements, and constraints to determine whether targeted improvements or a broader rebuild would be appropriate.
Can you meet our procurement and technical requirements?
We need to review those requirements before confirming suitability, scope, and delivery approach. The proposal should make assumptions, dependencies, and responsibilities explicit.
How are accessibility requirements handled?
We discuss the relevant requirements and agree on implementation, review, and testing responsibilities. A formal conformance claim requires appropriate evidence and cannot be assumed from the design alone.
Can the website connect to our existing service systems?
We review the systems, provider capabilities, available access, and information-handling requirements before confirming an integration approach. Some journeys may be better served by a clear link to an existing system.
Can different departments maintain their own content?
We discuss contributor roles, approval needs, and content ownership, then assess how the chosen platform can support the agreed workflow.
Do you provide hosting and ongoing support?
Hosting and support responsibilities are scoped around the platform, providers, and organizational requirements. Included activities and service arrangements need to be defined before work begins.
BRING YOUR REQUIREMENTS INTO THE CONVERSATION
Start with your priorities.
Let’s shape the experience.
Your choices are collected here. Add context about your organization and copy the brief for a conversation with Averane.
Your organization, audiences, and prioritiesNothing is submitted or stored. Copy your brief before leaving this page.
DISCUSS YOUR WEBSITEYour government website brief
Explore a topic to start shaping your brief.
Current explorationsCOPY MY BRIEFAdditional interactive examples and planning scenarios
Tasks
Audiences
Service details
TASKS
Name the need in familiar language.
Identify common tasks with your team and organize useful entry points around the actions people want to take.
Common needs → recognizable labels → useful routes
AUDIENCES
Consider who is looking for information.
Residents, businesses, visitors, and other audiences may need different routes into related information. Plan those distinctions without unnecessary duplication.
Audience context → relevant information → next step
DETAILS
Give each service a useful structure.
Use an agreed content pattern for the purpose, requirements, contact information, and next step. Define who keeps the information current.
Purpose → requirements → responsible owner
Prepare
Proceed
Follow up
PREPARE
Explain what someone needs before starting.
Present approved prerequisites, relevant documents, and instructions in a clear sequence. Avoid making visitors discover important requirements halfway through.
Requirements → preparation → starting point
PROCEED
Connect the visitor to the right system.
Clarify the destination and its purpose. Review integration possibilities and boundaries with the people responsible for the service.
Website guidance → appropriate system → agreed handoff
FOLLOW-UP
Make the next step understandable.
Explain the approved follow-up route and how someone can ask a question. Do not promise processing times or status information the service cannot support.
Expected next step → contact route → ownership
Organize
Find
Review
ORGANIZE
Use a structure that can grow.
Identify the content types and metadata needed to distinguish documents and updates. Define how related material connects.
Content types → meaningful labels → relationships
FIND
Support the way people look for information.
Discuss appropriate search and filtering against the actual content collection, including useful empty states and clear link labels.
Query or category → relevant results → document context
REVIEW
Keep ownership and currency visible.
Agree on review responsibilities and how outdated information is handled. Retention and publication requirements come from the organization’s policies.
Owner → review process → approved disposition
Draft
Approve
Maintain
DRAFT
Make a consistent starting point.
Define the fields and reusable layouts contributors need for recurring content. Provide useful guidance within the agreed editing experience.
Content model → contributor guidance → draft
APPROVE
Clarify the review responsibility.
Discuss who reviews content, what needs approval, and how the selected platform can support the process.
Roles → review requirements → publishing
MAINTAIN
Plan beyond the first publication.
Agree on ownership, review routines, training, and the route for future changes so the website remains useful after handover.
Ownership → review cadence → ongoing care
Read
Navigate
Respond
READ
Make content easier to understand.
Plan a clear hierarchy, useful labels, and readable layouts. Discuss language needs, document formats, and the organization’s content requirements.
Content hierarchy → readability → relevant formats
NAVIGATE
Make controls understandable and operable.
Consider keyboard behavior, visible focus, navigation patterns, and touch interactions alongside visual design.
Meaningful controls → focus behavior → device checks
RESPOND
Explain the result of an action.
Plan clear validation and useful feedback in the interactions included in the build. Agree on the approach to testing and review.
Action → understandable feedback → recovery route
Requirements
Dependencies
Handover
REQUIREMENTS
Define the conditions the work must meet.
Discuss procurement constraints, technical requirements, review responsibilities, and any specialist approvals before confirming an approach.
Constraints → requirements → agreed scope
DEPENDENCIES
Understand what connects to the website.
Identify external systems, provider responsibilities, and relevant access. Clarify what can be integrated and what requires a separate process.
System inventory → ownership → connection plan
HANDOVER
Leave the organization with a usable plan.
Agree on documentation, access, training, and ongoing responsibilities. Discuss how future issues and changes will be handled.
Documentation → responsible owners → support route
Familiar language. Useful routes.
Organize around public needs rather than requiring visitors to understand the internal department structure.
What do I need before I begin?
Before startingExplain the purpose, relevant requirements, and the expected process using approved information. Make practical details visible before sending someone into a form or another service.What we clarify togetherEligibility information, required documents, responsible content owners, and the destination of the next action.
At a handoffMake transitions to existing portals or external services understandable. Identify the destination and explain what the public website does—and what happens in another system.What we clarify togetherService ownership, links, explanatory content, accessible alternatives, and the handling of unavailable destinations.
When a task is unclearOffer a useful assistance route when a visitor cannot identify the right service or complete the intended task. Avoid forcing people through a single path that cannot accommodate their situation.What we clarify togetherContact ownership, practical alternatives, navigation recovery, and guidance maintained by the responsible team.
What do I needbefore I start?
Explain before asking people to act.
Give visitors the approved practical information they need before moving into the next part of a process.
A resource with context.
Use meaningful titles, dates, categories, and ownership to make public information more understandable.
Am I in the right place?
Where can I get help?
What do I need before I start?
Where do I go to proceed?
What happens after this step?