CiviVolunteer
Recruitment Appeals
Project completed while on staff at Ginkgo Street Labs.For many nonprofits, volunteers are absolutely vital, and their contributions keep the mission moving forward. CiviVolunteer, an extension for CiviCRM created and largely maintained by Ginkgo Street Labs, provides non-profit organizations tools for signing up, managing and tracking volunteers.
Identifying the pain points
In early versions of CiviVolunteer, volunteer sign up was accomplished by scheduling a volunteer to a shift called a "Need", which were associated with a volunteer "Project". A primary pain point that our clients identified was the desire for improved searching and matching capabilities in the system. We had initially thought to simply overhaul the data model to support this goal.
With a desire to ensure this approach had validity we engaged with the client to learn more about how their users were using CiviVolunteer, and what their goals were. Through a series of client interviews led by our team's Solution Architect, we learned that users were were leveraging Projects in unexpected ways, and with less than satisfactory results. Volunteer Projects were originally conceptualized to be a thin entity supported by Needs, which was essentially a block of time with a task and volunteer signed to it. The assumption had been that the potential volunteer would already have the information they required to make a decision to volunteer, and all that was needed was to sign them up for a shift. The process of a potential volunteer discovering the opportunity, obtaining relevant information, and being persuaded to commit to volunteering was never part of the design. And yet, we learned, it was apparent that this was the user's expectation of how the system should work.
Additionally, since the system was primarily based around scheduling a volunteer to a Need, opportunities that might be ongoing in nature or not reliant on the volunteer being at a specific location, were difficult for administers to manage and for potential volunteers to discover and sign up for. We also discovered that many users weren't interested in using the Needs feature to schedule or track volunteer hours, their primary motivation for posting opportunities was to entice new volunteers and keep existing volunteers interested with new volunteer opportunities.
Of course...
...the requirements of speedier searching and more accurate matching were still relevant.
The Recruitment Appeal is born
With our newly discovered requirements documented, we set out to brainstorm ways to solve these user problems. The initial solution of overhauling the data model and business logic to support these alternate use-cases for searching was determined to be too heavy of a lift, and would have all but entirely eliminated the Needs feature which other clients and users may still be using.
Realizing that a new layer of functionality would be necessary, an approach was developed to instead create a new search feature altogether to replace the “flexible-ish” Needs as the primary user path of discovering volunteer opportunities. The existing search UI and underlying Needs would be kept, but administers would be encouraged to configure it only for “set-schedule” opportunities.
Our new alternative entity was dubbed the “Recruitment Appeal” and included new configuration screens, a new search interface, and a new user workflow for signing up for Volunteer Opportunities. Appeals were conceived with the intent in mind to recruit a volunteer, and would address the problem areas identified in discovery. One of the largest changes to the interface would be the Appeal landing page, a sort of one-page brochure which could be used to entice potential volunteers to sign up.
Wireframing for Approval
As a solution, the Recruitment Appeal was created using what I would call a "backend approach". This is to say the database architecture, data model, and entity logic was sculpted by the Solutions Architect prior to working through any user interface solutions.
Once the Appeals data model and logic was determined, I worked in close collaboration with the Solutions Architect to realize the vision of the feature. Being an extension for CiviCRM and an enhancement to CiviVolunteer afforded us the convenience of working within established design patterns and familiar user workflows. I built wireframes for all the new screens that would be needed to implement the solution, and the Solutions Architect put together the narrative to propose the solution to the client. At this point we engaged the client with our proposed solution, making certain collect, parse, and incorporate their feedback and concerns.
Post-launch user feedback and takeaways
Once launched, the overall feedback we have received from the client has been positive. Their users were initially reluctant to the change, but adopted the new Appeals feature once the benefits were understood and proven. Volunteer engagement has increased, and overall user satisfaction is higher. The new architecture allowed us to implement faster search methods, as well as the refinement of a previously implemented matching algorithm that now returns more accurate results.
Working with a limited budget for this project, we did not perform any user testing prior to development. While I feel we delivered a very useful and desired feature, I believe user testing during the wireframe phase could have helped us identify improvements to the feature that we hadn't thought of.
Another potential improvement to our process would have been to create low-fidelity prototypes from the wireframes. We utilized singular wireframed screens with notes on functionality, which worked well as a leave-behind artifact. An arguably better approach would have been to use a prototype to show how the screens worked together, rather than explaining it in text. This would have also facilitated user testing during this phase as well.