Act 2: It’s A Group Thang


We are now into our second project of GA’s UXDI course, however it’s our FIRST collaborative one. In this unit I worked as part of a team, consisting of myself plus three of my peers! Apart from learning how to cohesively work as a small team, the four of us were tasked with integrating a new feature into an already existing app; the app we were assigned to redesign was letgo. Building from what we learned in Project 1, our two week unit pulled us head first into a whirlwind of user experience design, covering (but not limited to) the following: screening, user interviews, persona development, prioritizing features, designing both on paper as well as digitally, generating working prototypes, and all the while managing our group dynamics during the process.

letgo: Understanding the Product

For some very brief context, as the assigned application was also new to me, letgo is an online free, person-to-person, mobile app that allows users to buy and sell secondhand goods with others locally. According to the research firm Apptopia, it’s claimed that roughly 17.4 million people used the app monthly! Personally, I’d never heard of it prior to this project, so to better get a feel for what letgo is and how it works, we first decided to find some users who knew what it was all about!

User Research

We first determined that we needed to focus on gathering information to not only understand our users, but to also develop personas!


At the root of this, we were starting from scratch. This was the really the first step into finding a batch of users. We sent out the bat-signal to our personal networks in the form of a screener survey via Google Forms. We chose not to specify that we were doing a project solely on letgo, but rather built our screener questions broadly around secondhand goods (if you’d like to see the survey we sent out, here’s the link: We cast a wide net with this screener to reach as many people as we could, aiming to find potential persons to then call on for interviews. After receiving 120+ responses to the screener, we ended up contacting six of those responders, who agreed to be interviewed.

Topic Map

Before we spent the late afternoon / early evening jumping into interviews, we spent some time working on a topic map which helped us craft our interview questions! This exercise provided us the opportunity to put our minds together to address what we thought issues were/are and how to bring these topics up with our interviewees. I found this very helpful in putting together our thoughts visually before crafting our interview script.

Our team created a topic map before building out our interview script.

User Interviews

Our team of four now had six in depth user interviews to conduct. This was the catalyst to where we’d start our research; get to know these six individuals as best we could, find out how they’re buying/selling secondhand goods, and go from there! We developed an interview script to help lead these conversations. In an ideal world, we’d have conducted all the interviews in person, with two team members present at each (one conducting the interview, with another note-taking). But with some of our interviewees living in different states, a most of the interviews were held over the phone or via Facebook Video Messenger; subsequently, one or two of the interviews were conducted as 1-on-1, as we couldn’t have two team members at each interview.

This is me conducted an interview with a user in Florida via Facebook Video Messenger.

A few tips we included were making sure we made the interviewees comfortable right off the bat, request permission to record the conversations (for transcription purposes), and asking WHY more often than not. Of the six users, we spoke with five women and one man, ranging in age from their early-20s to mid-30s, living in NY, NJ, FL, and CA. Our team individually transcribed the interviews from audio recordings or rough notes taken during them. From here, our next step was to make sense of these findings.

Synthesis: Topic Map & Affinity Mapping

Using a technique we were introduced to during the first project, we gathered observations from our six user interviews and laid out our findings in (what ended up being a massive) affinity map. We first individually drew the most important observations from our interview notes, and wrote those out on post-it notes. Then added our collective post-its to a wall, to make sense of them all. We added our observations “silently” (or as best we could) in an attempt to mimic the Silent Generation method we learned in class; generating ideas silently encouraging diversity of ideas. Once all our “high-level” points made it on the wall, we then tried to break it down.

The team creating & categorizing our findings, into what eventually became a MASSIVE affinity map exercise!

We focused primarily on WHO our users are, WHAT they do/HOW they do what they do, and WHY they’re doing just that. Through this exercise, we were able to group our collective findings into some larger categories, including (but not limited to): budget, trust, the letgo experience overall, shopping habits (in general), payment methods, and the exchange of goods. From here, after synthesizing the most important and over arching components of what our users told us, we spent a hefty amount of time, developing our user personas.


Using the information and insights extracted from our interviews, we created two user personas to represent our overall users from here throughout the entirety of our project. Meet, Koko Wiley (primary user) & Bri Tarth (secondary user); please see their information below in the following two images. The level that we committed to our personas was rather impressive. As one of our instructors emphasized, we needed to be able to go to the mattresses for our personas, and we fully took on that role. Koko & Bri were just as much part of the team as the rest of us!

Meet our personas: Ms. Koko Wiley (our primary user) and Ms. Bri Tarth (our secondary user)!

Problem Statement

After Koko & Bri entered the team, we then sat down to create our problem statement. Boom, plain and simple; we needed to look at who our users are, and determine the problem at hand. For once we established the problem, then we’d be able to start solving/addressing the needs at hand. After SEVERAL iterations, we finally settled on our problem statement, which reads as follows:

Typically people buy and sell secondhand goods online with strangers.

Koko is concerned about her financial safety online when she’s unsure
about the trustworthiness of the second party. How might we help her
complete a secure, efficient transaction?

With this statement created, we were now able to hit the ground running towards developing solutions.

Feature Prioritization

Now with a problem on deck, it was time to ideate. To kick things off, we launched right into our first design studio.

Design Studio

This was the first point in which we were coming out of our preliminary research phase, and entering the design process. This allowed us an opportunity to visualize our research and rapidly generate many possible solutions. Firstly, we reviewed the personas we created. Then, with our problem statement in mind, we focused on Koko (our primary persona) and created a prioritized set of scenarios/tasks to design for asking ourselves “how might we” solve the problem using post-it notes. For this specific design studio, we ended up going with the following example: It’s Wednesday. Koko, 28, has arranged to sell her Kitchen Aide to Jake, 34, on Thursday after work, but he won’t have time to go to an ATM before they meet up. How might we help Koko and Jake facilitate an easy, secure payment? With this scenario selected, we then diverged by splitting up and ideating individually to create six to eight concept sketches on our own. The sketches we created were meant to elicit just enough to communicate our designs to the team, because we then had to PITCH our ideas to the team in three minutes or less. A few ways in which our team sketched ideas to pitch were in the form of screen flows, storyboards, and accordions. Being a pretty visual person, I preferred sketching out storyboards to convey my ideas. We gave each other three minutes to pitch out ideas, allowing only one speaker at a time, in an effort to avoid GROUPTHINK. We then finally converged and had a group discussion providing feedback on our pitches!

After a successful first round, we ended up repeating the process the following day and did a second design studio to further iterate possible solutions for the problem statement. We found dot voting to be a helpful tool for identifying a lead scenario in during our second studio. After all was said and done, we’d completed two design studios and created a hefty list of possible features that we’d consider including in our updated version of letgo; a few of the features were: developing a contract, a payment code, lock symbol for verification, algorithm identifies users common payment methods, user ratings, service fee only for credit card and 3rd party services (i.e. Venmo, PayPal), etc.

Our team Dot Voting (with pushpins) to prioritize a set of scenarios, and then pitching our ideas to the team after individually ideating.

Feature Selection: MoSCoW Matrix

Now that we had our features selected, it was time to actually prioritize them! We did so by exercising the MoSCoW Matrix method. This matrix method allows us to sort our features into four quadrants: MUST have, SHOULD have, COULD have, and WON’T/WOULD have. It was a very clear way of outlining our features!

(L to R): Initial feature placement to kick off the MoSCoW Matrix; the first iteration once reorganizing the categories and priorities.


User Task Flow

Once we’d sorted through our features, we then created a user task flow, one that Koko might hypothetically travel through from the entry point through the end of letgo.

A second iteration of our user flow with a few notations highlighted in green; the green notes were used when sharing the document for feedback between team members.

The user flow perfectly created a map to draw out the paper prototypes! It made it extremely easy to see which screens we’d need or not.

Paper Prototypes

Seamlessly from the user flow, came the paper prototypes of our concept! I really enjoy this stage of the process because you have a lot of freedom to start from scratch, can churn the paper screens out quite rapidly, and there’s really little time commitment spent. I prefer getting more wrinkles ironed out in this stage, before jumping into Sketch and Invision (which you’ll hear about soon).

Two shots of the same paper prototype screen, with different dropdown features represented by adding smaller paper cutouts.
An artboard showing the total of paper prototypes mimicking the main stages of the user flow (a few images above)

Digitizing our features: Prototype in Sketch

From this point, the paper prototypes were built out as lo-fidelity wireframes in the application Sketch. Sketch has some really impressive features to digitize concepts in a beautiful and quick way.

A series of lo-to-mid-fidelity wireframes created in Sketch, before moving onto Invision.

Digitizing our features: Prototype in Invision

After having translated our paper prototypes into a Sketch version, we were then able to link and sync up our Sketch wireframes into the more hi-fidelity application, Invision! This was at time tedious in getting all the frames lined up, but in the end really quite magical to see our letgo project come to life as a (draft but still) functioning prototype.

Please see a clickable final prototype of our work by following this link:

I’ve still got some learning to do within in Invision but I’m looking forward to (hopefully) mastering it over time!

Usability Tests

With Invision in play, we committed to conducting two rounds of usability testing, with four different usability tests each round. After the first round of usability tests, our group returned to discuss our findings/feedback from our testers, and iterated from there. Then, by increasing the productivity and fidelity of our already existing Invision prototype, we conducted our second round of usability tests. From there we iterated and enhanced a select batch of features, but left higher level/larger endeavors for future steps!

Out of our eight usability tests, we actually had two extras (including this one) which we conducted in class on a fellow peer.

Group Presentation

With two weeks complete, our group finally presented our findings to the rest of the class, to showcase what we’d been working on all this time!

Next Steps

In short, here are a few future feature design iterations that we’d consider including down the road: implementing service fee (based on Stakeholders’ input); user rating systems; penalty fees; and an more thorough instructional tutorial enhancement