How research into volunteering inspired an email app

Volunteering seems like an "our better angels" phenomenon where people freely give their time to organizations doing good. But it doesn't always end well.
Inspired by my nonprofit work, I embarked on a User-Centered Design process to explore product design opportunities. Through generative research, I discovered that staff in small nonprofits struggle with communication fatigue.
This led me to design an email app that helps staff at small nonprofits support more volunteers in less time with groups, templates, and organizing tools — a solution my target users found "wonderful to use."
I was the sole UX/UI Designer on this project.
UX research
UX/UI DESIGN
Testing
While working at a nonprofit, I observed staff and volunteers alike frustrated by the coordination of volunteering. How could people donating their time to nonprofit organizations result in mutual frustration?
My curiosity led me down an intriguing path to designing an email app.
Inspired by a question, my first move was to gather more data to validate and define the problem. I had a lot of questions.
Does a problem really exist with volunteering, at scale? What exactly is the root problem I'll solve for? Who experiences this problem, and how does it affect them? Why does the problem exist? What solutions are available, how well are they solving the problem, and why?
Working outward from my observation, I was wary of confirmation bias. I started with secondary research of existing data within the U.S. to add objectivity and scale to my perspective, and I resolved to be open to new data that invalidated my hunch or changed my point of view.
I did a literature review and competitive analysis. I marked up psychological research, national studies, and articles. I dissected products for coordinating volunteers. I went wide and absorbed everything I could about volunteering.
This led to my first major hurdle . . .

Mind Map iterations showing complexity in the volunteering problem space
I started with a huge problem space. Volunteering encompasses hospitals and sports teams, board members and soup kitchen servers, teenagers and retirees. Each with unique contexts, behaviors, and challenges. On a macro level, volunteering is just one node on a complex web of interconnected problems facing the nonprofit sector: fundraising, staffing, institutional inertia, the list goes on.
To sufficiently research and design a solution that solved any user's problem, I needed to find a smaller target.
My mindset changed from sponge to scalpel. I prioritized data by relevance, consolidated by affinity, and looked for strong connections between my secondary data and competitive analysis.
Here's what stood out.
Volunteers aren't (really) free. And while it may be a factor, altruism isn't believed to be a primary driver. In reality, people are motivated to volunteer by the expectation of one or more intrinsic benefits:
- Furthering their values
- Learning, understanding the world
- Social connection
- Gaining new skills
- Having purpose
- Feeling needed & valued
- Increasing work viability
- Validating self as a good person
- Escaping other problems in life
1. “The Volunteer Dilemma.” Murnighan, J. Keith, et al. Administrative Science Quarterly
2. “The Motivations to Volunteer.” E. Gil Clary, Mark Snyder. Current Directions in Psychological Science
3. GIVERS Research Report: Using behavioral science to recruit and retain volunteers more effectively. Daniel Fujiwara, et al.
This hasn't changed for almost 20 years. A nationwide U.S. study by Americorps and the Urban Institute in both 2004 and 2019 found largely the same results.
They assessed effectiveness across 20 metrics, such as:
- Role Descriptions
- Training
- Communication
- Appreciation
1. “Volunteer Management Capacity in America’s Charities.” Mark A. Hager, Ph.D, Jeffrey L. Brudney, Ph.D. 2021
2. “Volunteer Management Practices and Retention of Volunteers.” Mark A. Hager. Jeffrey L. Brudney. 2004.
3. "Study Finds Nonprofits Lack Effective Volunteer Management." 2004. Philanthropy News Digest.
Nonprofits lack staff, time, budget, and formal training in volunteer management. Especially small nonprofits.
- Less than 1/4 of nonprofits have a staff member who spends more than 1/2 of their time managing volunteers.
- Finding staff candidates with formal training in volunteer management is rare
- Nonprofits lack time and budget to provide existing staff with training
1. “Volunteer Management Capacity in America’s Charities.” Mark A. Hager, Ph.D, Jeffrey L. Brudney, Ph.D. 2021
2. “Volunteer Management Practices and Retention of Volunteers.” Mark A. Hager. Jeffrey L. Brudney. 2004.
3. "Study Finds Nonprofits Lack Effective Volunteer Management." 2004. Philanthropy News Digest.
More people could be volunteering and existing volunteers could be more impactful if they were effectively supported.
- Only 30% of people in U.S. volunteered in 2019
- 2/5 people have stopped volunteering before due to being poorly managed
- On VolunteerMatch, the #1 complaint of prospective volunteers is never hearing back from the organization (*)
1. Volunteering in America: Demographics. Americorps.
2. “Volunteer Management Practices and Retention of Volunteers.” Mark A. Hager. Jeffrey L. Brudney. 2004.
3. Jane Cravens. Nonprofit speaker, consultant, moderator of r/volunteer on Reddit (*unable to verify data on VolunteerMatch)
Paradoxically, small nonprofits simultaneously needed volunteers most, and were the most under-resourced to support them.
They presented a significant target. There are one million small nonprofits with a budget < $500K/year in the U.S.
Through this lens, I looked again at existing solutions. Small nonprofits rely on flexibility to make do with minimal resources, but lack time for complex software. Here's what I found...

Free solutions focus on a single task, but offer limited flexibility.
Paid products offer an all-in-one solution, but are time-consuming to learn and maintain.

I'd found my target. My analysis revealed a target user, a problem, and a gap in current solutions that felt focused, concrete, and substantial. My product design would focus on helping staff who coordinate volunteers at small, local nonprofits.
With renewed clarity, I framed a problem hypothesis to guide me forward.
With a clear problem statement, next I wanted to validate my hypothesis and uncover deeper insights through my own primary research. I arranged user interviews with 9 staff in small nonprofits, across a spectrum of seniority levels and nonprofit types.
I would have liked to include a contextual observation and diary study, because coordinating volunteers happens between other daily tasks over extended periods of time. I ruled them out due to Covid, travel, and the project's time constraints.
Regardless, my interviews were filled with insight.
Themes emerged across my 9 interview participants. Here were some key insights from my user interviews with small nonprofit staff.

Participants juggled multiple roles, worked voluntary overtime, favored quick fixes, and didn't have time to learn or maintain new software.

Their biggest pain point with volunteers was communication fatigue. Recruiting, onboarding, setting expectations, and resolving misunderstandings felt never-ending.

Participants felt Volunteer Management Software products created extra work and confusion. They used workarounds with email, which they found more familiar, easy, and personal.

Participants felt that volunteers expected more personal communication from small nonprofits, and were less accepting of automated messages or FAQs. They managed relationships with their volunteers.
At this stage, I applied divergent thinking to explore many as possible solutions as I could. Producing more ideas increases the likelihood of discovering one that actually solves the problem.
UX wisdom says this is harder for a single designer than a team, because you're limited to one perspective. I compensated for this by shifting perspective through my research artifacts: 8-minute bursts of ideation around each HMW question, each persona, and a few randomly chosen outlier data points for good measure.
In hindsight, I still wish I'd invited at lease one UX designer to review the research highlights and join me for the day to shake up my point of view. But I ended up with 100 or so ideas. Through affinity mapping, those coalesced into 6 big ideas.
Modular Toolkit
Bring common organizing tools into one place with a unified, lightweight user experience.
Social Platform
Empower volunteers to meet each others’ needs through a social platform with signups built in.
Staff Training App
Make volunteer management education more accessible and engaging through an app with mini-lessons.
Training Video Maker
Help staff quickly create and share video training collections for volunteers.
Email that Helps
Help staff communicate with volunteers through an email app with templates, tips, and supports.
Lean VMS Software
Design a simpler Volunteer Management Software with paired-down features & better usability.
The choice was hard. My research artifacts really proved their value here. I asked myself, Which solution best met my three principles? Which solution could I see my personas actually using?
I decided to design an email app with communication supports for people who coordinate volunteers.
Why email? My user interviews indicated that small nonprofit staff's biggest challenge with volunteers was communication fatigue. They didn’t have time to learn and maintain specialized software, but were already emailing with volunteers every day.
Building communication support into email would meet staff where they are. And (hopefully) reduce the time and energy they expend there.
With my solution decided, I wrote user stories to express all the potential user needs for this solution. The list grew impossibly long, and I started prioritizing.
I prioritized four features for my MVP prototype based on elements of communication fatigue in my research: visual overwhelm, repetitive input, creative exhaustion, and redundant tool linking.

Users can quickly save and recall groups of people within a message draft.

Users can save and recall their own email templates. One template can include any elements of a message (recipients, subject line, body text, signup sheet, attachment).

Users can create, edit, and add scheduling tools within a message draft: signup sheets, group scheduling polls, and one-on-one meeting booking.
My strategy was to build into the familiar process of composing an email.
Users should be able to manipulate new features (groups, templates, and scheduling tools) directly within the new message window. This, I believed, would make the experience fast and intuitive.
I crafted a user flow to articulate how this would work.

With my features and flow decided, I started sketching screens with pencil and paper. I did nothing radical here. Considering my users' wide age range and limited learning time, the interface needed to feel familiar. The new features had to be clear and obvious.
I considered Jakob’s Law, that people expect your site (or app) to work the same as the ones they already know.
With all this in mind, I incorporated my new features neatly into a familiar email interface.

I tested my paper prototype with a local volunteer group. Participants liked the concept and completed the tasks easily. I only discovered two small issues that were easily fixed in my wireframes.
Seeing peoples' reactions helped validate my early design choices, and de-risk my time investment in wireframing and UI design. It increased my confidence that I was heading in the right direction.
Because this was a new app, designing the user interface also meant creating a brand. I needed to establish the colors, typography, tone, and also a name for this new solution.
My research showed staff are overwhelmed, busy, and discouraged. So I wanted the user experience to feel calming, efficient, and empowering.
Neutral tones look clean and calm. Green evokes health, productivity, and growth. I reserved green for key actions like sending message to positively associate these actions with growing.
Neutral, soft, rounded sans-serifs are friendly and easy on the eyes. They feel professional and organized. This makes the interface less intimidating, and helps users feel calm, collected, and in control.
The logo and name serve as a reminder that each message sent can plant a seed of growth in a volunteer and your organization.
The goal of my prototype was to test the solution concept and usability, so I added few interactions. This hover interaction helps communicate what will happen if a user clicks. It feels playfully empowering.
I put all these elements together, and adjusted proportions and spacing.
I conducted usability tests with 9 staff at small nonprofits, in two cohorts of 4 and 5. Participants loved the solution and moved easily through the tasks, with one exception: the very first step.
What was going on? I used the second round of testing to diagnose the issue and design a solution.
"Imagine you organize a weekly Food Pantry. You need to send out an invitation to your volunteers to sign up for shifts this Saturday. You'd like to save time next week and not have to make this from scratch again."
The result? 4 users all took different first steps, and not the one I expected.

To my surprise, all 4 participants started in a different place. This isn't necessarily a problem. Many apps provide multiple ways of doing the same task to accommodate different mental models, and so could I.
But why didn't any users start with the New Message button? I wanted to understand users' behavior, and create a better solution.
Hypotheses 1: I moved "New Message" button. Users still took different first steps.
My first hypothesis was that the placement of "New Message" button caused users to miss it. Many desktop apps place a logo in the top-left corner, and perhaps users aren't used to interacting with that area. So I added a logo to bring the New Message button away from the corner, and tested again with 5 more participants.
One participant started the task by clicking "New Message." But the rest: all over the place. Same problem.
However, the second round of testing gave me insight into why this was happening. It rang like a bell when one user said, "Ohhh, I can save a group in the message. I wish I'd known about that sooner, so I didn't do it the long way."
The problem was: When new users start at the inbox screen, they aren't aware of what actions they can do in the New Message screen (i.e. save groups, create a signup sheet, save a template).
Tooltip tours are notoriously unpopular. So how would I get new users to see what they can do in the New Message flow, before getting started?
My solution was simple: Show it them. And, provide the option to learn more or come back later. I accomplished this by having the New Message window open, plus an introductory email in the inbox, at the very first use of the app.
This project challenged and sharpened my UX skills across the spectrum. I was able to create solution the met users needs.
As an educational project, my solution Springmail was focused on users' needs discovered through research, and less on the technical feasibility and business viability of an email solution.
In the real world, once I chose the high-level solution of email, another phase of research was warranted: 1) primary research on small nonprofit staff's behaviors with email, and 2) competitive research to assess the feasibility and viability of launching an email product.
Technical feasibility and business viability would present significant challenges, since Gmail and a few others dominate the email space.
I see three possible options for entering the market:
1. An Independent Email Provider | As a standalone email provider, Springmail would require significant data hosting, spam filters, indexing, and algorithmic power that would unlikely rival Gmail. Also, it'd be a tough sell to get users to leave their current email provider and start over with a new email address.
2. A UI Extension | Springmail could piggyback its interface on top of Gmail, like another newcomers to the email space, Superhuman. But this requires users to set up email forwarding, which conflicts with my users' limited time for setup and low tech confidence.
3. A Plugin | Springmail could be a plugin within Gmail, like Flowrite. That would present a whole new design challenge, and would likely limit its functionality.
Each has its challenges. I believe option two is the most feasible, even though it presents the unfortunate challenge of helping users set up email forwarding.