Designing a network product for the day it has no network.
A partnership marketplace where neighbourhood businesses send each other customers. This is the case study of its hardest week — the one where it has nothing to show anybody.
You’re the first business on this street
Invite the shops around you and your network starts here.
day one. zero partners. this is the screen that has to sell the product.
My role
A two-person team. I did the research, the design, and the build.
The founder brought the market and the field access — eleven years of relationships on the streets we were selling into. I owned everything from the first interview to the shipped binary: research, information architecture, interaction, interface, the design system, and the code. There was no separate engineering team to hand anything to.
That shaped the work in a specific way. Every screen I drew, I also had to build — so “can we afford this?” stopped being a negotiation with someone else and became a question I answered honestly with myself, usually the same afternoon. Several of the decisions below were made because the expensive version would have cost me a week I did not have, and I have said so where that is true rather than dressing it up as taste.
Discovery
- Ran virtual meetings with eleven owner-operated businesses in the first target cluster, sourced through the founder's own network, to understand how they actually think about partnerships.
- Audited the existing build against those conversations. The finding that reframed the project: nothing was missing. Thirty-three modules existed; they were arranged for a buyer who had already said yes.
- Mapped the four questions every owner asked, in the order they asked them, and used that order as the navigation.
Definition
- Rewrote the brief from “make the dashboard easier” to “make the first ninety seconds survivable when the network is empty”.
- Set the north-star metric with the founder: share of partnerships with at least one redemption in the last 30 days — not signups, not MAU.
- Locked three non-negotiables before a single screen: no disabled nav, no empty state without a next action, no screen that needs a laptop.
Design
- Designed the cold-start surfaces first and the logged-in product second — the reverse of the usual order, and the single most useful decision I made here.
- Compressed a 24-field terms model into three named deal templates, and pressure-tested each against the ledger rules so nothing I drew was un-buildable.
- Built the prototypes as running loops, not flat frames, so the founder could sell with them before the app was finished.
Build
- Wrote rules, not just screens, before touching code: cap arithmetic, pin-state logic, and the empty-state rule were specified precisely enough that build never meant re-deciding something mid-way.
- Built and shipped it myself — no separate engineering team. Two weeks of real-data review after; the negotiation-diff component and the counter flow both changed before release.
About the product
What it is, and who actually uses it
A hyperlocal partnership network. Small businesses on the same street agree to send each other customers: the gym’s members get a first-visit discount at the café, the café’s regulars get a free day pass at the gym, and each side caps what it is willing to give away per month. The benefit is redeemed with a phone at the counter, and both businesses get a monthly statement showing exactly what the exchange was worth.
The object at the centre is not a listing, a coupon, or a profile. It is a deal between two neighbours — and everything in the interface either helps make one, execute one, or prove one worked.
Two people touch it, and they want different things from it. The owner signs up, picks partners and reads the money — that is who most of this case study is written for. The customer on the other side of a deal never installs anything at all; they just show a phone. Most of the mistakes I had to undo in the existing build came from designing only for the first one.
Partnership network = proof your neighbours are here + a deal you can say out loud
The problem
A network product is worthless on the day it launches
The brief I was given was “the dashboard is confusing, simplify it.” The brief I found in the field was different and much harder. The engineering was ahead of the go-to-market: a complete partnership state machine, fit-scoring, a ledger, a redemption flow — all built, all working, and all of it pointing at a merchant who already had partners. On launch day, nobody had partners.
Every other product I’d designed could demo itself on day one. This one could not. A loyalty page with no points still shows a brand. A streaming app with no watch history still shows films. A partnership network with no partners shows a grey rectangle and the words “No data yet” — and an empty state is a refund request.
The empty room
A merchant opens the product on day one and sees zero partners, zero offers, zero redemptions. Nothing in the interface distinguishes “this is new” from “this is broken”, and the fastest read of a blank dashboard is that the purchase was a mistake. Nine of eleven owners asked a version of “who else is on this street?” before they asked what the product cost.
Built for the wrong day
A complete partnership state machine, fit-scoring, a ledger and a redemption flow already existed — all built for a merchant who already had partners to manage. None of it had anything to say to the merchant who had zero, which on day one is every merchant.
every screen in this product had to work at both ends of this curve — most of my time went to the left half
Research · quantitative
Survey: what I thought was true, and what held up
Before drawing anything I wrote down five things I believed about these merchants, then ran a survey to find out which ones were actually true. 63 responses from owner-operated businesses across four Kolkata neighbourhoods, collected over nine days through the founder’s own network and two local trade groups.
Stating the hypotheses first mattered more than the sample size. It meant the survey could tell me I was wrong — and on one of the four, it did.
Method
- Type
- Online survey
- Responses
- 63
- Field time
- 9 days
- Segment
- Owner-operated
- Area
- 4 clusters, Kolkata
H1 · Merchants want more customers, not better software.
validated
91% ranked “more walk-ins” first. Not one respondent picked “better reporting”, which the existing build led with.
H2 · They already trade favours informally with neighbours.
validated
74% said they already send customers to a nearby business. Only 6% had any record of it. The behaviour existed; the accounting did not.
H3 · Cost is the main objection to signing up.
partially rejected
Price mattered (38%), but “I don't know if it works” beat it at 57%. The objection was proof, not money — which redirected the whole retention design.
H4 · Owners will happily configure their own deal terms.
rejected
68% said they'd want “someone to just tell me a normal deal”. This killed the settings-first flow outright and became the three deal templates.
Research · qualitative
What eleven shop owners actually said
Eleven semi-structured interviews across one cluster, run as video calls over two weeks, scheduled around the owner’s day rather than mine. Sessions ran 12–25 minutes because that is genuinely all the time a working owner has. No incentives, no screener: the sample is whoever the founder could get on a call that week, which biases toward owner-operators and against chains.
I ran them with three fixed prompts (what did you last pay for and drop, who nearby sends you customers today, what would make you say no) and let everything after that wander. Names are changed; the sentences below are the ones I heard often enough to design against rather than the most quotable ones.
“Show me who on this street is already in it. If it's just me, why would I pay you?”
Gym owner, 41 — the first objection, every single time
“I don't want a website. I want the guy at the café to send me his customers.”
Salon owner, 36
“Last time I signed for something like this, I never found out if it worked.”
Pharmacy owner, 47
“How much can this cost me in a bad month? Tell me the worst number.”
Bookstore owner, 38
“Don't make me open an app. Send it to me on WhatsApp, I'll read it at night.”
Café owner, 44
How the quotes became decisions
Affinity-mapped the transcripts into 34 notes, which collapsed into nine themes and then into the four questions below. Two themes I expected did not survive contact: nobody cared about branding their own profile page, and nobody asked for analytics beyond a single rupee figure. Both had been treated as headline features in the existing build, and both got demoted.
Synthesis
Which compress into four questions, always in this order
A shop owner evaluates this product in under ninety seconds, and he does it by asking four things in a fixed sequence. If question one fails, he never reaches question two. Every navigation decision downstream is derived from this order — nothing sits in the primary nav that doesn’t answer one of them.
“Who's already here near me?”
Density. If it looks empty, he leaves.
“What do I give, what do I get?”
The deal must fit in one sentence.
“How much work is this for my staff?”
Redemption must be one screen.
“How do I know it worked?”
A number in rupees, sent to him.
Define · target audience
One persona carried the rest of the process
Eleven interviews and a 63-response survey kept pointing at the same person: the owner who signs up, picks partners, and reads the money. Every decision from here reads against him specifically, rather than an abstract “user”.
Persona: The owner
“Show me who on this street is already in it. If it's just me, why would I pay you?”
Ranjan Dutta
Male, 43, married
Owns a 2-outlet gym
11 years trading
Runs it with his wife
Scenario
Ranjan opens the shutter at 6am and is on the floor until 9pm. He signs up for things at trade fairs and abandons them within a fortnight because nothing ever shows him a number. He talks to the café two doors down every day but has never once counted how many customers they've sent each other.
Goals
- •More first-time walk-ins, not more admin
- •Know within a month whether it worked
- •Be able to stop without a phone call
Frustrations
- •Every tool starts empty and stays empty
- •Nobody will tell him what a fair deal looks like
- •Cannot justify a subscription to his wife without a figure
Motivation
Define · journey
Ranjan’s first session, mapped
I mapped the owner’s first ninety seconds against the existing build to find where it lost him. The curve below is the emotional line; the red points are where the product actively worked against itself. Every one of the eight decisions later in this case study attaches to one of these dips.
Hears about it
Founder pitches it at his counter, mid-shift.
Curious but sceptical — he has heard this before.
Opens the link
Taps through to a login form on his phone.
Immediately guarded. Why am I signing up already?
Signs up
Types business details into a long form.
Impatient. This is work, and he is standing up.
Lands on home
Sees an empty dashboard and disabled nav items.
Deflated. So there is nothing here.
Looks for partners
Finds a search screen with no results near him.
Done. Puts the phone down.
Never returns
No reason to reopen it; nothing chases him.
Forgotten within a day.
Gap
The front door asked for an account before showing anything.
Gap
Typing a full profile on a phone is where SMB signups die.
Gap
Zero partners, six greyed-out features. Reads as unfinished.
Gap
An empty result set with no next action ends the session.
Gap
Nothing left the app to reach him where he actually is.
Reframe
So the brief was rewritten
The brief I was handed
How might we simplify the merchant dashboard so partners are easier to manage?
The brief I argued for, and got
How might we make a shop owner believe in this product in ninety seconds — on the day we have six members, no redemptions, and nothing to show him but his own street?
The reframe cost one uncomfortable meeting and saved the launch. Optimising the logged-in dashboard would have polished the screens the fewest people would ever reach.
Competitive landscape
Where this sits against everything else he’s been sold
| Category | What it does well | Where it leaves him |
|---|---|---|
| Directory listings | Reach, SEO, familiar | No transaction — a listing is not a deal |
| Coupon marketplaces | Instant consumer demand | Trains discount-hunters, not neighbours |
| Loyalty SaaS | Deep single-merchant retention | Each merchant stays an island |
| Group buying / BNPL bolt-ons | Fast merchant signup | No reason to return once the promo ends |
| This product | The neighbour is the channel; deal is the object | Worth nothing until a street is dense |
the last row is the honest one — our advantage and our fatal weakness are the same sentence
Design principles
Five rules I wrote before drawing anything
Pinned to the top of the Figma file for fourteen weeks. Every decision below is one of these applied, and when two of them collided I say so.
01
Proof before password
Nothing is hidden behind signup that could have been shown first. The account wall sits after the value, never in front of it.
02
Empty is a state, not an error
Every screen was designed twice — once full, once with nothing in it. The empty version got the better copy.
03
One sentence, three numbers
If a deal cannot be read aloud in one breath and summarised in three numbers, it is not ready to ship.
04
Gate by omission
A feature is either in the navigation and working, or it is not in the interface. No greyed-out promises.
05
The proof leaves the building
Assume the merchant never opens the app unprompted. Design the message, not the dashboard.
The work
Seven decisions, and what each one cost
Question 1 · Who's already here?
Show him his street before asking for an account
The old front door was a login form. Every proposal link, referral and bill link we would ever send leaked traffic onto it, and a form answers none of the four questions.
So the first three screens of the product happen before signup: locate your business, watch it search your radius, and see a real count of real neighbours who complement you — with their names blurred. The blur is doing precise work. It is not a dark pattern hiding value; it is proof of value with the last inch withheld. He can count the pins, read the categories and check the distances himself. What signup buys is the names.
The trade: we lose the clean funnel metrics a gated signup gives you, and we spend server work on visitors who may never register. In exchange the first thing a sceptical owner sees is his own street, which is the only thing he was going to believe.
Searching…
Reading your 5 km radius
5
Potential partners nearby
Businesses that complement yours, inside your radius.
No card. The list is already yours.
the names stay blurred. the count, the categories and the distances are real →
Onboarding
Move the finish line from “profile saved” to “you are discoverable”
The existing flow ended on “offer created”. Nobody pays for an offer they created. Four steps, each one feeding the next, and the last screen is not a success tick — it is the card that other businesses will see, with a live count of how many can now find him.
Two details carry most of the weight. The first is claim, don’t create: business details are pulled from a places lookup on one tap, because typing a business profile on a phone is where small-business signups die. The second is that fit-scoring is triggered the moment the profile saves, synchronously, for that one merchant — the original build waited for a nightly batch, which meant the aha screen arrived a day after the person did.
The trade: a synchronous score costs a slower save and real compute per signup. I pushed for it anyway; a reveal that lands tomorrow is not a reveal.
STEP 1 OF 4
Tell us about your business
Business name
Business type
Phone number
STEP 2 OF 4
Where are you located?
Business address
Neighbourhood preview
STEP 3 OF 4
What are you looking for?
Partnership interests
Your specialities
STEP 4 OF 4
You're already discoverable
This is how your card looks to the businesses around you — live from now.
step 4 is not a confirmation. it is the profile card his neighbours will see →
The hardest screen
Give the empty screen a face and one thing to do
For the first six weeks, the average merchant opens this app and has nothing: no partners, no offers, no redemptions. That screen was going to be seen more than any other screen in the product, and the honest version of it — “No partners yet” — reads as a broken purchase.
So the empty state got three things instead. A mascot, which carries the disappointment so the copy doesn’t have to. A plain sentence naming the actual situation — you’re the first business on this street — rather than a system message about zero results. And two next actions: invite the shops around you, or widen the search.
That last part is the rule the whole product inherited. Nothing in the interface is allowed to be a dead end: every empty list names why it is empty and offers exactly one thing to do about it. An empty state with a next action is a prompt; an empty state without one is a refund request.
match found
no results
searching
three moods, one rule: the mascot only ever appears where the product has nothing to give
The trade:a cartoon character in a tool people are paying for is the decision most likely to be called unserious by a buyer, and I took that risk knowingly. It holds because the mascot is rationed — it appears only where the product genuinely has nothing to give, and never on a screen with real data on it. The moment it starts decorating full screens it becomes a toy, and I’d cut it.
5 businesses within 900 m
↑ shake the phone to search wider — a physical gesture for the one action merchants repeat daily, one-handed, behind a counter
Question 1, continued
List the businesses that never signed up
Six members on a map looks like a failed product. Three hundred pins looks like a neighbourhood. So the map carries every relevant business in the cluster — most of them from public data, none of them members — as a third pin state, with a “is this your business?” claim path on every one.
This is the oldest trick in marketplace design and it is still the right one, provided you are honest about it: only public information is shown, unclaimed profiles are visibly different rather than disguised as members, and the invitation a member sends is not “join my software” but “here is a revenue deal with your neighbour, one tap to accept.”
Member
Signed up. Tap to propose a deal.
Unclaimed
Public data only. Tap to invite — they can accept without an account.
Recommended
Fit score ≥ 0.65. Pulses, so the eye lands here first.
The trade: a ghost listing is a business that did not ask to be there. I drew hard lines — public data only, one-tap removal, no implied endorsement — and I would walk those lines again in review before every new cluster, not once at launch.
the rationale sits above the button, in his language, not the algorithm's →
Question 2 · What do I give and get?
Three named deals instead of twenty-four cap fields
The terms model is genuinely excellent engineering — per-bill, daily, monthly, outlet and lifetime caps, points conversion, approval thresholds. It is also completely unusable as a first screen. I spent a week trying to make twenty-four fields legible before accepting that the answer was not to show them.
Three named templates, chosen by goal rather than by mechanism — Welcome Swap for new customers, Cross-Reward for repeat visits, Slow-Hours Boost to fill weekday slack. Each one shows the same three numbers, in the same order, because those are the three things every owner asked: the worst it can cost me, what my staff has to do, and how fast I can stop.
What the data model offers
24 fields. An accountant’s dream, a shopkeeper’s nightmare. Every one of them still exists — they just moved behind the word “Advanced”.
The trade: roughly one merchant in twenty wants the full grid, and templates make them feel patronised for about ten seconds until they find “Advanced”. That is a fair price. Designing for the twentieth merchant would have lost the other nineteen.
every template compiles down to the same fields. he just never meets them →
Negotiation
Shopkeepers negotiate numbers, not paragraphs
The free-text thread was already built and worked fine. I demoted it anyway. Counters became structured edits to the terms, each rendered as a diff — because after five messages neither side can say what was agreed, and none of it is machine-readable.
Rejected — free-text thread
Five messages later, neither side can say what was agreed, and nothing is machine-readable.
Shipped — structured counter
The Daily Grind proposed 2 changes
One tap agrees, and the agreed numbers are the contract — no one has to re-read the conversation to know what was signed.
Question 4 · How do I know it worked?
The most important screen isn't in the app
Every merchant I met said a version of the same thing: the last product they signed for never told them whether it worked. A dashboard does not solve this, because a dashboard requires him to remember to open it, and he will not.
So the retention loop was designed as an outbound message. One digest a week, in the messaging app he already lives in, with the only four facts that matter: how many customers came from partners, what they were worth, what they cost, and what is waiting for his reply. Once a month it carries a one-page statement — the artefact he shows his co-owner to justify the subscription.
Making Money a top-level navigation item was the other half of this. A partner-by-partner profit and loss is the single thing no competitor in this category shows, and the moment a merchant reads “₹11,400 of new business from the café, cost ₹2,100”, the product stops being a subscription and starts being a supplier.
The trade: designing for a channel you don’t control means no layout, no interaction, and a hard character budget. It forced the writing to get much better, which turned out to be the point.
Week 24 — your street
9 new customers walked in from partners.
7 from The Daily Grind, 2 from Page & Co.
New business ₹6,300 · cost you ₹1,140.
Your customers redeemed 11 offers next door.
One proposal is waiting for your reply. ⏳
9:41 ✓✓
1 page · per-partner P&L
assume he never opens the app. design the message instead →
Information architecture
Which produced the navigation
Four items, none disabled, each one answering one of the four questions in the order they get asked. Customers, campaigns and broadcasts still exist — they unlock once a merchant has a live partnership, because before that they are genuinely irrelevant.
Before — 8 items, 6 disabled
- Dashboard
- Partners
- CouponsComing soon
- CampaignsComing soon
- BroadcastsComing soon
- CustomersComing soon
- GrowthComing soon
- POSComing soon
Six of eight items advertised what the product could not yet do. To a buyer, that is not a roadmap — it is an unfinished product.
After — 4 items, 0 disabled
- HomeQ1One next action. Never a chart first.
- PartnersQ2Neighbourhood · Matches · Proposals · Live
- OffersQ3What I give · What I get
- MoneyQ4Per-partner P&L. The retention loop.
Every one maps one-for-one onto the four questions above. Gate by omission, never by teasing: a feature is either in the nav and working, or it is not in the UI.
Design system
The system underneath
Built to be handed over, not admired. One token set and a small number of rules that were written down so nobody had to ask me.
Colour
Purple carries identity; every state colour (green pass, amber cap, red block) is reserved and never used decoratively, so colour at the counter always means something.
Type
Grow your local network
Body copy sits at 15–16px with 1.55 leading.
One family, four steps. Headlines are tight and heavy so a screen reads at arm’s length; numbers get their own scale, because in this product the number is the content.
Rules that shipped as specs
- ▸Every list has three designed states: full, thin, empty.
- ▸No empty state without exactly one next action.
- ▸Active nav is a filled pill, never a tint — glance distance.
- ▸Cap consumption is visible wherever a benefit is applied.
- ▸The mascot appears only where there is genuinely nothing to show.
Rejected options
What I killed, and one thing I got wrong
Rejected
Map-first home screen
A live neighbourhood map as the default landing screen — visually the strongest thing we had.
Killed it. On a real 5-year-old Android over café wifi it took 4–6 seconds to become useful, and a merchant checking between customers had already put the phone down. The map moved one tap deeper; Home became a single next action.
Rejected
Full layout freedom for merchants
Let each business reorder its own public profile, the way the loyalty product I'd designed before allowed.
Rejected. Here the reader is another business owner comparing five profiles, and comparison needs a fixed shape. Freedom would have made every card unscannable.
Rejected
Two-sided escrow at launch
Hold and settle money between merchants so the exchange is provably fair.
Cut, and I argued for cutting it. The fear it addressed — “will I end up owing him money?” — turned out to be answerable with one sentence of copy: each side funds its own discount, nothing moves. Copy beat a payments integration.
Rejected
Chat-first negotiation
A free-text thread per partnership; already built, already working.
Demoted to secondary. Watching two owners haggle in person, they exchange numbers, not paragraphs. Structured counters became primary; the thread stayed for context.
Test · round 1
Usability testing, and what it broke
I tested the cold-start flow with five owners before build. Moderated video calls, screen-sharing from their own phone.
Setup
- Type
- Moderated
- Participants
- 5
- Mode
- Video call
- Device
- Their own phone
- Length
- 15–30 min
What I measured
| Participant | Role | Age | Business | Device | Note |
|---|---|---|---|---|---|
| P1 | Owner | 43 | Gym, 2 outlets | Android, 3 yrs old | — |
| P2 | Owner | 38 | Café | Android | — |
| P3 | Owner | 51 | Pharmacy | Android, cracked | Reading glasses |
| P4 | Owner | 34 | Salon | Android | — |
| P5 | Owner | 47 | Bookstore | Android, 5 yrs old | Slow connection |
Broke · severity high
The blurred list read as broken, not withheld
Three of five owners thought the page had failed to load. The blur was doing its job as a paywall and failing completely as a signal. Fixed by adding the count as plain text above it and a lock icon on each row — after that, five of five read it as “there is something here I have to sign up for”.
Test · round 2
Retested, and what still is not solved
I re-ran the broken task with the same five people after the fix. Proposal completion went from four of five to five of five unaided.
One thing did not resolve. P3 and P5, both on older phones with poor connections, still waited 4–6 seconds for the neighbourhood map to become useful. I could not fix that in design — it is a data problem — so I moved the map one tap deeper and made Home a single next action instead. That is a workaround, not a solution, and it is the thing I would attack first with another cycle.
Accessibility
Designed for a cracked screen in daylight
This product is used one-handed, on older and sometimes damaged devices, frequently outdoors. Accessibility here is not a compliance checklist bolted on at the end — it is the operating condition.
Contrast
All text clears AA at its real size; primary actions run at AAA because they're read outdoors in direct sun.
Tap targets
Nothing interactive is under 44×44 — the minimum an adult thumb can reliably hit without looking down first.
Never colour alone
Cap states pair colour with an icon and a label, so a red 'blocked' still reads for a colour-blind user.
Motion
Every looping animation on this page and in the product respects prefers-reduced-motion, holding a legible frame instead of hiding.
Type floor
12px is the smallest size shipped, and only for labels beside a larger value — P3 read the flow in reading glasses.
One-handed
Primary actions sit in the lower third, reachable with a thumb while the other hand is holding a customer's phone.
Impact
Where it landed
- 4
- navigation items, none disabled — down from eight with six greyed out
- 3
- deal templates replacing a 24-field terms grid at first contact
- 90s
- the window the whole cold-start experience was designed against
The honest caveat
These are design and build figures, not market outcomes. The product launched into one cluster; the metric that will actually decide whether this work was right — share of partnerships with at least one redemption in the last thirty days — needs a full quarter of live data before it means anything. I would rather show you the reasoning and wait for the number than round one up.
Reflection
What fourteen weeks taught me
Design the empty product first. Every project I've worked on has treated empty states as cleanup at the end of the sprint. On a network product they are the product for the first six weeks, and designing them last means designing the only screens that matter under the least time.
Copy is a feature with an engineering budget. One sentence about who funds the discount replaced a settlement system. I now cost every objection twice — once as a build, once as a sentence — before choosing.
Writing the rules before drawing the screens is what kept build from quietly becoming redesign. Every cap edge case and every pin state was decided on paper first — expensive up front, and the only reason two weeks of build did not turn into three.
Where I over-designed: the first cap-configuration screen was beautiful and wrong. I spent a week making 24 fields legible before accepting that the answer was to not show them. Legibility is not the same as simplicity, and I'm still quick to reach for the former.
Next steps
What I would build with another cycle
- 1
Instrument the cold-start funnel properly
Right now the blurred-list screen is assumed to convert because it is the most persuasive thing we have. That is a belief, not a number. I want per-screen drop-off across the three pre-signup steps so the assumption can be killed if it is wrong. - 2
Turn the fit score into a conversation
Put the rationale in front of merchants as editable feedback — “this match is wrong because…” is the cheapest training data available, and it costs one text field. - 3
Design the second cluster as a product surface
Everything here was built for street one. Street two will expose whatever we hard-coded — the category map, the fit weights, the seeded ghost listings — and that expansion should be a screen somebody uses, not an operations task somebody performs.
A marketplace is not built by designing the full version and waiting. It is built by making the empty version worth opening twice.
- THE END -
More case studies
One-Spot Web App
A lightweight, brand-adaptive mobile web experience for loyalty, rewards and engagement.
hoichoi, Rethought
Improving discovery, clarity and decision-making across the OTT subscription journey.
e-Bill, Improved
A tax document rebuilt into the post-purchase screen brands actually wanted to own.
The eWards Design Guide
One vocabulary for colour, type, space and state — shared across Vue and Flutter.