An event-creation platform for Australian Greens volunteers that writes back to CiviCRM on submit — so newer volunteers stop dropping off, and branch staff stop absorbing the overflow.
Year
2023 — 2024
Role
Product Designer Two-person team with Liz, contracted out of Thoughtworks
Client
The Australian Greens
Outcome
Ready-for-dev design package covering the full event lifecycle
01 / Problem
CiviCRM is the Greens' system of record — but it's a CRM, not an event tool.
Creating an event in Civi meant scattered forms, unclear field labels, and a workflow that required CRM familiarity most volunteers did not have. Newer volunteers stopped creating events entirely. Older ones found it took far too long. The cost fell on branch staff, who absorbed the overflow.
The events themselves also suffered — poor form design produced unappealing, incomplete event listings on the public Greens website, which hurt visibility and attendance.
02 / Approach
Don't replace Civi. Build a friendly front-end that writes back to it on submit.
Liz and I mapped every field in the Civi event data model against how volunteers actually worked. One branch officer had already built a Microsoft Form workaround for her team — that gave us real signal on which fields were essential and which could be cut.
We ran a competitive analysis across Humanitix, Facebook Events, Eventbrite, and NationBuilder, then borrowed patterns volunteers would already recognise. The key insight: the new platform didn't need to replace Civi — it could be a modern layer on top, so advanced Civi users kept their workflow while casual users got something humane.
From interviews we grouped needs into Create, Manage, Search, and built a backlog of fields to consolidate, rename, or remove. We skipped lo-fi wireframing and designed straight into a customised MUI Figma library themed for the Greens brand — giving developers a shared source of truth from day one. After a week of user testing on the mid-fi prototype, I kept a tracked backlog and iterated flow, copy, and field structure each round.
Four design principles emerged: plain language for a volunteer audience not fluent in CRM jargon · maximise content real estate by consolidating nav into one side rail · keep the flow linear and clearly labelled · make the creation form visually echo the published event page, so users can see where each field will land.
The creator form visually mirrors the published event page, so volunteers see where every field will land.
Manage view with RSVP and attendance tracking, and the mobile attendance-marking tool.
03 / Outcome
A ready-for-dev design package covering the full lifecycle.
Events list dashboard · five-step creation flow (Basic Info, Event Settings, Email Reminders, Fees and Finance, Publish) · event management dashboard with RSVP and attendance tracking · mobile attendance tool. Paid and ticketed events — a long-standing pain point — became safely accessible to volunteers with branch approval still in the loop.
On publish, data flows into Civi which posts the event to the public Greens website, ready to be shared on social. Every deliverable uses the customised MUI library, with reusable organism and template components seeded for future Greens projects.
04 / Learnings
Designing a front-end for someone else's backend is a constraint that sharpens the work.
I could not add or remove data, only reorganise how it was presented and captured — which forced every decision to be defensible against "can Civi actually accept this?" I also learned how much volunteer tooling improves when you stop treating users like administrators and start treating them like the event organisers they actually are. Plain language and a familiar visual pattern did more for adoption than any new feature would have.
What I'd do differently. Run accessibility testing as part of the core research phase rather than flagging it as untested at the end, especially given the older volunteer demographic. Push for a live publish preview in v1 rather than as a follow-up — volunteers kept asking to see what their event would look like before hitting publish, and solving that upfront would have removed a whole class of back-and-forth edits.
.png)
