Publicus Banner Image3.png

Publicus: A Trustworthy Platform for Sharing Household Goods

Publicus is a mobile application developed during a 10-week User Experience Design course at General Assembly. I was responsible for all aspects of research, conceptualization, and design of the app, from user interviews to feature prioritization, to wireframing, to building a functional prototype.


The Problem

As a society, we’re drowning in stuff.

Say you live in a place that has a yard, with a lawn. How often do you need to use a lawnmower?

Maybe you actually own a lawnmower, which sits idle for 27 days of every month. Yet everyone on your block also has their own lawnmowers, which they also use for a few hours every month, and that also occupy space in their garages or sheds when they’re not being used.

Lawnmowers 2.png

Meanwhile, some poor soul’s lawnmower just died. Custom, habit, and social convention are keeping them from asking to borrow any of the many lawnmowers that already exist in the neighborhood.


Current Solutions

Publicus - CompAnalysisGrid3.jpg

There already exist a range of online platforms for sharing, borrowing, or trading goods or services without exchanging money. Some of these, like Kindista and Peerby, have their activity concentrated in a single city or region. Simbi is a strong competitor, operating on its own internal system of currency. Only Peerby has a map interface, and only Simbi has a system for rating interactions with other users on the platform.

To research real-world pains, gains, and jobs to be done by prospective users, I conducted interviews.


User Insights

Publicus - UserInsights.jpg

Five interview subjects shared their experiences with trading, borrowing, or lending things or services where no money or very little money was exchanged. Interview subjects ranged in age from 25 to 53 and all live in the Chicagoland area. Emerging themes included:

  • Sense of trust and responsibility

  • Desire to give back to a real-world community

  • Aversion to waste, reluctance to spend money

  • Distinction between items that are or are not borrowable/lendable

  • Positive emotions arising from communal activities

One interview subject had previously used a mobile resource sharing platform, Peerby, which originated in the Netherlands and sees some usage here in Chicago. She had used Peerby to borrow a pair of ice skates, and her experience with the platform was generally positive. She feels she would use the platform more frequently if she had more household items to share and felt that she was more actively contributing to the user community.

Informed by these insights, a minimum viable product and three personas emerged.


Minimum Viable Product

Publicus - MVP small.jpg



User Flows

Publicus - UserFlows small.jpg

Based on the experience of one of the interview subjects described above, who had used Peerby to borrow a pair of ice skates, I focused a use case on a user’s need to borrow a specific item. As the first user flow above illustrates, users can take any of three routes to request to borrow an item: using the search function, browsing among items previously offered by other local users, and placing a request to the user community. The second user flow describes the process users employ after being notified of responses to their requests for items to borrow.



Publicus - SiteMap small.jpg

Card sorting exercises were conducted among seven test subjects to inform the information architecture of the application. While normally a much larger number of test subjects are recommended, there was strong similarity among all of the sorts performed for this project. The resulting sitemap is above.

Based on user flows and the above sitemap, I began sketching prototype screens.



Publicus - Sketches.png

Annotated Wireframes

The above wireframes describe the walkthrough and walkthrough browsing processes as well as the registration process.


User Testing

Publicus - UserTestingPhotos.png

On early iterations, users had the following feedback:

  • While walkthrough screens were clear, map view detail pop-ups were illegible.

  • Question mark and exclamation point icons that were initially used on both map and list views were cluttering the interface, and their meaning was unclear.

  • Language in walkthrough screens needed to be more active, engaging, and specific.

  • While there was a clear happy path for the testing use case, the app needed to respond to users’ urge to use a search function and inclination to filter list views.


High-Fidelity Screens



Give the prototype a try. And please feel free to reach out to me at with any recommendations for improvements. I love to get actionable feedback.