POTLUCK APP
app design for a community rewards sharing program
TIMELINE: 2 week academic project; 1-day revamp 6 months later
TEAM: Salisa Jatuweerapong, Lisa Weber
TOOLS: Miro, Figma
My role included product strategy, logo design, stakeholder research, wire-framing, and hi-fi flows. Lisa worked on brand identity and copy.
Overview
Potluck is a community rewards sharing program proposal built upon the values of mutual aid. There are two main functions: you can ‘Request’ help, and you can ‘Gift’ rewards. Light gamification tracking how many rewards you’ve gifted and money you’ve saved encourages use of the platform, and Potluck’s mandate emphasizes users to really show the difference you can make with a little gift. Pay it forward with Potluck.
The Ask
Develop a proposal for a screen-based application for a heretofore undigitized (or non-public) civic task: (ie. voting, citizen science, mutual aid, crisis resource distribution, etc.). Starting with the assumption that everyone has a smart device, identify a civic problem that could be aided (if not remedied) by a civic solution.
Our group wanted to look at food insecurity & wealth distribution, through a lens of mutual aid.
INITIAL PROBLEM DISCOVERY
Why is this important?
10.5 percent of US households were food insecure last year—that's 13.57 M families hungry.
One in 7 people in US utilize Feeding America's network of food banks.
The top 20% of Americans owned 86% of the country's wealth...while the bottom 80% of the population owned 14%.
The rich just get richer while the poor get poorer. A microscopic example of this would be how loyalty programs reward higher-spending customers with free items and discounts they may not actually want or need.
Why should companies care?
Well...to do good? Maybe, but mostly because:
78% of US consumers are retracting loyalty at profit-crushing rates, with millions of loyalty points sitting dormant. (Accenture Strategy)
Loyalty programs aren't working right now, and companies need new strategies to convert users. Adopting this angle has the potential to draw in users who are interested in social welfare, as well as improve their brand image.
*More research needs to be done to substantiate the business case, however, this was out of scope for my timeline. If I had the time, I would do a SWOT analysis.
So... loyalty program rewards are going unclaimed. And people are going hungry.
Can we solve two problems at once?
P.S.
Has the pay-it-forward model ever worked before?
Yeah! Rosa's Fresh Pizza, the pay-it-forward $1 pizza shop, has had its walls covered with over 17000 multicolored sticky notes over time, each representing a $1 pizza slice a customer has bought for someone less fortunate. If customers were willing to pay $1 for someone else's meal, why wouldn't they donate something they don't even have to pay for?
USER RESEARCH
Who are we designing for? What are their needs and goals?
Our research process at a glance.
I said in the beginning that we went wrong a lot, and here's where that first started. When we started this project, we originally saw this as more of a grocery-focused app, and we researched food banks and their users. The maps shown will support that, though we later pivoted into a more F&B direction.
The assumption we made was that there would be two users: one who primarily donated, and one who primarily requested help. However, this was proven wrong by subsequent interviews*: there was a larger overlap between the segments than expected.
*For this project, our academic focus was on the design. While I personally believe in the importance of doing robust research--and our lack of robust research certainly trips us up later--we weren't able to do much primary research in our timeline. We started with secondary research, then used IDIs to probe deeper on certain topics.
Findings
We did three user interviews with classmates who were loyalty program users. If given more time, we would've screened for demographics and conducted a survey.
1. The most common frustration with loyalty programs was that the rewards would expire before they could use them.
2. 100% of interviewees said they would donate a freebie at least once, if it were "easy" and was of no cost to them.
3. More people were excited about receiving coupons than donating.
We knew we would have to design an experience that incentivized donating.
HYPOTHESIS #1
If we make it so that people don't have to go out of their way to donate food, people would do it out of the goodness of their hearts.
DESIGN GOALS
How can we bring it all together?
USER TASK FLOWS
3 main tasks
1. Gift Rewards
User browses their rewards > User selects a reward to gift > Gifted reward is sent to the Community pool.
Alt: Batch gift system; user donates all their rewards to Community pool.
2. Claim Rewards
User browses Community rewards pool > User sees reward they want > User 'claims' reward > They can use now or use later in their rewards.
3. Redeem Rewards
User is at the store, wants to use a reward they own> User selects a reward to use now > User gets QR code for reward > Scans code IRL.
With tasks in mind, we started designing the information architecture.
This IA needed several revisions, and I regret not doing card sorting exercises to clearly conceptualize the organization.
In the end, what didn't work was that the task flows we decided on weren't...actually the best for the users. But we didn't know that yet!
SOLUTION DESIGN
Let's start wireframing.
With the IA done, I started sketching out the 3 user task flows we had set up. I started with lo-fi sketches (see above), then brought them into Figma.
Upon seeing our wireframes and IA, the feedback we got was that we were losing sight of the people in need. These tasks focused on the 'rewards', making it easy for reward redeemers and users, but where were the people in need? If this was a mutual aid system, the users requesting help needed to be our north star.
ISSUE: Our system was dependent on rewards availible, instead of rewards users needed. What if the rewards they needed weren't being offered?
SOLUTION: Users needed to be able to ask for what they needed, so other users could respond to their ask.
PIVOT #1: What I'll call the Taskboard era.
Remember when I said the IA was changing a lot? Here's the first change, where we introduce a new feature, Taskboard, and make it the home page.
We wanted to design the Taskboard similar to a "People Map", a concept we've seen in mutual aid networks. This taskboard showed various requests that needed to be filled in your area. Lisa did a quick mock-up, though the map was immediately scrapped due to privacy and safety concerns.
An aside: At this point, you're probably wondering, why didn't we just digitize mutual aid?
Mutual aid pods often operate very low-tech: the spreadsheet on the right is how a local group does day-to-day operations.
Our reasoning was that we felt that was not a need felt by current mutual aid systems and the learning curve would be too high. We wanted to offer people ways to help out without making them go out of their way... and the taskboard was doing exactly that.
TASKBOARD ISSUE #1: We made people have to go out of their way to donate. Following our hypothesis, this meant fewer people would donate.
ISSUE #2: Users could entirely ignore the taskboard and still use the 'Rewards' function of the app for their own purpose, instead of donating.
What stayed though was the concept of the people behind the tasks. We moved forward with integrating the 'Request' feature on the old home page, and attached names to requests to humanize them more. At this point, we also debated getting rid of the Claim Community Rewards feature, and made Requesting the only way to gain rewards. Looking back, we made the wrong call in keeping it.
REEVALUATING USER TASKS
PIVOT #2: Okay, let's find a way to incentivize gifting rewards. The 'People' Era
It was clear our system still made it too easy to redeem apps, and never gift any. How could we use UI to reinforce gifting as a desired action?
I tried several strategies, while concurrently working on hi-fi flows. These ultimately all failed.
1. Putting People front and center
Instead of having the coupon name at the top, we would first show the people who needed it. The profile pictures would encourage empathy and bring the human touch to the platform.
Not only was this visually overwhelming, all the extra load time would make this design impractical.
2. Creating intentional friction on the redeem button
What if we made it harder to press redeem? I created a design where users had to hold down the 'Gift' button until it turned to 'Redeem'. The rationale was that the moment of pause would encourage users to deliberate if they'd rather donate, instead.
This design wasn't intuitive however, and required a lot more testing. I wasn't confident in it, and scrapped it in later iterations.
3. Gamification—earning points by donating.
+Making Batch Gifting Easy
Instead of having to gift one by one, we created a 'Quick Gift' interface that would let you quickly batch donate all your rewards (can between New Rewards/Expiring Rewards/All Rewards).
I was inspired by the action of swiping away a reward you didn't need, kind of like Tinder (you can see previous designs were more Tinder like).
PIVOT #3: aka this time, I designed on a layout grid.
Taking all the feedback from V2 and iterating further on my own time.
In the time between, I'd been focusing on improving my visual skills, as well as expanding my visual library. I brought to a few peer design crits to see how I could make the app better.This new UI is inspired by card patterns in Uber Eats and AirBnB.
1. Fixing the IA (again).
Users were confused by the 'Community' tab. We'd initially conceptualized its placement there as 'Community Rewards', where users could Browse and Claim rewards, but users expected more of a social feature from the connotation of the word. Since Navigation titles are better when absolutely clear, I changed it to 'Browse' and also moved it into the menu.
2. Quick Gift Banner
'Quick Gift' was another term that was confusing. This button was the main CTA of the page, so I highlighted it in a banner and also used copy to explain its function.
3. Card Redesign
I went with a more conventional UI and used a secondary button for 'Redeem', so 'Gift' was prominent, but Redeem was accessible still. Furthermore, I shrunk the icons to give longer coupon names more space, and gave everything a bit more room to breathe.
What's next?
Maybe an IA like this?
The Claims/Browse/Community feature weakened the Request feature. We should've removed it entirely when we introduced Request.
This would largely simplify the IA. We originally conceptualized the Home screen as a dashboard of sorts, where you could Redeem, Request, Gift, Claim/Browse in one, but that was too many functions.
