For my second project in General Assembly’s UXDI course, I was asked to work with a team to add a feature to a pre-existing an app. My group was assigned letgo, a Craigslist-type app where people can buy and sell local used items. The app facilitates easy browsing, posting and in-app messaging to organize meet ups, however, users are currently required to organize payment between themselves. We were tasked to add the option of an in-app payment system within letgo that would allow users to transact easily and safely within the app.
We first needed to identify our users. We wanted to interview people who regularly purchased or sold used items online and people who comfortably used app-based payment service like Venmo, Applepay, and Paypal. We created a screener and of 38 responses, we chose 8 people to interview. We asked our users to describe an experience purchasing or selling a used item, where the transaction occurred, what kind of payment was used and most importantly, how they felt safe transacting with a stranger. We also asked about their habits using app-based payment services, when and why they use them and how they know their financial information is safe and secure. We wanted to uncover what would make our users feel safe inputting their financial information into letgo and using it to transact with strangers.
After our user interviews, we began affinity mapping- a process for finding patterns and uncovering insights in user research. We pulled out quotes, wishes, frustrations and behaviors from each interviews and wrote each down on a colored post-it note. Our groupings revolved around three main themes: safety, convenience, and control. Some key insights from this process were: “I trust an app when others do,” “I expect institutions to resolve issues” “I like to limit my digital footprint” and “I’m pretty laissez-faire about my information.”
From these insights we developed two personas: Jamie and Pat. Jamie represents our digital native users who consistently use app-based payment systems and who place most of their trust in peer approval of an app or service. Pat represents our users more wary of sharing information, who prefers cash but might be open to an in-app payment system if he knew his information was safe and if their was a plan for recourse. We definitely had a lot of difficulty in forming these personas and one of our next steps would be to do more interviews with actual letgo users to more fully flesh out our personas.
The final step before we started to design was to create a problem statement that would define what we planned to solve. We chose to focus the statement around Jamie, our main persona based on the demographic of people we were able to interview.
Jamie is a digital native that likes using apps to buy and sell used items. She uses payment apps between friends, but doesn’t feel comfortable using them with strangers.
How might we facilitate convenient digital transactions that allow Jamie to feel safe and in control?
To begin the design process, we needed to choose which features would solve our problem statement. We began by doing three design studios that focused on saving payment information, safety features and making a transaction.
Once we finished our design studios, we made a list of features and plotted them using the MoSCoW Method (Must, Could, Should, Won’t).
We then moved our post-its to another feature prioritization chart that plotted our features on a y-axis of essential to nice-to-have and an x-axis of low effort/cheap to high/effort expensive. The actual process of physically moving each post-it from one chart to another was extremely effective in forcing us to examine each feature fully and defend its placement on the chart. We were lucky enough to be able to do this process next to our affinity map, so once we had placed our features, we made sure to back up each feature with insights from our research. Based on both charts, we came up with a list of user flows: (1)completing a transaction (2)disputing a transaction (3)saving payment information.
Next, we needed to merge our sketches from the design studios and create lo-fidelity paper wireframes.
We quickly moved to mid-fidelity wireframes, putting our designs into sketch so we would be able to create an inVision prototype.
Once we had our mid-fi wireframes, we created a linkable inVision prototype and began usability testing. We did three rounds of testing, with five participants per round and 5 tasks for each user to complete. We asked users to (1)save their payment information to their profile (2)execute an in-app transaction (3)leave a review of the seller (4)dispute a transaction (5)accept payment for an item. Between each round of testing we reviewed our notes and made changes both in the flow and with increasing the fidelity of the wireframes. Based on user feedback we iterated on the profile screen, making it easier for users to find their saved payment information, view items they had bought, and actually hit the settings button (since it was too small!)
We also iterated on the make payment screens, allowing users to add a payment while mid-transaction and we added a pop-up that reminded users to only make a transaction when they were standing face-to-face with the seller. The main change we made was adding a “Make Payment” button to the home screen. In the first round of testing, we found that users did not like going through their messages to make payments so, through each round of testing we worked to resolve that issue.
Next Steps and Final Thoughts
One of the comments we received from our presentation was that we did not focus our features enough on our original goal of safety. Based on the demographic we interviewed, people between 20–35, most of our users cited peer approval as the main source of trust when using payment services. Not many people had real concrete reasons for choosing one service over another beyond “everyone uses it.” In our next steps, we would like to do more user interviews to get more information about what features make users feel more safe when transacting online and we would also like to do more competitive research with companies like eBay.
We also had trouble with some of the design choices already within letgo, specifically redundant buttons and too-crowded screens that made it difficult to find space for new buttons or icons. We would like to specifically do A/B testing with the “Sell Your Stuff” button on the homepage of letgo which proved confusing to users and redundant to the camera icon directly below it in the navigation bar.
This project was a great learning experience for a couple of reasons. It was our first project working in a group and it was really interesting to see how other people approach the same problem and how together, we were able to create a collective design. I also learned the importance of being confident in your research and personas before beginning to design. The research and synthesis were definitely the hardest parts of this project for our group and due to limited timing, we had to move on to our next steps. Had we had more time, we would have benefitted from spending more time with collecting research and creating our personas.