Strategy
Early intervention
Reach people sooner, before needs escalate.
Executive concept walkthrough
How might we reimagine early intervention mental health support for all Australians?
A Technology view of a community-first service: human-centred, safe, scalable and designed so people can feel informed on first view, then return when they need more depth.
Early intervention strategy
Integrated stepped care
Community-first service
HCD-led experience
Board narrative
Community need
Trusted entry
Right level of support
Human connection
Learn and improve
Model
Integrated stepped care
Offer safe support that can step up, step down or connect locally.
Enabler
Community-first technology
Use digital as infrastructure for access, trust and continuity.
01 · How might we?
Start with community need, not a digital channel.
How might we, as the Technology team, help deliver a reimagined early-intervention mental health service for all Australians?
The shift is from digital-first delivery to community-first support: technology becomes the connective tissue behind access, navigation, care, partners and learning.
From
Digital-first service design
Channels and products can lead the experience, forcing people to understand the system before the system helps them.
To
Community-first service design
Local need, lived experience and human pathways shape the service; digital makes access and continuity easier.
So that
People feel oriented quickly
The first view gives the gist. Deeper explanation is available when executives, teams or partners need it.
HCD lens: what should be obvious on first view?
Who this is for, why early support matters, what support could look like, and how a person can move safely from self-help to human or community support without starting again.
What should be available when people return?
Deeper journeys, service logic, governance controls, partner pathways, evidence of outcomes and the technology capabilities that make the experience reliable.
What role should Technology play?
Enable the service promise: trusted access, safe routing, continuity, measurement, privacy, integration and learning — without making the user experience feel technical.
02 · Community first
A national service that feels local, human and easy to enter.
Technology’s role is broader than building the web app. It enables community access, safe pathways, service quality and accountable scale.
Framing statement
Early intervention is the strategy. Community-first stepped care is the operating model.
The app demonstrates how Technology can help move from separate digital products to one connected, HCD-led service across community, human, peer and clinical support.
Role 01
Trusted community front door
Simple entry, plain language and confidence that support can continue beyond the screen.
Role 02
Pathway coordinator
Shared intake, routing, escalation and follow-up so people move safely between self-help, human support and local services.
Role 03
Trust and quality steward
Clinical safety, privacy, lived-experience input and outcome learning embedded into every change.
03 · Stepped care
One pathway, multiple levels of support.
The service model should support self-management, brief support, guided low-intensity care, telehealth, and escalation or referral — without making the person restart at every step.
Service blueprint
The operating logic behind the person journey.
A simple blueprint connects user actions, frontstage service, backstage work, support systems and governance controls.
04 · Person journey
Design from people, context and pathway.
The journeys are the centrepiece. They show how a human-centred service can be clear on first view, useful on return and safe as needs change.
Community need first
Least intensive safe response
Return, review and step up
Journey demonstration
Select a person journey.
Lead with the lived pathway. Let the service model, governance and technology reveal only when useful.
Journey persona
Select a journey
Journey summary appears here.
Pathway through the service
Each step shows how the person moves across access, assessment, matching, support and review without re-entering a fragmented system.
Designed outcome
What this proves
Journey storyboard
Three connected lenses for the same journey.
Use the storyboard to move from lived experience to operating logic and then to the enabling platform. Related architecture, governance and roadmap items are highlighted below.
Service model intersection
How the operating model shows up for the person.
The selected journey explains how shared intake, navigation, intervention and escalation work as one model.
Care framework alignment
Why the pathway fits stepped care and quality expectations.
The selected journey explains how least intensive safe support, review and step-up logic operate in practice.
Enabling technology
The platform that makes the experience feel connected.
The selected journey explains the orchestration, data and workflow capabilities needed behind the scenes.
Follow the technology storyTraceability
The selected storyboard lens highlights the platform capabilities, governance controls and roadmap moves it depends on.
05 · Operating model
Shift from channel ownership to capability ownership.
The outsource/insource decision should follow the capability model: what must the organisation own to safely operate the pathway, and what can be delivered through partners?
Operating model question
Which capabilities must be owned internally to protect trust, safety and pathway integrity?
Specialised delivery can still be internal, outsourced or partner-led. The critical distinction is whether the organisation keeps control over service definitions, pathway rules, governance, data standards, quality expectations and escalation logic.
06 · Technology backbone
Technology enables community-first care; it is not the care.
The target platform should make access, screening, routing, support, referrals, outcomes and partner connection feel coherent without making the experience feel technical.
Capability map
Reusable platform capabilities.
Journey selections highlight the capabilities required behind the scenes.
07 · Governance and assurance
A connected pathway requires connected governance.
Clinical safety, community moderation, digital design, data use, privacy, cyber, service quality and partner performance need to be governed together.
08 · Transformation pathway
Start with HCD, governance and sequencing — not just technology replacement.
The roadmap is deliberately conceptual: align on the community-first service promise, validate with people and teams, pilot safely, then scale based on evidence.
09 · Transferable value
A reusable pattern for community-first support.
The strongest asset is the pattern: make fragmented support easier to enter, safer to route, clearer to govern and better able to learn.
Reframe the proposition
Move from “digital product” to “community-first service infrastructure”.
The web app can remain visually simple while carrying a deeper service narrative underneath. In every version, people should not have to understand the system before the system can help them.
Representation modes
Four ways to package the idea.
Where else it could be useful
Alternative contexts for the same model of care pattern.
Open each card to see the fit, adaptation and web-app angle for a different audience.
10 · Discussion prompts
The question should create alignment, not pretend to be the final answer.
Use these prompts to help executives decide what Technology should enable, what must be governed, and where HCD validation is needed next.
Strategic
What community-first role are we prepared to own?
Trusted front door, pathway operator, partner connector, evaluation engine — or some combination?
Operating model
What must be internally controlled?
Model of care, risk logic, service definitions, data standards, partner assurance, community safety and outcomes are likely ownership anchors.
Technology
What platform capabilities should disappear into the service?
Intake, identity, consent, workflow, referral, analytics and governance evidence should feel like one coherent support pathway.
Source basis
Use as an internal concept artefact.
This walkthrough is based on the strategic framing paper, service catalogue, operating model notes and the current demo application repository. External references should be formalised before using the app as a published or board-pack artefact.