Destigmatizing Support
Segmenting Give InKind’s onboarding process.
Role: UX Designer, UX researcher, UX writer
Team: Lacy Omon, Andre Oosthuizen, Abdelmajid Abdelaal
Duration: 3 weeks
COMPANY
A stillbirth brought two grieving parents to create Give InKind: a social platform designed to organize support from the communal many to the vital few.
ROLE
My job, along with my team, was to redesign Give InKind’s onboarding process to boost user retention, and mitigate user drop-off. We achieved this goal by developing two personas, and segmenting Give InKind’s onboarding process accordingly.
Personas
Supporter
True to their name, the supporter enlists Give InKind to provide… support. For a friend, a family member, a loved one in need. The supporter is focused on function, on action. They want to do something, anything, to alleviate the suffering of those whom they love. They feel, of course, the pain they perceive in others. And they want to help. All they want to do is help.
Recipient
Unfortunately, the recipient doesn’t want their supporters’ help. They may need their help, sure. But they’re forced to it by financial, temporal, practical necessity. Asking for help feels shameful. Needing help feels worse. The recipient, in the end, hates help. They wish it away. They will avoid soliciting support from even their closest relatives, because the recipient wants to stand, as we all want to stand, on their own. Unsupported.
The Problem
Similar to a Facebook profile, an InKind page—the result of Give InKind’s onboarding process—is used to structure personal information. It’s an interface employed by the recipient to update supporters about what the recipient needs. Food, clothing, babysitters, etc.
So far, so fine.
Here’s the rub: Supporters and recipients want different things. Supporters want to help recipients; recipients want to achieve, or recover, a state of independence whereby they don’t need any help at all.
Why is this a problem?
The current Give InKind site assumes that supporters and recipients have an aligned goal: to help recipients. Supporters want to help recipients; recipients want to help themselves. But this is not true.
Supporters want to help recipients; recipients want to avoid receiving help at all.
The Site
Language: an obstacle.
The majority of InKind pages (80% or so) are created by supporters who pass the pages on to recipients. As such, the supporter who creates an InKind page is not the same as the recipient who ‘owns’ the page. “Create Your Page” is a misdescription of 80% of Give InKind’s onboarding activity. Ditto for the tagline: “Free tools to help you coordinate support—all in one place.” The same goes for: “What email address would you like to use to manage your page?”
These misdescriptions continue throughout the onboarding flow. They can mostly be fixed by editing out a single word: You.
Function: an obstacle
The current Give InKind onboarding process provides a toggle, and a description of each function, but does not allow the supporter or recipient to interact with these functions prior to completing the onboarding process. In the current flow, the supporter and recipient can only see the relative value of an InKind page after they have already created it.
There exists a gap between the point at which the recipient and supporter make a choice, and the point at which that choice’s value is demonstrated. The supporter is more amenable to this gap than the recipient. The supporter values speed: a toggle is speedy. The recipient doesn’t care about speed. Instead, the recipient values agency, independence, control. This gap breeds anxiety, frustration. It does not promote agency, nor a sense of control.
The Solution
We segmented the onboarding process, separating supporters from recipients, by designing two onboarding processes tailored to the specific goals of each individual persona.
Given our time constraint, we focused primarily on designing for the recipient.
The Reticent Recipient
Asking for support—the act itself—is very emotionally taxing. It can emphasize feelings of grief and powerlessness, and create further senses of passivity and uselessness. The recipient does not want to feel like a burden. They do not want to be seen as weak.
Even though a recipient may need support, and may know that they need support, they may still be hesitant to ask for it. This is because the act of asking itself generates a host of negative emotions.
So how do we reframe the act of asking to emphasize a sense of agency, rather than a feeling of passivity; a sense of control, rather than a feeling of powerlessness; a sense of independence, rather than a feeling of uselessness; and, above all, a sense of direction, rather than a feeling of grief?
Acknowledgment
Acknowledging the recipient’s feelings helps establish trust between the recipient and Give InKind. Asserting the recipient’s control promotes the recipient’s sense of control over the Give InKind process, and, by extension, over the support they receive. Describing an InKind page’s purpose tells the recipient why they should use an InKind page, and reinforces the recipient’s desire to receive support.
This prepares the recipient—emotionally and mentally—for the onboarding flow that follows. The copy is meant to encourage the recipient to act on his own behalf
Privacy
Privacy and agency go hand in hand. Agency, at its core, is the recipient’s ability to affect his surroundings. Here, the recipient’s surroundings equate to his community—to whom he allows to interact with his InKind page, or whom he allows to see his requests for help.
Privacy is social. It’s a response to fear, shaped by a selective sense of trust. Before providing the recipient with Give InKind’s privacy settings, my team and I wanted the recipient to think intentionally about trust. This provides him the emotive reason for choosing what he wants from his space.
Function
We wanted to provide the recipient the immediate ability to manipulate and control the functions of their InKind page, so that they could get an immediate sense of how an InKind page worked, and how it could benefit them. We also wanted to provide the recipient with a sense of who else would be interacting with these functions.
Conclusion
Our client was impressed by the possibilities of segmented onboarding, and plans to implement a segmented flow within the next six months.
Though they acknowledged the site’s essential design problem—that a single interface has to meet the needs of two separate user-types—they did not decide to prioritize this problem. This was, in part, because they felt it would require too much work. Give InKind is a small company. They do not have the time, or manpower, to undergo a complete overhaul while still functioning as a business.
Finally, this project was an absolute pleasure to work on, for me. I think about my mother’s divorce. About her anxiety, her pain. I think Give InKind could have helped her.