Skip to content
Avenier GroupStart a Conversation
Avenier Lab
Fictional City of Briarfield, a Blue Ridge mountain town with a civic tower and mill pond at dusk, used for an independent Avenier Lab municipal concept study.

Avenier Lab / Municipal Concept Study

City of Briarfield

What if one resident request could stay connected from first report to final resolution?

A concept study exploring how direction, digital services, operational software, and communication could work together around one municipal service experience.

Independent concept study · Fictional municipality

PracticesTechnology DirectionWebsite DevelopmentCustom Software DevelopmentCommunications Design

Explore the study

CIV-2047 · Cedar Walk

  1. Resident need
  2. Place
  3. Work
  4. People
  5. Communication
  6. Resolution
  1. Resident need
  2. Connected city work
  3. Resolution

The situation

One damaged sidewalk. One resident trying to get help.

A resident sees a damaged sidewalk creating an accessibility concern at Cedar Walk at Harbor Lane, west of the Mill Pond Library crossing. Inside the city, the same request could belong to streets, public works, accessibility, or parks. This concept follows request CIV-2047 end to end.

  1. Where do I start?

    A broken sidewalk might involve streets, public works, accessibility, parks, or another department. Residents should not need to understand the city’s organizational chart before asking for help.

  2. How do I identify the location?

    A street address may not be enough. Residents need a way to identify a landmark, map point, crossing, or nearby public place.

  3. What happens after I report it?

    Submitting a form should not end the experience. Residents need understandable confirmation, status information, and closure.

Behind the concept

A concept is a starting point.Validation shapes what gets built.

Briarfield is fictional. The interfaces and workflows below demonstrate how Avenier might approach a municipal technology environment — not assumptions we would carry directly into a real engagement.

  1. 01AssumeCreate a plausible starting point.
  2. 02ValidateLearn how people, processes, and systems actually work.
  3. 03AdaptChange the direction based on what we learn.

The connected idea

One request, followed through every practice.

This is not four unrelated services. They are four views of one organizational challenge, followed here through request CIV-2047.

  1. CIV-2047Close view of the fictional City of Briarfield service blueprint connecting the resident path, city workflow, website, software, field work, print, and support.01Technology direction
  2. CIV-2047City of Briarfield municipal website homepage with service search, resident actions, service advisory and popular city services02Resident website
  3. CIV-2047Briarfield Connect service-request software concept on a desktop monitor and phone, showing request CIV-2047 with a map and update history.03Briarfield Connect
  4. CIV-2047Briarfield communication system for the Cedar Walk improvements: a project notice, wayfinding sign, service-update sign, resident guide, brochure, open-house flyer, banner, letterhead, and staff materials, all in one visual language.04Communications Design

01— TECHNOLOGY DIRECTION

See what you have. Understand what connects. Decide what comes next.

We map the systems, dependencies, constraints, and opportunities shaping the organization—then turn them into priorities and a practical technology roadmap.

Leadership team reviewing a technology environment and roadmap during a planning session.

City of Briarfield

Technology Direction Map

Independent concept study · illustrative examples

  1. 01Current environment
  2. 02Pressures & gaps
  3. 03Direction decisions
  4. 04Priorities
  5. 05Roadmap

01 · UnderstandCurrent environment

02 · EvaluatePressures & gaps

03 · DecideDirection decisions

Working assumptions · concept study

  • Public websiteCitizen information, forms, accessibility
  • Internal applicationsDepartment workflows and operational tools
  • Data & reportingDepartment data, reporting, exports
  • Infrastructure / cloudHosting, identity, storage, network dependencies
  • CybersecurityAccess, backups, security practices
  • CommunicationsEmail, public notices, alerts, digital communications
  • Support & vendorsExternal providers, contracts, internal ownership
  • Accessibility remediation already planned
  • Do we actually need to replace this?
  • No internal system owner
  • Duplicate entry between applications and reporting
  • Two departments depend on this
  • FY27 budget cycle
  • Security review required
  • Keep
    Existing finance platformStable, supported, and meeting current needs.Internal applications
    No change recommended.
  • ImprovePriority 01
    Public websiteAccessibility, governance, and maintainabilityPublic website
  • ConnectPriority 02
    Service requests + reportingReduce duplicate entry and improve visibilityInternal applications · Data & reporting
  • ReplacePriority 03
    Legacy internal workflowHigh maintenance and limited visibilityInternal applications
  • ExplorePriority 04
    Shared data layerValidate value before investingData & reporting · Infrastructure
    Not yet.

Not everythingneeds to be replaced.

SequencePriorities

  1. 01ImprovePublic website
  2. 02ConnectService requests + reporting
  3. 03ReplaceLegacy internal workflow
  4. 04ExploreShared data layer
  5. —KeepExisting finance platform
Priority 01
Near-term
Priority 02–03
Sequenced next
Priority 04
Validate before investing
Unnumbered
Maintain / monitor

RoadmapIllustrative horizons

  1. Now0–3 monthsStabilize
    • Document current environment
    • Resolve immediate risks
    • Confirm ownership
  2. Next3–9 monthsModernize what matters
    • Website modernization01
    • Accessibility improvements01
    • Priority integrations02
  3. Later9–18 monthsImprove the core
    • Internal workflow modernization03
    • Data/reporting improvements
    • Selective automation
  4. Future18+ months / revisitStay adaptable
    • Evaluate shared data layer04
    • Revisit architecture
    • Adjust roadmap as conditions change

Direction, not a rigid plan: revisit as needs, budgets, and technology change.

City of Briarfield · Technology Direction Map · Independent concept study · illustrative examples

01 Current environment

  • Public websiteCitizen information, forms, accessibility
  • Internal applicationsDepartment workflows and operational tools
  • Data & reportingDepartment data, reporting, exports
  • Infrastructure / cloudHosting, identity, storage, network dependencies
  • CybersecurityAccess, backups, security practices
  • CommunicationsEmail, public notices, alerts, digital communications
  • Support & vendorsExternal providers, contracts, internal ownership

02 Pressures & dependencies

  • Website forms feed the service requests handled in internal applications.
  • Reporting depends on what internal applications record.
  • Hosting and identity sit underneath internal applications.
  • Security practices depend on the infrastructure beneath them.
  • A shared data layer would build on reporting. Its value is still to be validated.
  • Accessibility remediation already planned
  • Do we actually need to replace this?
  • No internal system owner
  • Duplicate entry between applications and reporting
  • Two departments depend on this
  • FY27 budget cycle
  • Security review required

Working assumptions · concept study

03 Direction decisions

  • Keep
    Existing finance platformStable, supported, and meeting current needs.Internal applications
    No change recommended.
  • ImprovePriority 01
    Public websiteAccessibility, governance, and maintainabilityPublic website
  • ConnectPriority 02
    Service requests + reportingReduce duplicate entry and improve visibilityInternal applications · Data & reporting
  • ReplacePriority 03
    Legacy internal workflowHigh maintenance and limited visibilityInternal applications
  • ExplorePriority 04
    Shared data layerValidate value before investingData & reporting · Infrastructure
    Not yet.

Not everything needs to be replaced.

04 Priorities

  1. 01ImprovePublic website
  2. 02ConnectService requests + reporting
  3. 03ReplaceLegacy internal workflow
  4. 04ExploreShared data layer
  5. —KeepExisting finance platform
Priority 01
Near-term
Priority 02–03
Sequenced next
Priority 04
Validate before investing
Unnumbered
Maintain / monitor

05 Roadmap

Illustrative horizons

  1. Now0–3 monthsStabilize
    • Document current environment
    • Resolve immediate risks
    • Confirm ownership
  2. Next3–9 monthsModernize what matters
    • Website modernization01
    • Accessibility improvements01
    • Priority integrations02
  3. Later9–18 monthsImprove the core
    • Internal workflow modernization03
    • Data/reporting improvements
    • Selective automation
  4. Future18+ months / revisitStay adaptable
    • Evaluate shared data layer04
    • Revisit architecture
    • Adjust roadmap as conditions change

Direction, not a rigid plan: revisit as needs, budgets, and technology change.

How Avenier thinks

Understand before recommending.

Useful direction starts with understanding the organization around the technology, not just the technology itself.

  1. 01UnderstandWhat exists today?
    • Technology
    • People
    • Process
    • Dependencies
    See the environment as a connected system: how work moves, what teams rely on, and where technology supports or complicates it.
  2. 02TestWhat shapes what’s possible?
    • Constraints
    • Readiness
    • Risk
    • Capacity
    Test possible changes against organizational reality before deciding what deserves investment.
  3. 03DirectWhat paths make sense?
    • Improve
    • Connect
    • Replace
    • Explore
    • Keep
    Turn that understanding into a small set of plausible paths leadership can evaluate and sequence.Informs the direction map

Possible outputs Current-state map · Decision framework · Priority roadmap

From direction to experience

We understand the direction.Now let’s see what that direction could become.

02— WEBSITE DEVELOPMENT

A resident experience built around getting things done.

Residents think in needs, places, and outcomes — not departments.

A municipal website should help people start with what they need to accomplish, then guide them to the right service.

City of Briarfield municipal website homepage with service search, resident actions, service advisory and popular city services
City of
Briarfield

My Requests

CIV-2047

Damaged sidewalk

Mill Pond Library

In progress

City of Briarfield request photo: a raised, damaged sidewalk panel.

Latest update

Site inspection scheduled

Apr 15, 2025, 2:14 PM

View full history

  1. Find
  2. Inform
  3. Follow

CIV-2047Resident journey

The question

Should residents need to understand city departments before they can ask for help?

The direction

Organize around what residents are trying to accomplish — not the municipal org chart.

The experience

  1. 01 — Find

    Start with the need, not the department.

    Residents shouldn’t need to understand the organizational chart to get help.

    • Plain-language services
    • Location-aware guidance
  2. 02 — Understand

    Know what’s needed before submitting.

    Clear requirements reduce incomplete requests and unnecessary back-and-forth.

    • Eligibility & requirements
    • Accessible, mobile-first forms
  3. 03 — Follow

    See what happens after submit.

    Status, expectations, and updates make government services feel less opaque.

    • Visible status
    • Next-step expectations

Possible outputs Information architecture · Accessible experience · Production website

03 — CUSTOM SOFTWARE DEVELOPMENT

How Avenier thinks / Software development

Software should follow the work.

We start with the people doing the work, understand how information and responsibility move, and design the system around that reality — not the other way around.

  1. 01Understand the work
  2. 02Connect the record
  3. 03Design for reality
  4. 04Adapt over time

01Understand the work

One request. One connected operational record.

The problem

Requests move between teams.Context often doesn’t.

Information can fragment across email, spreadsheets, departments, and disconnected systems as responsibility changes.

The principle

Move ownership —not the record.

Keep the request, history, responsibility, status, and next action connected as work moves across the organization.

02Connect the record

Request lifecycle CIV-2047

Staff workspaceFull operational context.

CIV-2047

Damaged sidewalk creating an accessibility concern

Cedar Walk at Harbor Lane · North curb · panel 14

StatusReceived
OwnerResident Services · Intake
Next actionThe request moves to the team that can assess it.
HandoffReady to route by service need, not by a department the resident chose.
Activity history
  1. ReceivedResident Services. Resident Services receives the report and keeps the wording intact.
Related information
Field
Not yet assigned to a crew.
Record
CIV-2047, unchanged
City of Briarfield · FieldCIV-2047Not yet assigned to a crew.

The request moves to the team that can assess it.

Field viewSame record. Only what’s needed here.

The record stays intactas responsibility moves.

Ownership can change without forcing the next person or team to reconstruct what already happened.

Explore Briarfield Connect

The next question

But what happenswhen the expected path changes?

03Design for reality

Beyond the happy path

Real operationsaren’t always linear.

The system has to keep context intact when the expected path changes.

01 Exception

What happens when the request doesn’t fit the normal path?

Preserve the original context while allowing staff to clarify, reroute, or escalate without blocking access to help.

02 Handoff

What happens when responsibility changes?

Move ownership without moving the record, or forcing the next team to reconstruct what already happened.

03 Ongoing support

What happens after launch?

Maintain the system as workflows, policies, accessibility requirements, integrations, and organizational needs change.

Design for what happensbetween the steps —not only the happy path.

Useful software has to account for exceptions, handoffs, changing responsibilities, and what happens after launch.

Different responsibilitiesdon’t require differentsources of truth.

04Adapt over time

The software principle

One systemis notOne interface

One source of truth.Different views for different responsibilities.

Staff, field teams, leadership, and residents don’t need the same interface. They need the same information to remain connected.

Shared record / purpose-built views

  1. Resident
  2. Staff
  3. Field team
  4. Leadership

How Avenier thinks

Understand the work.Preserve the context.Build around reality.

  1. People
  2. Organization
  3. Process
  4. Technology

Technology comes last for a reason. The system should reflect how people, responsibilities, decisions, and information actually move through the organization.

Possible outputs Workflow model · Connected application · Operational system

04 — COMMUNICATIONS DESIGN

Clear communication beyond the interface.

A service doesn’t stop at the screen. We carry its language and priorities across notices, signs, guides, events, staff communications, and other real-world touchpoints — so each moment feels connected to the same service.

Avenier Lab · Independent concept study

How Avenier thinks / Communications design

01 — Establish the message

Same information.

Avenier identifies what people need to know and what action the communication needs to support.

02 — Design for the moment

Different context.

We adapt the hierarchy, format, and level of detail to where and how people encounter it.

03 — Keep the path clear

One clear next step.

Across notices, signs, guides, events, and digital touchpoints, the next action stays easy to understand.

Communication system / Cedar Walk

One service expressed across the moments surrounding it.

Briarfield communication system for the Cedar Walk improvements: a project notice, wayfinding sign, service-update sign, resident guide, brochure, open-house flyer, banner, letterhead, and staff materials, all in one visual language.
  1. 01 — Public informationWhat is changing?
  2. 02 — WayfindingWhere do I go?
  3. 03 — Service materialsWhat do I need to know?
  4. 04 — Organizational touchpointsWho is communicating with me?

The outcome

The goal is less friction.

Different formats, one coherent path from information to action.

Possible outputs Communication system · Production-ready materials · Real-world touchpoints

One connected service

One request.One status.Every channel.

CIV-2047
  • Resident websiteCIV-2047Field work scheduled
  • Briarfield ConnectCIV-2047Field work scheduled
  • Field communicationCIV-2047Field work scheduled
  • Resident communicationCIV-2047Field work scheduled

Request CIV-2047 shown as "Field work scheduled" on the resident website, in Briarfield Connect, in field communication, and in resident communication: one record and one status, seen through four channels.

Website Prototype ↗Briarfield Connect ↗

Behind the concept / Validation notes

What the concept assumes.What we’d need to learn.

The study gives us plausible directions to explore. A real engagement would test those ideas against the people, processes, systems, and constraints already in place.

Avenier Lab

Validation notes / City of Briarfield

Independent concept studyMunicipal technology

01 — Service discovery

Assumption

Residents can begin with a shared service entry point.

Validation questions

  • How do residents actually find and request services today?
  • Where do requests actually enter the organization?
  • What channels are most important to residents?

Design implicationResident need ≠ internal workflow

02 — Shared record

Assumption

CIV-2047 can move between departments as one connected service record.

Validation questions

  • Which systems are authoritative today?
  • Where is information re-entered?
  • When does ownership actually change?
  • Which integrations would be required?

Design implicationExisting systems matter

03 — Shared language

Assumption

A common service-status vocabulary can work across resident and staff touchpoints.

Validation questions

  • What terminology do staff use today?
  • What do residents actually need to know about status?
  • Where do department vocabularies differ?
  • What language needs to remain specific to a particular service?

04 — Field experience

Assumption

Field staff can use a reduced view of the same underlying record.

Validation questions

  • What information do field teams actually need?
  • What can safely be omitted?
  • What accessibility requirements apply?
  • What connectivity conditions exist in the field?
  • What security, privacy, records, and audit requirements affect the experience?

Design implicationAccessibility is a requirement

What we’d measure

Time to route · Duplicate entry · Handoffs · Resident follow-up · Accessibility failures · Resolution visibility

The concept gives us somewhere to start.Discovery tells us where to go.

AssumeValidateAdapt

City of Briarfield is fictional. This independent concept study demonstrates Avenier’s approach and does not represent commissioned client work or validated municipal requirements.

Your organization won’t look like Briarfield.

That’s the point.

We start by understanding how your people, processes, communications, and technology actually work — then determine what deserves to change.

Start a conversation See how an engagement begins