AVERANE / GOVERNMENT
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 JOURNEYOrganize around public needs rather than requiring visitors to understand the internal department structure.
EXPLORE THIS APPROACHFOLLOW THE TASK, NOT THE ORGANIZATION CHART
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.
Eligibility information, required documents, responsible content owners, and the destination of the next action.
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.
Service ownership, links, explanatory content, accessible alternatives, and the handling of unavailable destinations.
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.
Contact ownership, practical alternatives, navigation recovery, and guidance maintained by the responsible team.
GOVERNMENT / PUBLIC NEEDS INTO CLEARER EXPERIENCES
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
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.
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.
EXPLORE THE EXPERIENCE / PUBLIC SERVICE DISCOVERY
Identify common tasks with your team and organize useful entry points around the actions people want to take.
Common needs → recognizable labels → useful routes
Original planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Visitors may know the task but not the department. Discuss audience language, common requests, and how service categories relate before deciding on navigation.
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.
Some tasks touch several teams. Define how related pages connect, where ownership sits, and how shared information is kept consistent.
02 / PROCESS GUIDANCE
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.
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.
EXPLORE THE EXPERIENCE / PROCESS GUIDANCE
Present approved prerequisites, relevant documents, and instructions in a clear sequence. Avoid making visitors discover important requirements halfway through.
Requirements → preparation → starting point
Original planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Identify what visitors should understand or prepare before beginning. Clear expectations can prevent unnecessary backtracking when a process requires documents or continues elsewhere.
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.
Consider unavailable systems, unanswered questions, and tasks that require offline assistance. Agree appropriate alternatives and who maintains that guidance.
03 / DOCUMENTS & INFORMATION
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.
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.
EXPLORE THE EXPERIENCE / DOCUMENTS & INFORMATION
Identify the content types and metadata needed to distinguish documents and updates. Define how related material connects.
Content types → meaningful labels → relationships
Original planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Titles, dates, subjects, formats, and relevant context help people decide whether a document is useful. Avoid relying entirely on filenames or upload dates.
Discuss categories, search, filters, and relationships between documents and service pages. Choose features around the volume and nature of the material.
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
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.
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.
EXPLORE THE EXPERIENCE / EDITORIAL WORKFLOWS
Define the fields and reusable layouts contributors need for recurring content. Provide useful guidance within the agreed editing experience.
Content model → contributor guidance → draft
Original planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
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.
Reusable service, department, notice, and resource templates can make recurring work more manageable. Define fields around the information each type needs.
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
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.
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.
EXPLORE THE EXPERIENCE / ACCESS & USABILITY
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
Original planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Review representative journeys across agreed screen sizes and input methods. Keyboard operation, focus visibility, labels, and understandable feedback belong in the implementation discussion.
Plain-language explanations, meaningful links, and clear headings help people find their way. Multilingual content and translation responsibilities should be planned where required.
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
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.
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.
EXPLORE THE EXPERIENCE / TECHNICAL STEWARDSHIP
Discuss procurement constraints, technical requirements, review responsibilities, and any specialist approvals before confirming an approach.
Constraints → requirements → agreed scope
Original planning concept. No information is submitted and no client results are implied.
THE DETAILS BEHIND THE EXPERIENCE
Procurement, security, hosting, integrations, access, and content migration can affect delivery. Surface those conditions before choosing an implementation approach.
Domains, accounts, publishing, application maintenance, and external systems may have different owners. Document the boundaries and the route for resolving questions.
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
Give residents, businesses, visitors, and other audiences useful paths into the services and information they need.
Connect content, tools, and publishing responsibilities to the people who will use and maintain the website.
Discuss hosting responsibilities, maintenance, handover, and future improvements so the organization knows what comes next.
QUESTIONS WORTH ASKING
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.
We need to review those requirements before confirming suitability, scope, and delivery approach. The proposal should make assumptions, dependencies, and responsibilities explicit.
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.
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.
We discuss contributor roles, approval needs, and content ownership, then assess how the chosen platform can support the agreed workflow.
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
Your choices are collected here. Add context about your organization and copy the brief for a conversation with Averane.
Nothing is submitted or stored. Copy your brief before leaving this page.
DISCUSS YOUR WEBSITE