DupeDupe

a social hub for product dupes

TOOLS

ROLE

Figma

Figjam

Microsoft Teams

UI Design

Prototyping

UX Research

Leadership

TEAM

TIMELINE

Bibilomo Sanni (Team Lead)

Jasmine To

Marcel Wheat

Rubin Liggin

Thomas Carson

January 2024 - April 2024 (8 weeks)

Project Overview

DupeDupe is a social hub app for clothing and makeup/skincare “dupes”. Dupes are budget-friendly substitutes for products. The inspiration for DupeDupe was the insurgence of social media users recommending dupes for products on apps such as TikTok and Instagram. DupeDupe takes on this idea but instead creates an organized hub where users can easily find a dupe they seek. I pitched this app idea in January 2024 and was chosen as a team leader to lead a team of four.

We designed this app for our Senior Capstone Project class, where we followed the Goal-Directed Design method. Our team spent about eight weeks working on this app prototype and eventually showcasing it during our Senior Showcase event.

Project Goals

  1. Create a space that allows users to find product dupes easily without going through multiple sources

  2. Prototype an app that prioritizes an organized information architecture for ease of browsing

  3. Undergo phases of the Goal-Directed Design method to produce a high-fidelity prototype after 8 weeks

Our Approach: Goal-Directed Design Method

Goal-Directed Design (GDD) was created by former software designer and programmer, Alan Cooper. GDD is a human-centered design process that provides solutions to meet users' goals and needs. Goal-Directed Design combines techniques of ethnography, stakeholder interviews, market research, detailed user models, scenario-based design, and a core set of interaction principles and patterns (Cooper et al., 24). This process is roughly divided into six phases 'Research', 'Modeling', 'Requirements Definition', 'Framework Definitions', 'Refinement', and 'Support'. However, we completed the first five phases of designing our prototype for this project due to limitations in having a cross-functional team to fulfill the Support phase.

Goal-Directed Design Phases

Research Phase

The research phase is a critical part in the Goal-Directed Design process. In this phase, my team and I needed to gather information to help determine and understand our users' needs. The research phase is divided into five sub-phases of the 'Kickoff Meeting', 'Literature Review', 'Competitive Audit', 'Stakeholder/SME Interviews', and 'User Interviews'. Due to the limitations of this class, we did not complete a Literature Review. Our starting point of this project began with our Kickoff meeting.

Kickoff Meeting

For ​our kickoff meeting, we discussed our plans and goals for our app. We used FigJam, an online collaborative whiteboard, to complete a kickoff meeting template. The template consisted of a problem statement filled with a theoretical problem a real-life company would have if creating our app. The template consisted of other questions responded to with assumption statements about the app and its users. The purpose of completing this kickoff meeting template was to imitate the kickoff process that would be held with stakeholders in real-world business settings. In defining our problem statement, we took on the role of stakeholders.

Competitive Audit

There are apps/services curated for dupes that are somewhat sparse but also concentrated within social media spaces. In working on our competitive audit, we decided to audit both social media apps where dupes are a topic of conversation and hunt for platforms that specifically promote dupes. We audited the social media app, TikTok, which posts about dupes are at a peak. Though it has many great qualities, its purpose is not for specifically finding dupes. We then looked into the perfume dupe website, Dossier, whose primary focus is selling budget-friendly dupes of popular perfumes. Finally, we audited the influencer reviewing app, Influenster, a platform that . Each of these three apps had both positive and negative qualities but none were specifically curated towards dupes of mthese elements needed to be combined to create an app that is a mix of social media and gratitude.

Stakeholder Interviews

Stakeholder interviews are meetings between the design team and those teams involved/have stakes in the project. Here, the design team would usually record, explain the project, and ask the stakeholders questions to gather information relevant to the topic. This gives an opportunity for the design team to gain insights that leads said project to success. As stated in the 'Kickoff Meeting' section, this project is for a class and we did not have any stakeholders present. Therefore, our design team took the role of stakeholders to imagine what might occur. We did this by filling out a FigJam worksheet

User Interviews

After our team concluded the Stakeholder Interviews portion of the Research Phase, we transferred our focus into user research so that we could see how our assumptions aligned with possible user goals. Before getting into interviews, our team must consider what kind of users would use our app. The GDD user Research Phase recommends creating a persona hypothesis to help decide who our candidates are for interviewing.

Our team looked for interviewees who were active on social media and knew about purchasing dupes and those not as online and might have never heard of dupes. Five interviews were held in total, either online via Zoom or in person. In these interviews, we asked interviewees their purchasing decisions, experiences buying dupes and questions on their perspective on product dupes.

User Research Participants

Collected Insights on an Interviewee

After each interview, our team completed an affinity mapping activity on FigJam. Affinity mapping gives designers a visualization of important relationships by simplifying the large amounts of information received from interviews. From our collected insights we were able to understand better who our user was and some of these nights contrasted with our initial assumptions of our users. Which helped move us forward to the modeling phase. Some highlights of these collected insights were:

  • The cost of items largely impacted their purchasing decisions

  • A lot of our interviewees read product reviews when purchasing an item but did not leave reviews

  • The majority of the interviewee’s perceptions about dupes were along the thoughts that cheaply and badly made products did not make a desired dupe instead products that were affordable alternatives were the type of dupes they desired

Modeling Phase

Identifying Behavioral Variables

​After gathering all of our research, we used this information to create a primary persona to represent the goals and needs of our targeted users. After the completion of the research phase of GDD, the next phase is the Modeling phase.

In the Modeling Phase, behavior patterns from user interviews are synthesized into user models, or personas. Personas are not real people but a re-design tools assembled from the behaviors, aptitudes, attitudes, and motivations we saw from our user interviews in the Research Phase. Personas help us understand and communicate how potential users of our app behave and the goals that they have. They are crucial for validating design decisions and informing designers and stakeholders what our users' needs are to keep our focus centered on users throughout the whole design process. Looking at our user research, we identified key behavior patterns.

Identifying Behavioral Variables on FigJam

We identified key behavior patterns using scales based on the questions we asked our interviewees, such as:

  • Frequency of shopping ( not often - - - often )

  • Loyalty to brands ( low - - - high )

  • Trust in reviews ( negative - - - positive )

Defining User Goals

Cooper suggests creating brief points to define users' goals based on the behavior variables identified. We first worked on synthesizing the characteristics of our user. This was a process of detailing the key behaviors into a user's actions.

Our team then defined four end goals (what the user wants to do) and a life goal (who the user wants to be) for our primary persona.

To give our persona more relatability, we brainstormed a name to identify them with. Using our synthesized characteristics and defined user goals we created our primary persona, Amelia Baker.

Amelia Baker

  • 22 years old

  • Works in retail

  • Charlotte, North Carolina

  • Recent college graduate

Persona Narrative

Meet Amelia, a young adult who spends her time working retail. She assists customers who are looking for help and organizes displays with precision. Amelia loves clothes, make up and other fun cosmetic products. Despite her knack for fashion, Emily is determined to be financially savvy and save for her future aspirations. Amelia’s passion for stretching her paycheck extends beyond just finding dupes. She's an avid thrifter, always on the lookout for cool, trendy vintage or Y2K clothes at bargain prices.

She also loves expressing herself through make up but it can get expensive. To stretch her paycheck further, she opts for dupes or duplicate products, carefully selecting alternatives that mimic the style of high-end brands without the hefty price tags. She regularly uses social media to find dupes and meticulously goes through reviews to help decide what dupe to purchase. Yet, navigating the landscape of dupes can be overwhelming and time-consuming.

Amelia dreams of a centralized hub where she can effortlessly explore and compare dupes for her favorite items, streamlining her shopping experience and empowering her to maintain her budget without sacrificing her sense of style. Such a platform would revolutionize her approach to shopping, allowing her to curate her wardrobe with confidence while staying true to her financial goals.

(Primary) Persona

End Goals, wants to be able...

  • To feel confident in their purchasing decisions

  • To purchase good quality items

  • To find trendy alternatives to name brands

Life Goal, wants to be . . .

Financially responsible and save money for the future

Experience Goal, wants to feel . . .

The convenience of being curated towards in their shopping experience

Requirements Phase

Following the modeling phase and the creation of our primary persona, our team needed to define our requirements. This is what is required for our application to help our persona to achieve their goals. To extract these requirements, we went through various steps to create a Context Scenario for our primary persona. A context scenario is a written series of interactions our primary persona would have with the Dupe Dupe app. 

In this phase, we also created a problem and vision statement. Our team had already created a problem statement during our theoretical kickoff meeting. So, we moved on to editing our original problem statement by adding more defined details. Meanwhile, our vision statement was centered on our users’ goals in relation to our app.

Problem Statement

The current state of the product alternatives or the “dupe” market has focused primarily on providing dupes without much organization or fact checking. What existing products/services fail to address is a central hub to find product alternatives with reviews that are quality controlled. Our product/service will address this gap by consolidating product alternatives into one platform.

Vision Statement

The new design of “Project Dupe Dupe” will help users achieve to find good quality alternatives to name brands and to feel confident in their purchasing decisions by allowing them to do access product alternatives in one platform and view trusted reviews with greater convenience, cost efficiency, and reliability, and without problems defective product alternatives, biased or sponsored reviews that they currently experience. This will dramatically improve user satisfaction while purchasing and confidence in purchases and lead to increased app usage.

​After noting our problem and vision statement, we took the time to brainstorm our ideas of our application’s layout and features. After brainstorming, we identified our primary persona’s expectations.

These expectations are based on users' attitudes, experiences, and aspirations. To do so we divided our persona's needs into ‘Data Needs’ and ‘Functional Needs’. We began to write our context scenario after defining our users' needs. For our context scenario, we wrote a series of interactions our primary persona would have with the DupeDupe app. 

​To conclude this phase, we finalized our Requirements List. A requirements list details the needs of This was done by extracting the information we wrote in our context scenario. This list was categorized by 'Requirements for Primary Persona' and 'General Requirements'. We reordered the requirements list in order of importance to wrap up this phase.

Our Requirements List

Frameworks Phase

Key Path Scenarios & Validation Scenarios

Following the requirements phase, our team began working on our low fidelity wireframes. These low fidelity excluded detailed features and colors. We focused on defining our prototype's structure. We used our requirements lists to create features; turning each requirement into an app feature. After wire framing we constructed our Key Path Scenarios. A key path scenario is the most used path or steps our primary persona will take while using our app. We used color coded arrows to identify the key path scenarios throughout our wireframes. 

Validation Scenarios are the less followed or used paths by users on an application. They are oftentimes more in number than key path scenarios. After adding items from the key path scenarios or validation scenarios to the wireframe, we crossed out the item on the requirements list. 

In this phase, our team hit a roadblock. After initially creating our low-fidelity wireframes we realized that our interface did not completely align with our persona’s expectations. These expectations were derived from the people we interviewed and most of them were avid online shoppers who were used to social media formats and looking through multiple reviews to make a purchasing decision. We originally thought the best solution for users to find dupes efficiently would be for us to provide dupes for them and create curated lists from what we thought were good dupes. However, once we saw our wireframes we realized this interface may not be appealing to users who would typically browse social media for dupes. After many long conversations, we decided to pivot. This of course as a team leader was a challenge especially as we were in the final weeks of the design process but we knew the importance of staying true to our user’s needs above our own assumptions. In pivoting, our application took a new form in its wireframes - we implemented a more social media feel and instead of providing dupes for users we gave users the ability to make posts of the dupes they discovered. We knew some issues might arise from this in preventing users from posting false information so we had to put in some safeguards such as a commenting feature and detailed input fields for posts.

Initial Wireframes

Refined Wireframes

Including commenting, an explore page, and detailed input fields gave users more of a community environment that our persona was already familiar from using other social media apps. It solved one of our main questions of how we would consistently update the lists of dupes on our application. Our pivot ended up creating a space by the users for the users. We maintained an organized interface by limiting our dupes to only fashion, makeup, and skincare finds. Through our interviews, we realized buyers of these types of products were our main target audience in the dupe market.

Refinement Phase

Refinement through Usability Testing

Next, our team moved on to work high fidelity prototyping on Figma. Previous to this most of our work in the previous phases took place on FigJam. In this phase, we also refined our prototype through Usability Testing.​

We performed three tests with participants from the Research Phase. I moderated these tests by explaining the app's concept, introducing the test, and asking questions. These tests were conducted remotely on Zoom. Each participant walked through the prototype while explaining their experience, and their likes or dislikes. Some of the insights we gathered included:

  • The price comparison of a dupe to an original product under a post looked more like a button than just copy. We noticed all our participants tried to click on this feature and expected an action to occur

  • The explore page looked too similar to a home page - the participants could not tell a lot of difference between these two screens

  • We did not prototype an animation that indicated the user’s post had been made and this confused participants if they post they made had been posted or not

Refined Explore Screen

Refined Price Comparison

Based on these insights received during usability testing, our team made refinements to our final prototype. We refined our explore screen by including more categories and imagery to differentiate from our home screen. We also refined our price comparison feature by removing the color background and instead adding in colored rectangles to prevent confusion that it was a button. I worked on including an animation that shows users they have made a post. For our final week working on our prototype, we went continuously through the flows to spot any design or prototyping errors we may have made and refined these too.

Conclusion

This was my first time working as a team lead on a project and I learned a lot from this experience. Having the privilege of being lead on a team allowed me to fully immerse myself in the design process and be hyper-conscious of all our design decisions. This experience allowed me to engage with teamwork in a new way where I had control in guiding our workflow and productivity levels. It also gave me more insight into the Goal-Directed Design methodology as this was my second time using this method but I gained further understanding this time around because I was leading a team. Overall, I found the design process for this project to be both challenging and rewarding.