DAPPA Technologies
AI virtual try-on that started as a mobile app before pivoting to a Chrome extension after struggling with traction. I led UX/UI design, directing 5 other designers and working with developers, marketers and PMs.
Role
Lead UX/UI Designer
Timeline
Feb 2024 - June 2025
Skills
Design systems
User research
Responsive design
Prototyping
Tools
Figma
Notion
Dovetail
TestFlight
Jira + Confluence
Problem
Online shoppers can't tell how a garment will fit or how it will look on them. That uncertainty is why people hesitate, order the wrong size, and send it back.
Solution
A Chrome extension that let people try a garment on while shopping, without leaving the retailer's product page.
DAPPA team, 2024
Existing company research with 282 shoppers showed that lack of visual confidence and fit uncertainty were the biggest barriers to purchase. Working in rapid build > measure > learn cycles, the product focused around three pillars: virtual try-on, price tracking and social sharing.
Design ran ahead of development, which is what happens at a startup with more ideas than runway. Virtual try-on and saved products shipped. The rest stayed in Figma.
224 users
were price conscious
190 users
struggle with fit & quality
146 users
can't visualise style
Price was the biggest finding and we built try-on first. Price tracking already existed in a dozen apps. Fit was the thing nobody had solved on the product page, and it was the only one of the three we could be better at.
Designed, not released
Where people dropped off
Try-on was our answer to fit. People stalled before they ever got to it, which is why the rest of this case study is about onboarding rather than the feature itself.
No proper research
UX research wasn't happening reliably. Decisions were often made on assumptions, with no dedicated researcher, and early designs were tested with people close to the team rather than recruited users.
I pushed to introduce more structured research and budget. We later ran moderated think-aloud sessions and guerrilla testing at UNSW, which is where most of our new findings came from.
No systems and structure
Designers, developers, and PMs were all working out of one tangled Figma file. I built the design system, file structure, and handoff workflow to keep files dev-ready and easy to navigate.
1 messy Figma file finally untangled: categorised, labelled, and version-logged.
Variables and tokenisation
Documentation for designers and devs
Mass componentised icons for consistency
The business model kept changing, so we tested a lot of directions. I worked on new features and on redesigns of screens we already had. Most were dropped for technical constraints, stakeholder pushback, or low traction.
A B2B dashboard aimed at retailers, which never found retailers. A wardrobe redesign that cleaned up a cluttered page but didn't move retention, because garment upload was the real constraint. In-app search, which wasn't relevant enough to drive discovery.
Three dead ends in a row is what pushed us to try somewhere we hadn't.
B2B dashboard, wardrobe redesign, in-app search.
After exhausting the earlier pivots, we landed on a desktop Chrome extension, DAPPA Clip. Somewhere we hadn't tried, with fewer technical constraints. The MVP let you try a garment on and save products to a list with their price. Price alerts were designed and never built.
One week, two people
Drag-and-drop
The standout was letting users drag garments directly into the browser, no saving to desktop then uploading, no roundabout steps. It felt natural to be dragging clothes onto your photo and seeing the result. I kept it simple: one main action per screen, everything else in the background.
Photo upload was clunky
Our AI engine needed a specific kind of photo to produce anything good. Full body, decent lighting, no overlap, no bulky clothes. That is a hard photo to take of yourself, with nobody to hold the camera. So I had two problems at once. Get people to a photo that met those conditions, and make it easy enough that they didn't give up.
Lengthy onboarding
Onboarding was the slowest part of the flow in testing. We watched people hesitate and lose momentum. Part of the reason was that DAPPA Clip still routed account creation through the older app, so new users were pushed through a sign-up built for a different product.
Lacked branding
The design was quite plain. We needed to build brand recognition, especially for a fashion company and to support marketing efforts.
We did guerrilla testing at UNSW during O-Week. We approached students who looked like they cared about clothes and screened them on the spot to check, rather than recruiting people we already knew.
We ran them from onboarding through photo upload to the virtual try-on. Fifteen people went through the MVP and completed a SUS survey afterwards, averaging 86.5 (the average SUS score is 68).
Guerrilla testing team
Upload confusion
"So I need a full body
photo, then?"
Lost at launch
"I downloaded it but...
how do I open it?"
Discoverability
"I forgot I even had
it installed."
Limits of the data
That SUS score was quite generous. We helped some users through onboarding during the sessions, which I noted at the time. The sample was small, skewed to students, and not all of them were high-intent shoppers. I treated the qualitative signal as reliable and the score as directional.
Onboarding is two flows: sign-up, then photo upload. They needed opposite things. Sign-up had too many screens. Photo upload had the right number of screens but too much happening on each one.
Sign-up
12 → 3
Photo upload
Same count, just rebuilt
6 → 6
Total onboarding
18 → 9
Original flow
Sign-up (12 screens)
Photo upload (6 screens)
What was wrong with it
The original sign-up asked for data we hadn't earned. Name, birthday, style preferences, favourite shops, all before anyone had seen what the product did. A company with a following can get away with that. We didn't have one.
The photo upload was overloaded rather than long. A video played on top of the written annotations, so people got two sets of instructions at once at the moment they were least sure what to do.
I cut sign-up from 12 screens to 3 by moving those questions rather than deleting them. Style preferences, favourite brands, measurements. The plan was to ask once someone had tried something on and wanted a better result, because that is the point where the question makes sense to the person answering it. I never got to build that second half. The company shut down first.
Redesigned flow
Sign-up (3 screens)
Pin prompt
Added pin prompt straight after installation. Testing showed people didn't know how to open the extension and forgot they had it installed, and pinning it to the toolbar solves both. This was a low cost and effective way to help traction and retention.
Photo upload (6 screens)
Handing off to the phone
Most photos live on your phone, so model upload opens as a web app with no install. It starts with a short try-on animation, a preview that gives people a reason to keep going. Then one large correct example, followed by the four mistakes that break it. One strong reference is easier to copy than a list of don'ts.
Trade off for a better photo
Moving model upload to the phone adds a device switch in the middle of onboarding, which is the kind of step I spent the rest of this project removing. I took it because the photo is the thing the product depends on. A bad photo makes a bad try-on, and a bad try-on is the reason someone uninstalls. One deliberate step to protect the output was worth more than a shorter flow that produced nothing usable.
The new sign-up, and photo upload were validated in another round of guerrilla testing at UNSW, and were still in development when the company shut down.
Total onboarding screens
1m 22s → 53s
Photo upload time
Photo upload success
150 → 1.5k
Growth in active users
“
