5 things to consider when designing a peer-to-peer product

I recently had some challenges designing a shift trading feature for conference staff members to exchange their shifts. The conference has over 40,000 attendees and more than 3,000 workers who host and staff the event. To maximize the conference experience, we want every employee to be happy with their assigned shifts. We already had a system in place to assign shifts based on employees’ preferences of time and locations, but the system can’t always guarantee that people would get the time slot or area they would want to work. We want to design a system to allow employees to trade their shifts to ensure “maximum happiness” that employees bring to the conference.
When we talk about ‘P2P (peer to peer)’ here, we are talking about services that assist two types of users. For example, Uber and Lyft serve both drivers and passengers. They offer the platform for drivers to take passengers to a destination.
When we worked on this feature, there were so many good points that came out of the conversations. I want to share them with you. I also wrote down the story of when we designed this feature.
Don’t let the typical interaction model limit your design.
Think outside of the box.

When I started designing our shift trading service, I didn’t realize I mentally limited myself to a traditional trading model, where one person offers their stuff to trade, and others bid on it. Like Craigslist or eBay, when both sides agree on a deal, the trade is completed. There’s nothing wrong with this model. However, it wasn’t the best solution under our circumstances because it requires employees to spend too much time manually posting their trade and bidding on a list of open trades. That will cause employees to spend too much unnecessary time on the system while doing their job. More importantly, employees may miss their best chance of trading a shift in this manual process because it functions as first come, first serve.

When we finally broke outside of the box, we came up with a new model. Jokingly, I called it a dating (matchmaking) app model because much like a dating app, we let employees set their shift preferences, and the system would match them with other employees who have shifts that “matched” to that preferences (not like Tinder). This whole process is automated. Once employees put their shifts up to trade, the only thing they need to do is wait for the desirable shifts to show up in their schedule. There’s no need to look for what they want and go back and forth with bidding and accepting/rejecting.

Did we reinvent the wheel? In a way, yes, because matchmaking has been done before. However, to our team in the context of shift-trading, this was a novel idea that came about only because we were willing to think outside the box.
Think beyond the front end
Good UX may lie beyond UI.

With the new trading model we created, the system beyond the UI was where the magic happened. As the designer on a P2P project, you should think about the flow and process more than the UI you design because there are hidden opportunities.
A well-designed back-end system helps simplify the process and increase the chance of successfully serving our users’ needs. Let’s say if we present all the tradable shifts on the UI and let users initiate the trade on a first-come-first-serve cadence. Users will need to browse through many shifts, and they may need to come back often to check newly posted shifts if what they wanted is not there. That can cause users to spend too much time on tasks and nervousness of missing what they want. The back-end system can review tons of users’ requests in a second and find accurate matches or wait until what the user wants is posted, simplifying the user’s tasks on the interface.
When designing this, I was worried that I would add a burden to the development team because I don’t want to blow the project's scope with limited time. However, talking to engineers, I found that my “matchmaking” model is way easier to build than the “Craigslist” model, even though “matchmaking” requires a lot of backend system support. Still, as designers, we should always check with engineers to figure out the time and complexity of implementing a design. If it is an intricate design to build, you can run an Event Storm with engineers to sort out the details.
Think about the Edge Cases’ effect on all stakeholders
Design to encounter user errors and users’ unexpected needs.

When I refer to “edge cases,” I refer to extreme use cases and hidden use cases that designers or development teams missed.
Looking for edge cases is very painful, but we all spend time digging them out. Just like engineers always try to test out bugs and debug them. The impact of edge cases on P2P products can be more potent than other products because users’ behavior depends on each other. When one user makes an unusual decision, other users may get impacted. If you want to make sure both users have their best experience, there are edge cases from both sides. The tasks users want to complete are their shared goals. If one side can’t finish their tasks, the shared goal can’t be accomplished even if the other side completed their tasks. For example, if A wants to trade with B, A did all the steps, but B couldn’t complete the process. A and B won’t be able to deal eventually.
In our case, A may trade with many other people depending on who has the piece that A wants. To dig out those Edge Cases, we set up a “Breakfast,” a set time that all our department members get on the system and try to trade as many times as they can. (Breakfast, Break-fast, Break it fast, get it?) “Let’s see who breaks it first,” is what we tell people. In that “Breakfast” session, we found so many bugs and logic flows we didn’t think through. Once we fixed those bugs and designs, we tested it again with our department, and we found more bugs and design improvements. We ended up doing five “breakfasts” before releasing the product to be sure we encountered most edge cases.
Take advantage of the network.
Don't limit yourself to one person with another.

When we were brainstorming our shift trading tools, we start thinking, what if user A has what B wants, but B has what C wants, and A wants what C has? In the system, we can identify those needs and trade in a chain that might be very complicated to achieve from a UI perspective. However, this could increase the chance of successfully trading and help match as many people as possible.

We originally designed it for just one person trade with another one. However, in our “breakfasts,” we discovered the chance of matching might not be high enough to support most users. It is possible some users may not get a trade because a match depends on both users wanting each other’s shift. To maximize the chance of successful trading, we came up with the idea of chain trading. In chain trading, we can let A trade with B, B with C, and C with D. All four users will get what they want. The more users in a chain trading, the higher the success chance is. With this system, we can make sure more employees are happy with the shifts they get.
In some other cases, it can be three people or a group of people. Think about the Uber pool or Lyft line; they match more passengers to one driver to help passengers save money. When designing a peer to peer product, we should also think about peers to peers or peer to peers cases.
Credits to Kevin for coming up with this idea at our brainstorming sessions.
Understand user might have biases
Should users pick the match?

If we allow our users to choose which shift they want to trade with, what would happen when there is more than one shift with the same time slot and working area? How would users pick one over another? The same question could be asked if users can pick drivers when they call an Uber or Lyft. How would passengers choose one driver over another if they get the same rating, car model, and it takes the same amount of time to pick up the passenger?
What if employees get more shift trades in these situations, or some drivers may get more customers than others? It may create an unknown impact on the product and how people interact with the product.
However, in some situations, the system should let users pick what they want. For example, if the tool connects doctors to patients. It would be a plus that patients can pick doctors based on their expertise because patients may have specific needs that only individual doctors can fulfill.
When we design a peer to peer platform, we should think about whether or not the product should allow peers to make selections and what criteria we let users choose. Once we understand the needs behind choices, we can design accordingly to accommodate them and minimize biases.
I want to thank Nicole Hayashida and Chad Camara for reviewing and giving me feedback on this article.