Background

Arts People is a ticketing and database management app geared towards small, performing arts venues. These theaters often rely on volunteers for day-to-day operations. The former volunteer management feature offered had been sitting in beta for years, untouched. Customers called it “unusable” and it had deterred prospective customers from signing up. For these reasons, management decided it was time for a redesign.

Research

We uncovered that 0 customers were actively using the former volunteer management feature, and a simple search for “volunteer” in our Help Desk yielded 3,700+ inquiries on the topic. After sorting through those requests, I had a list of roughly 20-30 users who seemed like great candidates for helping us understand why this feature wasn't being utilized.

I was able to schedule strategy interviews with a handful of interested parties. These interviews provided an abundance of invaluable feedback on the matter:

Additional research conducted:

• Competitive audits (Volunteer Sign-up, Sign-Up Genius, among others)
  

• Stakeholder Interviews (Management and Sales departments)
  

• Documentation of customer feedback through our help desk
  

Organize & Analyze

Affinity Diagramming helped sort through the large amount of data acquired.

By clustering requirements into like-categories, I pinpointed the most important needs for our new volunteer management product:

• Online Sign-Up: allow the volunteers to select shifts online themselves

• Emailing: automatic email confirmations, cancellations, and reminders

• Reporting: comprehensive tallying of hours worked, for individuals and events

• Managed by Volunteers: take work away from the administrator where possible

• Check-In Process: are they showing up for the job?

“The best results come from testing no more than 5 users and running as many small tests as you can afford.”
- Jakob Nielson

Using Sketch, InVision, and an iterative design approach, I started with wireframes and moved along the pathway towards more high-fi prototypes. 

I facilitated live and remote user-testing sessions that helped uncover a number of problems with assumptions made during the design process. Below are a few examples:

The design required users to manually enter their volunteer event information. Users had expressed that they would be needing volunteers for shows that already existed in the system, so it was important to design the product in a way that didn't require the user to manually enter the same information twice.

The solution was to offer a choice at the beginning of the "Add Event" process that allowed the user to build a volunteer event from a pre-exsting show, as seen below:

The process for adding shifts to multiple dates in one swoop needed refinement. Users were commonly trying to save an event before specifying any of their roles needed for their dates. By tweaking the verbiage and drawing attention to the "Add Positions" action, the updated design led users to supply more details before saving. 

The custom icons used during much of the user testing caused a bit of confusion. The briefcase icon meant to indicate "Roles" was often called a lunchbox. And the person with a heart, meant to indicate "Volunteers," was confused with a logout avatar. I redesigned the Events, Volunteers, and Roles icons with that feedback in mind.

I was also able to confirm the elements in my design that were working well. Users had no trouble with the main elements of the design: creating and managing events, adding volunteers, and assigning shifts. 

Final Design

Once the design stages started slowing down, I was able to pass my InVision mockups to our developers who used the Inspect mode build the product. Here's a glimpse at where we landed: