SPRINGMAIL

How research into volunteering inspired an email app

Project Overview
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."

Role

I was the sole UX/UI Designer on this project.

Methods

UX research
Literature Review
Competetive Analysis
User Interviews
UX/UI DESIGN
Sketching
User Stories
User Flows
Wireframing
UI Design
Testing
Prototyping
Usability Testing

Device

I noticed something odd about volunteering.

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.
project start

I zoomed out to understand the problem.

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.
finding a target

I found an opportunity to help staff at small, local nonprofits.

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.

I connected the data to tell a story.

Small, local nonprofits struggle most.

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...

Existing solutions are too limiting or too complex.

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.
framing the problem

In small nonprofits, staff lack enough time to meet volunteers' needs.

With tight budgets and a few staff, small nonprofits need volunteers to deliver their services. But overworked staff lack enough time to meet volunteers’ needs.

When staff look for help, the current solutions to coordinate volunteers are either too limiting or too complex. This causes frustration, burnout, and low retention of both volunteers and staff. It limits the potential impact of small nonprofits in our communities.

What impact might be possible if a few staff could support an army of volunteers in our communities' nonprofits?
going deeper

I interviewed 9 staff at small nonprofits for further validation & insights.

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.
THE DISCOVERY

Through user interviews, I discovered a big struggle with communication fatigue.

Themes emerged across my 9 interview participants. Here were some key insights from my user interviews with small nonprofit staff.

Doing it all, and then some

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

Running out of words

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

Existing solutions just complicate things

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

Volunteers expect a personal touch

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.
entering the solution space

I explored high-level solutions, from an educational app to a social platform.

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.

Solution Concepts

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 solution

I decided to design an email app for volunteer coordinators.

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.
the MVP features

Groups, templates, scheduling tools

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.

Groups

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

Templates

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).

Scheduling Tools

Users can create, edit, and add scheduling tools within a message draft: signup sheets, group scheduling polls, and one-on-one meeting booking.
user flow

How will these features work together?

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.

I tested a paper prototype to validate my early design choices.

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.
ui design

Making it feel calming, efficient, and empowering.

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.

Green for growth

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.

Type that says, "You've got this"

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.

Growing letter logo, and name

The logo and name serve as a reminder that each message sent can plant a seed of growth in a volunteer and your organization.

Simple interactions

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.

Putting It All Together

I put all these elements together, and adjusted proportions and spacing.

Usability Testing

usability testing

Finally, I tested my solution with small nonprofit staff.

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.

The Task

"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.

The Insight

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).

The Fix: "My First Message"

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.
results

Wrapping & Reflecting

Impact

This project challenged and sharpened my UX skills across the spectrum. I was able to create solution the met users needs.

Next Steps

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.