Website cleanup exposed an operational problem
The public website was disorganized. Behind it, the organization had no shared source of reliable operational information.
The public website had grown organically. Navigation and findability were poor, design and content forms were inconsistent, and information that should have been structured was duplicated across pages and maintained by hand.
Behind the website, member data, show staffing, upcoming events, and other operational information lived across separate Google Sheets, an Apple calendar, email lists, and other disconnected sources. Finding an answer required knowing where to look and which copy was current.
I was already deeply involved in the organization and initially volunteered to help with routine updates. Improvements to the navigation, homepage, and event data earned enough trust for me to take on the larger system.
Limit the investment in Wix
- Took over routine site updates and reworked the navigation around findability
- Improved the homepage and began structuring show data with Wix repeaters
- Wrote custom Wix server and page scripts with Codex when the native tools fell short
- Avoided deep Wix investment because migration was already the long-term direction
Start with contacts and events
Contacts and events touched nearly every other function, including membership, registration, staffing, communication, and reporting. Bringing them together created value well beyond the website redesign.
Inherited site
Structured Wix iteration
Current platform
Choose a platform the organization could sustain
A volunteer-led organization needed software that its members could afford, understand, and maintain.
Budget was a hard constraint. I evaluated nonprofit CRM and membership products including WildApricot and CiviCRM. WildApricot’s contact-based pricing would become increasingly difficult to sustain; CiviCRM offered a flexible open-source foundation.
A standalone backend and custom React frontend would have fit my own preferences. I chose CiviCRM integrated with WordPress because many people in the organization need to edit content and operate the site without specialized technical knowledge. WordPress gave them a familiar interface and a realistic ownership model.
Show the value of shared data early
- A current organizational KPI dashboard
- A member area with trusted, non-public information
- Structured event management and dedicated event pages
- CiviCRM registration replacing Eventbrite
- A WordPress frontend with distinct anonymous and authenticated experiences
Give members access to trusted information
Public visitors and logged-in members do not need access to the same information.
Both audiences can see geographic information about judges. Logged-in members can also see candidates and additional operational details that are hidden on the public site.
Event discovery supports the choices members actually make. They can browse a list or map, search by date, and filter for events with particular staffing openings. Each event listing leads directly into the staffing workflow.
Put staffing where organizers and volunteers already work
Show staffing had been a recurring coordination problem with no reliable view of demand across upcoming events.
Organizers mostly relied on people they already knew. Every few months, someone manually copied an incomplete list of openings into an email. A CiviCRM resource-staffing extension supplied part of the data model. Its interface did not work for the organization.
I first mapped what a prospective staff member needs to know before volunteering. That clarified what organizers needed to provide and led to a shared workflow embedded in each event page.
For members who want to help
- See open roles in the context of a specific event
- Express interest without navigating to a separate staffing system
- Automatically notify the organizer by email
For show organizers
- Define the target number of people needed for each role
- Add and manage staff and review interested members
- Accept or decline interest from an email link or the staffing interface
- Assign more people than the target when circumstances call for it
Keep a usable staffing history
The system stores accepted and declined requests. This creates a record for later reporting, communication, and certification work.
Learn from production use
This is a live platform. I learn what needs work by talking with users and seeing how the product performs in practice.
Users tell me when something fails, and I talk with organizers and members about the work they are trying to complete. I use that feedback to revise the product. Most complex improvements move from an identified need to production in about two weeks.
Codex lets me implement more of the work myself. I set the product and UX direction, then review and test the code it produces. Early interaction designs often looked plausible while using the wrong model. Reviewing low-fidelity wireframes first made those problems easier to catch before they became code.
What changed
- Improved findability and more consistent information
- Structured, reusable event data and dedicated event pages
- In-house event registration, integrated membership, and payments
- Role-based access to trusted information
- A usable show staffing workflow and real-time organizational dashboard
- Less dependence on disconnected spreadsheets and calendars
The platform continues to evolve
Next directions include automated notices for shows that need staff, deeper use of staffing history, easier member communication, integration with the separate entry-management system, automated show documents, and potentially more event commerce through WooCommerce.