QWIPO · 2024-25
B2B
Android mobile app
Consumer goods
Every screen - one source of truth.
No system, no consistency. Built QWIPO's first buyer-side design system from scratch - components, tokens, and handoff specs all in one place.
MY ROLE
Product Designer
TIMELINE
Nov ‘24 - Apr ‘25
RESEARCH
Contextual Inquiry
OWNERSHIP
Token architecture
Component library
Documentation
ABOUT THE PRODUCT
Qwipo is a mobile-first B2B marketplace connecting Kirana and general store owners with wholesalers for FMCG restocking. Unlike Udaan or Jumbotail, it recreates the traditional wholesale experience digitally - giving wholesalers a space to showcase products, not just list them.
With a small, fast-moving team and an evolving product, design consistency wasn't a nice-to-have. It was infrastructure.
THE USER
PRIMARY
Kirana and general store owner
High frequency
Thin margins
Time-pressed
Low-end devices
GOAL ON PLATFORM
Restock shop inventory fast, at the best price
DEVICE CONTEXT
Low-end Android with patchy connectivity
DESGIN IMPLICATION
Readable typeface, clear tap targets, lean UI density
SECONDARY
Restaurants, tiffin centres & PG owners
Bulk orders
Time-pressed
GOAL ON PLATFORM
Higher-volume reorders with less daily pressure
DESGIN IMPLICATION
Same system, different rhythm - consistency still matters
INTRODUCTION
When I joined as a design intern in September 2024, there was no component library, no visual guidelines, no documentation - and eleven distinct shades of black in use across the UI.
"Every screen had been built in isolation - the kind of inconsistency that's hard to articulate but instantly easy to feel."
For buyers running businesses off this app, that friction wasn't just visual - it eroded trust. My task: build a foundation the whole team could ship from confidently, not just clean up what existed.
IDENTIFYING THE PROBLEMS
A design audit surfaced five core problems, each contributing to a fragmented buyer experience:
1
No visual hierarchy
Inconsistent type styles and spacing made screens hard to scan, slowing ordering decisions.
2
Weak button affordance
Every button was black - impossible to distinguish primary from secondary actions at a glance.
3
Irregular typography
No type system. Product names and pricing on small screens were exhausting to parse.
4
Colour inconsistency
Eleven near-identical shades of black diluted brand identity and muddied visual priority.
5
No reusable patterns
Every new screen designed from scratch - any UI change was a disproportionate effort for both design and engineering.
THE PROCESS
PHASE 1
Establishing foundations
I established a style guide covering colour, typography, and spacing, and introduced design tokens to make the system maintainable as the product scaled.
1
Colour tokens
Black discontinued as a default fill. Replaced with accent colours - each with a defined semantic role.
2
Typography scale
Six roles (display → caption) with Raleway as the typeface. No more arbitrary sizes and weights.
3
Spacing system
An 8pt grid - every margin, padding, and gap from the same base unit.
4
Effects
Shadow values defined into elevation levels. Consistent depth cues, no more per-screen guesswork.
PHASE 2
Building components
With foundations locked, I built the component library - buttons, inputs, cards, modals, navigation - each with full state coverage (default, hover, disabled, error, loading). Concurrently handling live UX tickets stress-tested components against real product needs before they were locked in.
A working library existed for the first time - but new problems were surfacing.
PHASE 3
Iterating on feedback
By February 2025, two issues were undeniable. A second audit confirmed both - I widened the research lens to Razorpay and Atlassian's systems to understand how mature products handle density at scale.
1
Raleway broke at small sizes
Its letterforms are designed for display - at small sizes on mobile, characters lose distinction and product names become hard to parse
2
The UI had grown
Six roles (display → caption) with Raleway as the typeface. No more arbitrary sizes and weights.
PHASE 4
Redesign and scalability
The redesign focused on two things: fixing typography and creating breathing room. Four typefaces were evaluated against legibility at small sizes, performance on low-resolution Android screens, and fit with Qwipo's functional product character.
Components were revised to reduce visual noise - tighter hierarchy, more intentional whitespace, simplified states. Full documentation followed: colour usage rules, state guidelines, component principles, and spacing rules.
Text styles
Different text styles available for usage.
Headings: Used for prominent text like titles, sections, and page headlines.
Label: Used for form labels, interactive element names (buttons, menu items), or small headings within components. Requires clear, readable styling; can vary by font weight for emphasis.
Caption: Used for supportive information like image captions, helper text, or annotations. Usually smaller and subtler, helping ancillary text remain unobtrusive.
Heading
Font Weight
Font Size
Line Height
Usage
Heading/large_semibold
semibold
18
24
Main page/title headers, strongest emphasis
Heading/large_medium
medium
18
24
Section headers with less emphasis
Heading/small_semibold
semibold
16
20
Subsection headers, nested sections
Heading/small_medium
medium
16
20
Supporting subsection headers
Labels
Font Weight
Font Size
Line Height
Usage
Label/large_semibold
semibold
16
20
Prominent UI labels (e.g. buttons, tabs)
Label/large_medium
medium
16
20
Standard labels with clear readability
Label/large_regular
regular
16
20
Supporting large labels
Label/medium_semibold
semibold
14
20
Emphasized form labels, menu items
Label/medium_medium
medium
14
20
Default form or input labels
Label/medium_regular
regular
14
20
Secondary medium-scale labels
Label/small_semibold
semibold
12
16
High-emphasis small labels (chip text, small buttons)
Label/small_medium
medium
12
16
Default small-scale labels
Label/small_regular
regular
12
16
Subtle small supporting labels
Caption
Font Weight
Font Size
Line Height
Usage
Caption/large_medium
medium
12
16
Helper text, emphasized captions, inline annotations
Caption/large_regular
regular
12
16
Default caption text, supplementary content
Caption/small_medium
medium
10
14
Fine-print emphasis, small metadata
Caption/small_regular
regular
10
14
Disclaimers, metadata, faint supporting text
COMPONENTS
Label
Label
Label
Label
Label
Label
Label
Label
Label
Label
9
9
9
9
9
9
error text
Label
+91
9999999999
error text
Label
Upload file
supported file type: .PNG, .PDF
File size limit: 25 MB
error text
Label
Placeholder
error text
Label
Placeholder
error text
Label
Label
Label
Label
Label
helper text
Label
Add
Add
1
Label
Label
Label
Label
Label
Label
*In compliance with the NDA, only a curated set of components is shared publicly. The complete file is available on request.
EVOLUTION OF UI
OUTCOMES
100+
Design and dev hours saved
A shared language
The product's first design system.
WHAT I’D CARRY FORWARD
01
A design system is a product, not a deliverable
It wasn't done when launched - it was done when adopted and maintained. The same ongoing care as any product feature.
02
Speed and structure aren't opposites
Working on live tickets while building the system felt risky early on. In practice it made components more robust - real use cases surfaced edge cases that isolated system-building would have missed.
03
Documentation is design work
The Figma file was half the job. Usage guidelines and component rationale were what made the system usable beyond me - if the documentation wasn't clear, the system wouldn't survive my departure.