Service & Product

Voma

Two years overhauling a workflow, then building the product to fix it.

Part 1: Service Design

Code for Chicago started as a two-hour meetup in Uptown Chicago.

The first hour was orientation and agenda-setting: brigade news, current projects, future projects. The second hour was aside time for project work. Sometimes we had a speaker.

Our early pain points were reconciling how we structured the format for new and returning members. New members learned about in-progress project tasks for the first time. Returning members heard us orient for the thousandth time. If you had a skill that didn't fit our current projects then you were left lingering for the remaining hour. No mechanisms for follow-up, checking-in, and no accountability for when members don't return on a deliverable. It was casual.

When covid happened, we transitioned the same format online. Instead of a coworking space it was a 2-hour Zoom call. The problems we had when we were in-person were exacerbated. It was more difficult to both orient and work on projects remotely. I proposed shifting to a new model which deliberately separated the orientation and project spaces.

First Iteration: the "onboarding night" model (2021)

Through Meetup via Zoom call, we facilitated a twice-monthly, one-hour onboarding night. The goal of that call was to orient participants to our process and projects. If they were interested in signing up, we provided them a Google Form link which gave us basic information like their email and their skill (e.g. Development, Design, Project Management, etc.). From there I would set up a one-on-one 30 minute "interview." The purpose of that call was to gather more info about each potential volunteer to identify best fit. Afterwards, if there was project fit and availability on a project they were assigned to the project accordingly. Otherwise they were waitlisted and welcomed to participate in our Slack channel.

Compared to our previous model, every project had their own meeting cadence. Essentially, we shifted to a digital consultancy model where each project was assigned a "lead." In the past, brigade leadership handled all client communication directly. Under this model, that responsibility was delegated to each project's designated lead and members.

When we launched the plan in 2021, I scoped it to run 6 months to evaluate its effectiveness. During this time I was gathering data on participants, attendance, and project funnel. Overall, I felt that this was an effective process. Towards the end of 2021 we increased the overall volunteer pool from 15-20 to 54 active volunteers. We also increased the number of active projects from 6 in 2020 to 10 in 2021.

The only real problem was that for a volunteer organization, this was unsustainable.

The Backend Process for Admins

The workflow for facilitating this process was manually intensive. The reason for the workflow was to execute a low-to-no-cost method for capturing data AND having a visible system for managing volunteers.

The sequence of steps looked something like this:

1. Export attendee data from Meetup
2. Manually copy into a Google Sheet tracking registered/attended/completed form/onboarded
3. Sheet fed attendance numbers reported to Code for America
4. Send Meetup message with "New Members Guide" link + Google Form
5. Export Google Form responses into a second spreadsheet (contact info, pronouns, skills, availability)
6. Manually input into Trello (one card per volunteer)
7. Copy-paste Slack message once they'd joined Slack
8. Schedule and run the one-on-one (personal checklist/agenda)
9. After the call: project-specific onboarding tasks (Trello, GitHub, Figma, done manually)
10. Update Trello with attendance/status
11. Final copy-paste Slack message confirming access, asking them to double-check nothing was missed

There were 3 pain points that I wanted to resolve as we iterated this process:

1. Time cost: There was an average of 14 hours monthly on volunteer management, that's a lot for a volunteer-led organization.
2. Funnel loss: There is likely an expected loss of participants as they graduated towards each phase: only 30% of participants actually fall through the entire process.
3. Ghosting/communication: We had team dependencies that were exacerbated by a lack of follow-through or communication, and I wondered if there was a way to either screen or nurture this in our onboarding process.

Second Iteration: the async model in 2022

As we transitioned to 2022, I proposed we shift to an asynchronous model. This iterated model mapped what worked well in the onboarding night format: orientation and project assignment based on skills. Another layer I wanted to test was capacity. From my extensive time managing volunteers in my previous career, I think a core tenet of what makes a volunteer successful is whether they can make time to complete tasks. Of course intention and goodwill are important as well, but if a participant simply doesn't have time or can't dedicate time then they cannot make a meaningful contribution.

Some volunteers overestimate their own capacity, sometimes genuinely, from real obligations like caretaking, or sometimes simply misjudging their own bandwidth. As someone managing volunteers, I couldn't tell the difference from the outside. All I'd see was the same thing either way: a lack of follow-through.

Without expanding on this further in this case study (happy to chat about it over coffee), I'll just call it for what it is: volunteerism can be a proxy for free labor. What we did at Code for Chicago could be work you'd do if you worked at a consultancy.

With that said, the new process focused on task assignment:

1. Registration link (Google Form)
2. Trello ticket auto-assigned with onboarding tasks (recorded onboarding presentation, skills-focused Google Form)
3. Assigned to a project based on that info
4. Project-specific Trello checklist
5. Explicit decision to join, via another Google Form

We all agreed some type of volunteer onboarding was important. But the 2021 model was too time intensive for me.

Part 2: Making Voma

Voma was conceived as a response to transitioning away from our manual process.

As I was mapping out the service blueprint, I identified areas where automation could occur. As opposed to paying for a service, why not create one for our brigade and the brigade network as a whole?

The Voma concept would automate all the manual touchpoints I felt was important:

1. Collect data
2. Interact with the volunteer (via Slack)
3. Move the volunteer along their onboarding process

The volunteer team for this project spanned the entire technical spectrum: Product, Design, Development and Research.

Building the Pilot (late 2021 to mid 2022)

I knew I wanted to facilitate a whole end to end design process for this project. But I wanted to test the idea at a high level first before we could commit more time to establishing a whole design system.

To start, I did a bare bones design. The goal was to test the concept so I wasn't too concerned with how the UI rendered.

As the devs worked on the initial concept, I fleshed out the UI further. For the sake of speed I used material design to ground the vision further. There were two primary tasks for the MVP:

1. Assigning and reviewing tasks
2. Assigning users to a project

As the project moved further along, I leveraged material design as a placeholder design system on purpose.

Real Validation, Real Momentum (June to September 2022)

Around June 2022, we presented to Code for America Brigade leadership on potentially leveraging Voma and got initial buy-in. We got the initial MVP done around August 2022.

During this time I felt it was important for us to have documentation about user personas, along with some usability testing. I defined the research questions we needed answered for both volunteer and admin user groups:

1. Could users navigate Voma's information architecture intuitively?
2. Did the verbiage feel familiar?
3. Did they trust Voma to onboard volunteers efficiently?
4. Did they understand the different volunteer designations?
5. Did they have enough project information to make onboarding decisions?
6. Did the value proposition come through clearly?

I directed the research team to run the study against them with 8 participants unrelated to the brigade. Their synthesis directly shaped what made it into Voma 1.0's scope.

As we got the initial sign-off, another volunteer and I began conceiving Voma's brand and building the components that became our baseline for the design system.

Project Departure (March to May 2023)

As we were nearing completion of Voma 2.0, towards the end of 2022 into 2023, I had to make the difficult decision to leave the brigade. Coincidentally (and I swear I made this decision before CfA said anything), Code for America made the decision to sunset the brigade system. This meant the project would exist only for us, without the support we'd had from CfA.

I gave notice 7 weeks in advance. I used the final sprint to leave a documented handoff, which included additional features I designed:

1. Active status
2. New admins
3. The volunteer modal

Part 3: Features & Repository

2 years later, Voma 2.0 continued on without me.

Before I left, I created prototypes to showcase interaction for every task we planned for 2.0. Years later as I reconnected with volunteers, I learned Voma 2.0 did continue mostly as a development project as you can see in the repo. There were commits until July 2024.

As I mentioned previously, since the brigade system sunsetted, the project became a labor of love and I'm proud of all the work we put into it.

Volunteer Onboarding

Voma consolidated the beginning part of the volunteer onboarding workflow: users registered by signing into their Slack account, then completed the surface level form fields to get started. Once they were in Voma, in lieu of going back and forth with someone like me, they chatted with a bot that had automated conditional responses based on their input. The beginning portion of their onboarding was completing tasks like watching videos or introducing themselves in the #intro channel.

As I'm watching this years later in retrospect, I wonder: if we had implemented this, how would a user navigate the system if they were truly lost? What use cases would this look like? Would we designate an actual human to facilitate this? How would this change with the advent of AI (remember this was years ago)? These are questions I'd want to explore and examine more closely once we had real data from actual use.

Assigning a Volunteer to a Project

The other core part of this MVP was the actual volunteer assignment. You'll see that once a volunteer user completes their onboarding and requisite information we need to assign them, Voma would identify a best fit. Usually when a human was doing this (me), my criteria for project assignment were availability and skill fit. If we wanted to scale this further we could ask for seniority, physical location, and actual capacity.

Again, as I'm rewatching this recording in retrospect, I'm wondering if there was a level of judgement that was truly gray. If we implemented this, was it possible we flagged people who had skills but were too critical in their self-assessment? It is true that when this was a manual process, people did select (not often) multiple skill areas, but in talking with them I found out what they truly wanted. This was, for sure, a trade-off from transitioning to this automated process that relies on participants either being truthful or making accurate self-assessments. These are also questions I'd want to explore and examine more closely once we had real data from actual use.

Reflection

The volunteer management model turned out to be an extension of my experience in managing volunteers.

I've been volunteering since I was 18. Volunteering led me to actual jobs. Being in it for a while I've developed a little cynicism. Yes, volunteering is a great way for your altruism to shine. It also fortunately/unfortunately fills an experience gap for juniors where an internship or apprenticeship should take place. I don't think an intention to volunteer that isn't wholly altruistic is inherently wrong. So long as you show up and make a meaningful contribution, I think that's all that really matters. In the end, volunteering AND managing volunteers is work.

While I enjoyed my time in the brigade system, based on the data and my experience, it felt like a space for people to transition to a tech job. Of course this included people like me who transitioned from crisis management as I was wrapping up grad school. It was truly a joy to connect with people more senior than me, and provide opportunity to mentor others as I gained my experience. This exchange is so valuable and the people I've met through the brigade have become friends since.

When we transitioned to remote, we expanded the volunteer pool beyond Chicago. In chatting with others who had their own local brigade but preferred to volunteer with us, I would hear that having a system for managing volunteers and assigning them to projects was appealing. These anecdotes provided some confidence in our decision to move away from the once-a-week format we had initially.

Voma was a culmination of the work I've done professionally up to this point. It truly felt like we lived the mantra the brigade system intended: when like-minded well-intentioned people get together to achieve a goal, amazing good can be done in the world.