Loro Piana
Cashmere Crewneck Sweater
$1,595
Web app · Luxury gifting
DADO is a luxury gifting platform. I own its 0-to-1 product design for all three launch products, plus roadmap priorities and the QA operation. I’ve worked with a 14-person team through launch.
To respect DADO’s NDA, some specifics are omitted here and shared only in interviews.
TEAM
14-person team, through launch
+8
TIMELINE
Jul to Sep 2026
TOOLS
Figma · FigJam · Airtable · Asana · Amplitude · React / TypeScript · Claude Code
Outcome
Launched to 5,000 invitations, drawing 4,100 users and 41,400 tracked events at a 7% bounce rate on the landing experience. Behind it, 150+ mobile-first flows across three products, shipped in under 3 months.
150+
mobile-first flows shipped in under 3 months
4,100
users from 5,000 invitations
41,400
tracked events from the launch
7%
bounce rate on the landing experience
What launched.
DADO is live. It launched invite-only, with 5,000 invitations sent. DADO is built for a luxury audience, and invite-only was a deliberate choice. It let us watch the product perform in a live market and fix what broke before opening the doors wider, and for this audience exclusivity is part of the product.
Five steps behind every product.
PRD
Where every product starts
Every product on this page starts as a PRD before a single screen exists.
User flows
Mapped in FigJam
The PRD becomes user flows in FigJam. The Accounts board opens in the Accounts section below.
Information architecture
The map below
The flows sit on the information architecture mapped below.
Sketches and wireframes
Pencil to frame
Screens start as pencil sketches before they touch the design system. This one is step 1 of the One Big Wish wizard, with the consent modal a parent fills in when the wish is for a minor.
Hi-fi on the design system
Shipped
Hi-fi screens use the design system below. I pair Figma with Claude Code, and the engineers and I take each screen to production in React, TypeScript, and Tailwind.
dado /
Editorial system · 60+ pages
/dado-presents/…
24 routes
Beauty splurgeBuys his own thingsComfort careDads having a momentFine and foreverFragrance wardrobeFragrance wardrobe · herFragrance wardrobe · himGoop got to herGot into pilatesHostess giftIt's not about the tennisJust started datingMétierNew momPuppy love, no budgetRich aunt energySelf-care is not clichéSomeone else's childrenTale of two housesThe bossThe friend with better tasteTreat yourselfWanderlust
Gift taxonomy · 20+ categories
Categories · 8
Fashion & AccessoriesJewelry & WatchesHome & LivingBeauty & WellnessGourmet & SpiritsTech & InnovationArt & BooksExperiences
Occasions · 10
ChristmasRomantic GiftsBirthdayAnniversaryWeddingMother's DayFather's DayGraduationHousewarmingThank You
Recipients · 8
The MinimalistThe AdventurerThe ConnoisseurThe AestheteThe HomebodyThe Tech EnthusiastThe Wellness SeekerThe Collector
Figure 1. The information architecture map, the editorial system on top and the gift taxonomy below.
Accounts, the consent architecture.
Accounts is where a person’s profile, wishlists, gift history, and sharing live. Sharing started out per list: one visibility setting covered a whole wishlist, so everything on it traveled together, and that leaked. The rebuild closed those privacy gaps across the platform with per-item visibility on a two-tier audience model, close connections and connections, with Only me for anything unshared. It’s enforced in the UI and again in the database’s RLS policy, across wishlists, gift history, and every share link.
PER-ITEM VISIBILITY
Each item carries its own audience: Only me, close connections, or connections.
CONSENT-GATED INVITES
Occasion invitations are consent-gated. No one lands in an occasion without accepting it.
GIFT HISTORY AT 18
A child’s gift history transfers to them at 18, and prices and notes stay withheld.
Two-tier audience model
Two audiences, plus Only me
Only me
Close connections
Connections
Figure 2. Profile visibility on staging: each section has its own audience picker, and occasions and preferences carry their own.
Figure 3. One branch of the Accounts user-flow board, My Gifting with its empty states. Open it for the full board.
One profile page for each person
Three separate views of the same person had drifted apart: a pop-up, a gift history entry, and account details. I merged them into one autosaving profile page that shows who added each detail. The same pass split the private save list from the public wishlist.
One Big Wish: a wish funded by the people around you.
In One Big Wish someone asks for one wish of one to five products, and their people pledge toward a goal set by the item prices. A five-step wish wizard and a four-step contribution rail, on Stripe saved cards. The payments protect contributors from paying for a gift that’s never bought: pledges save the card with an authorization, bigger wishes verify the wisher’s identity, and nothing is charged until purchase. Every error, empty, and edge state has a designed path. The payment model, the wizard, and the progress bar have their own case study.
THE RULE THAT SHAPED THE PAYMENT DESIGN
Everything downstream follows from that one rule: contributors see a non-refundable disclosure before they give, nothing is charged at contribution time, cards are charged in one batch 7 to 10 days before the moment, and a missed goal still has to end in a gift.
When a goal is missed, the wisher chooses how it ends:
Goal missed
$38 of $766.26 pledged when giving closed, with no card charged yet.
Complete it yourself
Pay the remaining amount and the wish is fulfilled as planned. DADO buys the pieces and the brand ships them.
still ends in a gift
Keep what you raised
The raised amount becomes a digital gift card. Claims run through the account that created the wish, so the card can only reach the wisher.
still ends in a gift
Do nothing
The gift card is the default after the response window, so the wish never dead-ends.
still ends in a gift
Figure 4. The under-funded fork, with three exits that each end in a gift.
One Big Wish case study →
The Edit, luxury you can browse.
The Edit is DADO’s editorial face, built so discovery feels like reading a magazine and still lands on a product you can gift. Every page runs on the design system, so the tone holds across every guide and category page. Behind it sits a pipeline: editors plan guides in an Airtable calendar, and each entry flows into a templated page on the site.
Figure 5. Editorial surface, commerce underneath: The Edit, gift guides, DADO Editions, and DADO Presents, captured on staging. Open any one to see it full size.
One design system under every product.
I authored the Figma design system in full: variable collections, tokens, component libraries, responsive breakpoints for phone and desktop, micro-interaction patterns, and transactional email templates, with documented WCAG 2.1 AA standards adopted across product surfaces. DADO is built AI-native, so the system also lives in the repo as DESIGN.md, the file every AI coding session loads before touching the product. Its design-system half is derived from my Figma collections, and designers and engineers both edit the file. The contract holds:
✓
Two typefaces.
✓
A closed color palette.
✓
Zero default radius.
✓
A section titled “What Claude Must Never Do.”
Every AI coding session starts with the same tokens and rules, so design review starts with the same baseline. Engineers build from the PRDs and the design system, and I review each build against the designs. I also mentor the 3 designers hired since, through critique and design review against the same system.
Figure 6. The Figma variables collections (Primitives 123, Theme 77) and a DESIGN.md excerpt. Open the variables to see the full table.
The QA workbook, rebuilt against the real routes.
I restructured an earlier 144-case document against the actual codebase routes into a 308-case workbook across nine sections, so coverage claims matched real screens. Every flow is QA-tested on phone, tablet, and desktop.
0144
test cases in the workbook
0
sections of the workbook
Intake runs through Asana: a tester’s form entry becomes a routed developer task, so discovery to fix lives in one system.
Figure 7. The QA workbook after the restructure: 308 cases, up from 144, in nine sections, with Asana intake.
Together and Overture come next.
Together and Overture are designed and follow the launch.
Together
Group gifting: several people give one gift together for an occasion.
UPCOMING
Overture
One-to-one gifting where the sender never sees the recipient’s address, because DADO holds the address and fulfills the order.
UPCOMING
Picture an employee sending their boss a thank-you gift. The gift arrives, and the home address stays with DADO.
Sender
Picks the gift, pays, writes the note
DADO
Holds the address and fulfills against it
Recipient
Shares their address with DADO only
The gift
Gift
The address
Address
Never sees the address
The only party that holds both
Receives the gift at home
Figure 8. The Overture address boundary: what the sender sees, what DADO holds, what never crosses.
Where things landed.
DADO is live. What I’m watching next:
Invite acceptance rate
The first read on the invite-only bet.
Wish creation per active account
Whether the people who get in create wishes.
Contribution completion rate on wishes
Where the four-step rail loses people, if it does.
The under-funded rate
How often the fallback fires determines how much that flow matters.
Project takeaways.
01
Start every product on paper
PRD first, then flows in FigJam, then screens. The order held for every product on this page and kept scope decisions ahead of pixels.
02
Enforce consent wherever the data goes
Set visibility on the smallest unit people share, and enforce it below the UI. Per-list sharing leaked, so per-item visibility is checked in the database policy as well as on screen.
03
Keep one source of truth for the design system
The Figma variables are the source. Exported into DESIGN.md, they give every coding session the same tokens before it writes anything.
Next case study
One Big Wish, a pledge that has to survive months
Read the case study →
Anchal Nagdev