Soon after Apple’s WWDC keynote in July 2016, Apple released features that allowed 3rd party apps to couple more tightly with the iOS 10 (e.g. iMessage and Sirikit). And since Venmo is always looking to make our customers’ lives easier, this seemed like an opportunity worth exploring.
This case study will only focus on iMessage. My role as the lead and sole designer on this project was to conceptualize and execute from beginning to end. The project team consisted of a PM and a few engineers. This project shipped on September 13, 2016.
Aligning with Venmo’s product vision
An iMessage integration made sense for our product because of two main reasons:
(i) Since our users already have conversations with each other both before and after making a payment, a Venmo — iMessage integration enhances a preexisting behavior.
(ii) Our vision is for Venmo to be accepted everywhere in the future. This means that Venmo transactions will take place outside the Venmo app in the context of other interactions. This could potentially mean paying people on other platforms and merchant stores/apps. Integrating Venmo into iMessage is a step towards that vision.
Building a relationship with Apple
We pursued this project because we had the opportunity to establish a business relationship with Apple.
This was important to us because of the potential future partnership opportunities.
Goals and Design Principles
Given this, we created design principles to help guide our decisions for this project.
Venmo in iMessage should be a product that…
- Improves the experience of paying someone outside the Venmo app
- Acts as a bridge that connects users to Venmo’s app experience
- Easily facilitates a payment in the context of a conversation
Before brainstorming ideas, we thought of use cases where Venmo might be used within iMessage. The themes were split into two groups: (i) making payments in a thread with a single person; and (ii) making payments in a group thread.
- Individual thread: Paying a specific amount (e.g. “I’m paying you $10.”)
- Individual thread: Requesting a specific amount (e.g. “Pay me $10.”)
- Group thread: Payments to one person in a group chat (e.g. “Johnny, I’m paying you $10.” or “Johnny, pay me $10.”)
- Group thread: Group requests (e.g. “Everyone who owes me money, pay me $10.”)
- Individual or Group thread: Open requests (e.g. “Contribute something if you want to.”)
North Star and the Ideal iMessage Experience
After a quick round of brainstorming and user testing, we came up with the ideal experience for making payments in iMessage for each theme we identified:
(Note that because of the tight timeline, we started on this project very shortly after the WWDC keynote on iOS 10. Because of this, we didn’t yet have full knowledge of iOS 10’s quirks and constraints. Thus, this iteration was based off of the project team’s best educated guess of the new framework.)
Constraints, Constraints, Constraints…
As we iterated and tested, we ran into many constraints that eventually turned into roadblocks. There were numerous design and time constraints, but the biggest hurdle was a technical constraint with devices accurately identifying participants in an iMessage thread.
Identifying participants in an iMessage thread
iMessage’s privacy model prevents Venmo from explicity identifying participants in a chat. Instead, each chat participant on each device is assigned a unique UUID; that unique UUID is strictly unique (in a chat between 2 people, there are 4 UUID’s, two for each person). And to further complicate things, the same conversation, extended to another device (e.g. perhaps a tablet, or watch) will add another UUID for the participants.
Basically, with the current iOS 10 framework, it was not technically possible for Venmo to automatically identify participants in an iMessage thread. In order to solve this problem and have an MVP ready by our target date of September 1st (which was less than two months away), we decided to focus on only one of the use cases we identified earlier: making a payment in a thread with a single person.
Brainstorming Ideas and Testing
We ran through a quick design sprint to brainstorm and test potential workarounds for not being able to identify participants in an iMessage thread. Given the constraints, we concluded that the four best options were:
1. Implement a “handshake model” in order to identify the person in an iMessage thread.
2. Make payments in iMessage “open payments” that need to be redeemed.
3. Search through Venmo friends in iMessage before making a payment.
4. Request that Apple change their framework, 💀.
1. Perform a “handshake”
This idea involves two devices trading identification, establishing a connection (i.e. handshake) and Venmo storing that information for the future.
The advantages of this idea were that the experience “made sense” and was the most easily understood out of all the ideas. The biggest con was that this model presented a lot of edge cases on the engineering side that would make building this in such short period of time very difficult.
2. Redeemable payments
Redeemable payments are simple to understand: Send an “open payment” (i.e. a payment without a recipient) that is redeemable by anyone.
The advantages of this idea were that Venmo didn’t need to know the participants in an iMessage thread and, based on our user testing, people understood this model fairly easily. However, the biggest downside was that we would have to introduce a new model to pay people since payments in Venmo weren’t redeemable. Also, creating redeemable payments in a group thread seemed like a very odd interaction.
3. Search and pay
This model requires a person to search through a list of their Venmo friends and select the correct recipient all in iMessage before being able to send a payment.
While testing this solution, we received a lot of feedback that people would “rather go to Venmo instead to make a payment because it’s easier.” A lot of people were not convinced a “search and pay” feature would provide any significant value to them as they could simply complete the payment in Venmo. Also, there was worry that it would be fairly easy to pay a wrong person, a big issue that already exists with Venmo.
4. Request that Apple change their framework
Deciding on a Solution
Based on our goals, constraints and testing, we decided to move forward with “redeemable payments” and “search and pay”. We continued to test these two solutions while getting advice from Apple. After much deliberation, we ultimately decided to move forward with “redeemable payments” because (i) it was the least complex solution to build, (ii) it would allow us to hit our target ship date of September 1st and (iii) it provided a user experience that people found value in.
What We Shipped
This is the final flow that we decided to ship for the iOS 10 release.
New interactions and existing features
In order to add some delight to the iMessage extension, we decided to include a new interaction for inputting numbers on the payment screen:
This is something that we plan on bringing over to our apps.
We also decided to include Venmo’s “emoji autocomplete” feature, since emojis are such an integral part of Venmo:
Meeting Our Goals and Getting Featured
In the end, Venmo was featured in Apple’s App Store. Subsequently, we became the #1 free finance app, and we were featured in the finance section (ranked #83 on the Top Chart for all free apps). Venmo also hit an all-time record for signups during this time.
We’ve also established a positive relationship with Apple and plan to work with Apple on future opportunities.
Lessons Learned and Other Thoughts
How do we bring people into the app?
I mentioned earlier that Venmo’s vision is to be accepted everywhere. This potentially means that payments will happen outside of the Venmo app. With more integrations outside of the Venmo app such as iMessage we realize that we have to create enough value in our app through things like splitting, sharing, offers, better receipts, etc. to bring people to the app pre and post payment/purchase.
The main narrative of this story was how we overcame constraints. This was the first time that we had to work through these unique obstacles. Balancing business, technical and design goals is truly an art, not a science.
Thanks for reading! 🙂