I designed an MVP prototype for a new mobile app that facilitates the sharing of free items/services within local communities. The concept comes from Buy Nothing Project, a decentralized non-profit network of Facebook Groups that have helped communities come together in mutual support.


Buy Nothing currently only operates within Facebook Groups, which have proven to be a clunky tool for this use case. Buy Nothing groups have only been growing since the pandemic, as has the demand for a better solution.


Create an app that is specifically designed to enable members of Buy Nothing groups to share resources, avoid waste, and build community.


Generative UX Research. Mobile UX/UI Design. Rapid Prototyping.
Timeline of 4 weeks.

Scope & A LESSON IN pivoting EARLY

I originally wanted to create an app to facilitate the volunteer grocery deliveries I was doing with Crown Heights Mutual Aid at the beginning of the pandemic. I ended up pivoting to the Buy Nothing Project solution after running into some hurdles with research:

I found that several of the most prominent mutual aid groups (i.e. Berkeley Mutual Aid, Bed Stuy Strong, and Denver Delivery Network) had stopped doing deliveries due to lack of demand as things were opening back up.

I had a hard time with recruiting. Since mutual aid groups are hyper-local, I could only join the one for my neighborhood. But I had de-activated the email that gave me access to the Slack channel a while ago and was unable to get back in despite reaching out several times. I was also unable to find other participants in my personal network.

Because of these challenges, I decided to pivot to a wider scope that still focused on the mission of helping communities share resources.

Secondary Research

I've been an active member of my local Buy Nothing group for a while now, but I knew nothing about Buy Nothing Project until I started working on this app.

In fact, Buy Nothing is a decentralized network of community-based gift economy groups founded by Rebecca Rockefeller and Liesl Clark in 2013. Buy Nothing operates primarily through Facebook Groups where anyone can create a group for their neighborhood and facilitate the giving/receiving of free gifts. Groups are run by moderators who enforce the rules.

As always, I wanted to keep my app consistent with Buy Nothing's values, which I found on their Mission & Principles page:

Buy Nothing's rules and values

As luck would have it, I discovered Buy Nothing Project was already developing an app (in beta). On their blog, they listed all the problems an app would solve, indicating that this was a solution in demand:

Problems faced by Buy Nothing members and target groups

While a Buy Nothing app didn't exist yet, 2-sided marketplaces where users could both sell and buy were the closest "competitors":

Competitive analysis of Buy Nothing alternatives, online and offline


I interviewed 7 Buy Nothing members in Brooklyn, Austin, and Seattle:

- 2 whom I've given items in our local Buy Nothing Group
- 5 I recruited through my social media network

Research questions:

1. Why do members choose Buy Nothing over the alternatives?
2. How are Buy Nothing Project's values maintained from group to group?
3. What problems with the current Facebook-based system could an app fix?
4. What are the main jobs to be done?


Hands down, this was the most interesting set of interviews I've ever conducted. I wish I could share all the stories here, but I'll just focus on the main insights that made it into the design:


Participants agreed on values but had different preferences on how to choose recipients.
For example, having control over recipients contributed to one participant's sense of safety/control but another participant's anxiety/discomfort. Participants also varied on how long they thought posts should stay up before selecting a recipient (the longer they're up, the more accessible).

Facebook Groups fails to accommodate important tasks such as filtering, scheduling, and setting neighborhood boundaries.
The most pressing concerns for participants were the inability to filter/sort posts and coordinating pick-ups with unresponsive or unreliable members. I also found a common trend that the larger the group, the less likely participants were to be active in it. As groups got bigger, new admins would split off and create more and more geographically specific groups.

Participants both gave and received, but perceptions of income played a role in the proportion of each activity.
Those who saw themselves as relatively more affluent wanted to focus more on giving than receiving. One participant transitioned from receiving to giving as their income grew.


After reading some articles about reducing bias in personas ("The Big Problem With Personas" and "How to Reduce Bias in Your UX Practice with Persona Scenarios"), I tried something different and focused on summarizing behavior from my research and omitting demographics.

Giver vs. Receiver behavioral personas

Feature Analysis

Because I was tackling so many problems in a single app, I focused more on determining what features I wanted to include and less on the specifics of those features. Ideally, I would get a prototype out quickly and iterate based on feedback received through usability tests.

Problem / Solution


Using the apps from my competitor analysis as a reference, I created a sitemap:

Preliminary site map

User Flows

I also used Miro to map out the giving and receiving task flows with an emphasis on scheduling:

Task flows for giving and receiving

Lo-fi Wireframes

I decided to design mobile-first since this was the Buy Nothing Project's approach as well as the device most participants said they used. I focused on the main tasks identified:

1. Onboarding
2. Browsing and filtering
3. Expressing interest in an item
4. Posting an item
5. Scheduling a pickup
6. Checking notifications/activity

Here they are in Figma:

Low-fidelity wireframes for mobile only.

Brand identity

Next, I worked on branding to bring the project to life. Flip through the steps in my process here:

Thus far, I had not come up with a name or logo for the app. So I sat down and gave myself about 10 minutes to word cloud themes, words, and possible names:

I decided to use different naming and branding from Buy Nothing to give myself as much creative freedom as possible.

To start, I brainstormed some brand words and put together a mood board:

I wanted colors that were natural (to reflect sustainability) and calming (to reduce overwhelm). I ended up going with turquoise and orange, for tranquility and sunshine.

I chose humanistic and readable typefaces.

I wanted to ensure that the name was unique, which ruled out some really great options like FreeCycle, ShareLocal, and Share Network. In the end, I landed on Sharecycle:

High-fidelity prototype (v1)

I used the branding to create a high fidelity prototype. To start, I made a reference board of screenshots from the competitor apps. To save time, I reused a lot of the same components and patterns throughout with the hopes of validating them in usability testing.

To showcase how I implemented feedback, you can see the versions side by side in the next section.

Test & Iterate

Usability testing

I conducted moderated usability tests over Zoom with 6 participants, 4 of whom had never used Buy Nothing before. I was interested in seeing how learnable the app was even for those who were unfamiliar.

I received a substantial amount of feedback that was surprisingly consistent on tasks that had <67% completion rates on the first try (like viewing activity and scheduling).

I derived themes using an affinity diagram, ranked the feedback by prevalence, then prioritized by effort:

Usability test report


I wanted onboarding to feel warm, welcoming, and human, and I thought that the royalty free illustrations I was using (while very cute) felt a little too corporate.

I went out on a limb and asked my extremely talented friend Sarah Leituala if they had any vector illustrations they would be willing to donate. They were actually kind enough to design and donate some wavy character illustrations that ended up adding SO MUCH PERSONALITY to the onboarding process. I was so grateful to collaborate with them!


On top of the feedback I received from usability testing, I also asked for UI feedback from my peers, which I incorporated into the next iteration. Finally, I performed an accessibility audit and made several changes to ensure that contrast met WCAG guidelines (AA+).

Here are some of the most impactful changes:

High Fidelity Prototype (v2)

Finally, I put it all together into a new prototype, which you can click through HERE. (It'll look much better than these compressed gifs!)

Challenges & Lessons

Seeking out lightweight feedback before usability testing

I'm working on feeling more comfortable asking for feedback outside of formal settings. A lot of the insights  gleaned from usability testing were relatively quick (but impactful) fixes that probably could've been pointed out to me beforehand. Had I done that, the amount of feedback coming out of testing may not have been so overwhelming and time consuming to synthesize. I'd also try usability testing sooner with a lower fidelity prototype.

Opening up competitor analysis to other verticals

I only used marketplace apps for borrowing patterns on the first iteration, but going into the second iteration, a fellow designer recommended an extensive pattern library called Where has this been my whole life?? Not only was taking screenshots of apps time consuming, I was also missing a lot of good stuff. As it turns out, like music, lots of great patterns transcend genre.

Thinking about contrast accessibility During Branding

While WCAG contrast guidelines don't technically apply to logos and wordmarks, I still wish I had considered this when designing them. During my accessibility audit, I spent a decent amount of time trying out different higher contrast variations but couldn't find something that worked. I don't anticipate being in a position to choose brand colors/logos very often, but this is definitely something I'll be more cognizant of in the future.