PayBack

Tools

Figma

Figjam

Role

Research

UI Design

Visual Design

Timeline

October - December 2022
(8 weeks)

Deliverables

Prototype

Team
Hala Canada

Mekayla Martin
Nicole Kadom
Sarah Subero
Lauren Deloach

Approach

Lean UX

Project Overview

PayBack is a financial app that allows friends and family to create reimbursement groups that split payments between one another, send notification reminders, and seamlessly transfer money into their bank accounts.

Approach

In collaboration with four other teammates, this project was created through the Lean UX design method. Lean UX is a collaborative design approach that focuses on continuous interations of design and user feedback.

Challenges

PayBack was guided by four main objectives to assist in achieving user goals:

1. Allow users to create groups based on outings or events
2. Allow users to make payments between one another within groups
3. Allow users to create and request payment reminders
4. Allow users to securely link bank accounts and credit/debit cards

Introduction

Imagine a time when you and your friends wanted to see a movie at the theater. Usually, each friend buys their own ticket and everyone works together to coordinate seating. However, you know that the process of trying to snag enough seats for everyone to sit together can become quite complicated. Instead, you offer to buy all the tickets yourself to make the experience more seamless.

To get reimbursed, everyone would normally send you their money via Venmo, Cashapp, or Zelle. But that can get tiresome and complex given all the money coming from different apps and waiting for each amount to deposit into your bank account. What if there was an app that allowed you to make a group with all your friends and input the total ticket price, then split the amount evenly among one another?

That’s why for our project, my team and I created PayBack, to solve a real-life problem similar to the one above.

Lean UX

In this project, my team and I used the design framework, Lean UX. This methodology, created by Jeff Gothelf and Josh Seiden in their book Lean UX: Designing Great Products with Agile Teams, is a combination of UX, Lean, and Scrum methodologies. For better understanding, the methodologies are defined as -

  • UX (User Experience): the process of how a user interacts with a physical or digital product
  • Lean: a practice that emphasizes continuous iterations to reduce project risk and resources while working on a product
  • Scrum: an Agile technique used to structure continuous progress while working on a product

Through these three foundations, Lean UX is an approach that is collaborative (with non-designers), user-centered (understanding their needs), and allows for continuous learning to improve products (Gothelf & Seiden, 42).

Assumptions

An important concept that Gothelf and Seiden discuss is assumptions, strong a guess of an idea that is perceived to be true. As designers, we initially start with assumptions on “how best to achieve a user’s goal” (Gothelf & Seiden, 75). Instead, they teach that we should “express ideas in a new way, as testable assumptions” through an exercise called the Lean UX Canvas (Gothelf & Seiden, 76).

Lean UX Canvas

The Lean UX Canvas allows team members to discuss their assumptions about the project to build shared understanding between members. The canvas “guides the conversation from the current state of your product […] to its desired future state…” (Gothelf & Seiden, 78). It is broken down into eight sections: Business Problem, Business Outcomes, Users, User Outcomes and Benefits, Solutions, Hypotheses, Most Important Thing to Learn First, and MVPs and Experiments. I will go into further detail about each section in Design Week 0.

Sprints

Our project is broken up into Design Sprints, which is a process where teams develop ideas, build prototypes, and test those ideas and prototypes, all within a week. Design sprints allow us to complete the iterative process of Lean UX by generating new ideas, testing our prototypes, and gaining user feedback on those ideas. Sprints are normally an ongoing process, however, because of our 8-week class constraint, our project was condensed into two sprints (consisting of two-Design weeks).

My process page will outline our two design sprints and how we used the Lean UX framework to create our PayBack app.

Sprint 1

Design Week 0

During Design Week 0, my team and I discussed our assumptions that were based on our initial ideas of the target users for our app. We used the Lean UX Canvas to organize our assumptions into their respective sections. Our canvas was completed using FigJam, a whiteboard collaboration software by Figma.

The Lean UX Canvas is broken down into eight sections: Business Problem, Business Outcomes, Users, User Outcomes and Benefits, Solutions, Hypotheses, Most Important Thing to Learn First, and MVPs and Experiments.

Box 1: Business Problem

The first step in the Lean UX Canvas is Business Problems. The Business Problem section is a way to define the problem for stakeholders and our target users. In our class, we did not have any stakeholders, so we imagined our team leader to be the stakeholder and gathered the problem that they wanted to solve with our project.

To help us break down the problem statement, we completed the exercise provided by Gothelf & Seiden in the book (89):

1. The current state of [the domain we are working in]
2. Has focused mainly on [these customer segments, these pain points, these workflows, etc.]
3. What existing products/services fail to address is [this gap or change in the marketplace]
4. Our product/service will address this gap by [this product strategy or approach]
5. Our initial focus will be [this audience segment]
6. We’ll know we are successful when we see [these measurable behaviors in our target audience]

After completing the exercise, we created our business problem statement:

The current state of mobile payment apps has focused primarily on sending or requesting money between a single individual. What existing services fail to address is how users can easily split payments among a group of people securely. Our app will address this gap by creating a smooth and intuitive interface that allows users to create groups and split payments among group members with only a few steps. Our initial focus will be young adults, as we determine they are the likely demographic to frequently split costs in groups. We'll know we are successful when our app's download rate and activity shows a steady increase.

Box 2: Business Outcomes

The next step was to create business outcomes through an exercise called “Outcome-to-Impact Mapping”. In this section, we continued to make assumptions to develop ideas of how we will know our app is successful. Particularly, we had to identify our leading (behaviors we want to see) and lagging (behaviors that we can measure) outcome metrics in order to determine the impact metrics (success).

From this exercise, my team and I decided that we wanted Consistent Downloads, Profitability, Customer Satisfaction, and Active User Accounts as our impact metrics.

Box 3: Users

Step 3 was to identify our personas, a.k.a, our assumed target users. These proto-personas were created as assumptions and were subject to change as we implemented research and solidified our user’s goals. To create our personas, we followed the template provided by Gothelf & Seiden in the book.

We created two personas for our app: Layla Henderson, our primary persona, and Michael Labriola, our secondary persona. Layla Henderson is a college student who wants an app that will allow her and her friends to create groups and split money between one another, as well as stay organized with expenses. Michael Labriola is a corporate individual who wants an app as a way to keep track of expenses and transactions and split payment transactions between co-workers.

Box 4: User Outcomes and Benefits

The next step was to define why users would use and seek out our app. In particular, as Gothelf & Seiden states, we are trying to achieve a “shared understanding of users and a deeper sense of empathy for what they are trying to achieve…” (117).

To complete this exercise, we followed the guided questions provided by the book, which include: ‘What is the user trying to accomplish?’, How does the user want to feel during and after this process?’, How does our product or service get the user closer to a life goal or dream?’, ‘Why would your user seek out your product?’, ‘What behavior change can we observe that tells they’ve achieved their goal?’ (Gothelf & Seiden, 120).

We provided our answers to these questions down below:

Box 5: Solutions

Step 5 is where the team and I started to develop solutions that we thought would solve our business problem and reach user goals. To complete our solutions task, our teacher tasked us with creating an affinity map. For this process, we individually came up with our own ideas for solutions. We then came together as a group and put each of our sticky notes into collected insight categories. Some of our collected insights included creating a “split payments” button, app payment reminders, and two-factor authentication for security.

Pictured below are my insights from the exercise, as well as the affinity map displaying our collected insights:

Box 6: Hypothesis

Step 6 involved taking all of our assumptions (from our “raw” material) and placing them into testable statements for research (Gothelf & Seiden, 137). In order to do this, we gathered our material from the sections on business outcomes, proto-personas, user outcomes, and solutions. From there, we drafted hypotheses in the form of ”We believe we will achieve [this business outcome] if [these personas] attain [this benefit/user outcome] with [this feature or solution]” (Gothelf & Seiden, 138).

Once we finished that part, we then took each statement and placed them on individual sticky notes so that they could be organized on the Hypothesis Prioritization Canvas. This canvas was used to establish the risk involved with certain hypotheses. The Hypothesis Prioritization Canvas is split by Low and High Risk, separated into 4 parts: “Ship and Measure”, “Test”, “Don’t Test, Usually Don’t Build”, and “Discard”. Our hypotheses only landed in the “Ship and Measure” and “Test” sections. Since our app was so simple, we initially thought that every hypothesis statement would accomplish a user goal.

Box 7: What's the most important thing we need to learn first?

Once we completed the Hypothesis Canvas, we then established the risk associated with building each hypothesis. Discussing the major risks allows us to determine if each hypothesis has value in the project and is worth producing. If we determine that the value of a hypothesis is not needed, we can scrap that idea and not waste valuable time and resources. To complete this process, we asked the question: What’s the most important thing we need to learn first about this hypothesis? (Gothelf & Seiden, 147)

Once our risks had been determined, we then ranked each hypothesis and reordered the table with the riskiest hypothesis at the top of the list.

Box 8: MVP & Experiments

The final exercise in the Lean US Canvas asked us to determine the work that we were going to do on each hypothesis. We did this by answering the question: What’s the least amount of work we need to do to learn the next most important thing? (Gothelf & Seiden, 150). Our solutions explained how we would design each feature and how we would measure its effectiveness. In addition, each of our solutions became our MVPs, Minimum Viable Products, or in simple terms, a prototype (Gothelf & Seiden, 151). These prototypes would allow us to test and learn what is needed in the app to accomplish our user’s goals.

Note: Since this was a class project and we were limited in our resources, most of our answers were repetitive solutions.

Design Week 1

Stand-ups

Design Week 1, we hit the ground running. To keep the team on track and hold accountability, we completed standups every 2-days. Stand-ups are 15-minute meetings where the team leader discusses the to-do list and progress goals for the week, and allow team members to update the group on their progress with assigned tasks.

Wireframes

We began this week by creating wireframes in Figma using the MPV Table. Each group member was assigned a set of functions to prototype for the app. I was tasked with creating the Link Bank Account and Credit/Debit card feature. This feature would allow users to link their bank account and banking cards to the app, as well as update or remove the accounts they no longer needed.

User Interviews

During week 1, we also started conducting 30-minute user interviews. Each week we completed three interviews to test our prototypes and gain a better understanding of our project users and their goals. To conduct the interviews in a structured manner, the team and I created a set of questions to ask our users. The questions enabled us to have consistent and focused answers to compare results and help us with prototyping needed features. Our user interview groups consisted of individuals aged 20 - 40.

Affinity Mapping

After each interview, we completed affinity mapping exercises. In these exercises, we took our notes from each specific interview and placed them on individual sticky pads. We then moved the sticky notes into categories based on our collected insights for each user. The collected insights pointed to clear behavioral patterns and user needs when using a money-based app. The affinity maps helped us compare our assumptions to our user observations, which then guided us to update certain features within our prototype.

Design Week 2

For our group, Design Week 2 was very similar in structure to Design Week 1. We completed our 2-day standups, hosted three user interviews, and completed affinity mapping. During this week, we transitioned from working on wireframes to low-fidelity screens. We wanted to give people in our interviews a more developed prototype so that we could gain specific insights on sections. In particular, we wanted insight on app security and how users transferred money within competitor apps. Throughout this week, we also started making components and icons for the app and creating a cohesive brand.

Additionally, we completed a Sprint Retrospective, which is a meeting at the end of a sprint that allows teams to review and evaluate the past sprint and project progress. The book describes a retrospective as “[examining] what went well, what went poorly, and what the team wants to improve” (Gothelf & Seiden, 217). In our retrospective, we discussed some areas for improvement:

  • Improve communication of progress and coordination for meeting times
  • Improve our interview questions and revise them to be more open-ended
  • Make components so the app will look cohesive and consistent
  • Make a style guide

Sprint 2

Design Week 0

The beginning of a new sprint! Design Week 0 called for revalidation, which is going back over past work to determine what assumptions were correct and incorrect. Revalidation allows us to look back at our past assumptions and update them based on our gained knowledge from user interviews.

To begin the revalidation process, we went back over the Lean UX Canvas and made updates accordingly. In our Business Problem section, we found that certain assumptions we wanted to implement were not of concern to our users or feasible within this class. For example, we assumed that users only wanted one security measure and that security would be enforced in order to use the app. However, we learned that users would like multiple security options, from Pin, Face ID, and two-factor authentication, and they would like the option to activate either feature based on their lifestyle. In our Business Outcomes section, we removed “Profitability” as an impact metric because we determined that it was not a capable metric to achieve or measure in this course. Our teacher also guided us to refine our remaining impact metrics into “Growth”, “Customer Satisfaction”, and “Retention”.

We also updated our proto-personas. We removed Michael Labriola because we determined that corporate individuals did not have a need for this type of service. In particular, from our interviews, we learned that older users do not have a need for payment splitting and do not use money apps often. As a result, Layla Henderson was our only persona for the app. For Layla, we updated her image because we felt that the original image was too young to support our user age group.

Note: Our discarded assumptions were crossed out and changed to a gray color sticky note.

Design Week 1 & 2

Sprint 2: Design Week 1 and 2 followed the same structure as Sprint 1: Design Week 1 and 2.

Design Week 1

This week we focused on turning out low-fidelity mockups into high-fidelity mockups. We wanted to test our high-end designs in user interviews and gain insight into features that needed to be refined and designed differently. We also wanted to get a general sense of the flow of our app, in particular, with the login onboarding process. We wanted the process to be a seamless interaction between the user and the app so that they could add all the necessary information in a quick and timely manner.

Design Week 2

This week we focused on solidifying our brand design and refining our colors, components, icons, and overall brand cohesiveness. We also took the time to clean up the functionality of the app by linking pages and adding transitional effects where needed. We also tested our semi-complete app with user interviewees for certain page locations and app functionality insight.

At the end of this sprint, we completed another retrospective meeting where we discussed our areas of improvement:

  • Better communication
  • Clean up page Figma file
  • Use components and consistent brand (design and alignment) across the prototype

Conclusion

Lean UX taught me the power of iterative design and continuous progress. While fast-paced, I learned how to solve problems and not use my assumptions as the requirements for a product or service. I also gained a greater value in teamwork and communication. Both are key to making sure projects run smoothly and efficiently.

Challenges

  • Constant communication as a team
  • Project constraint in an 8-week time frame
  • Creating and maintaining a brand design
  • Understanding limitations with prototyping and meeting user goals

If I did this project again, I would interview more people of a variety of ages to gain more knowledge of different types of users and their needs for this type of app. I would also set internal deadlines with my team so that we could gain more concrete feedback from users earlier in the design process. Overall, this was a great learning experience and I felt that it made me a better researcher and designer.