NM Company
A portfolio and enquiry site for events firm NM Company
A visual portfolio and enquiry website for an event management and supplies firm — presenting a full...
Read itProduct design and design systems
UI/UX Design
Research, information architecture and a coded design system — tokens, not screenshots. Designed to WCAG 2.2 AA and for a ₹9,000 Android in Kanpur, not a MacBook in a studio.
- A coded design system with tokens — change one value, not two hundred files
- Every state designed: empty, loading, error, offline, permission-denied
- WCAG 2.2 AA at design time, not as a remediation pass before a tender
- Tested with real users on real devices, including a 3GB Android
What this is
Anyone can design the happy path.
Most of what gets called UX in India is a Figma file of eleven beautiful screens, delivered as a PNG, that describes a product on a large screen with fast wifi and no errors. Then engineering builds it, discovers there is no empty state, no loading state, no error state and no idea what happens on a 360px-wide phone, and quietly invents all of it at 2am.
We design the other 80%: the states nobody draws, the flows where money changes hands, the moment the network drops, the screen a user sees when they have zero records. And we ship a design system — tokens, components, documented behaviour — not a folder of screenshots. Handoff is the point where most design work quietly evaporates, so we treat it as a first-class deliverable rather than an email with a Figma link.
Our users are usually not people like us. They are a 42-year-old shopkeeper in Kanpur on a ₹9,000 Android with 3GB of RAM and a patchy connection, filling a form in his second language with the sun on his screen. Design that only works for the person who designed it is not design. It is decoration.
How we work
Research, architecture, system, handoff.
In that order. Skipping to the pretty part is why so much design gets built once and never used.
-
01
Research, sized to the decision
1–2 weeksContextual interviews with people who will actually use the thing, in the place they will use it. A teardown of what they use today, including the WhatsApp group and the paper register that the software is competing with. Analytics on the existing product, if there is one. Research exists to change a design decision — if a study cannot change one, we do not run it.
-
02
Information architecture
1 weekWhat are the objects, how do they relate, and what does a person need to be holding in their head at each step. Card sorting where the taxonomy is contested. Navigation designed around tasks, not around your org chart — which is the reason most enterprise software is unusable.
-
03
Wireframes and the unglamorous states
1–2 weeksLow-fidelity, fast, disposable. We design the flows that carry money or risk properly, and we draw the states nobody draws: empty, loading, partial, error, offline, permission-denied, too-much-data. This is where the real product decisions get made, before anyone has fallen in love with a colour.
-
04
Visual design and the system
2–3 weeksTokens first — colour, type, spacing, radius, elevation, motion — then components built from them, then screens assembled from components. Built in that order it is a system. Built the other way round it is forty artboards that will never agree with each other again.
-
05
Usability testing on real devices
1 weekFive to eight users from your actual segment, on their own phones, doing a real task while we watch and say nothing. It is uncomfortable and it is the cheapest bug-fixing you will ever buy. Every serious issue gets fixed before a single component is written.
-
06
Handoff that does not evaporate
1–2 weeksTokens exported as code into your repository. A component library in Storybook with every state documented. Interaction and motion specs. Accessibility annotations. Then we pair with your engineers on the first components, because a system that nobody was taught to use is a system that decays in two releases.
What bad design costs
None of this shows up in a Dribbble shot.
These are the design failures we get called in to fix, and every one of them has a number attached.
-
The empty state was never designed
A brand-new user logs in to a blank grey rectangle and no idea what to do next. Your entire activation funnel dies on the screen nobody drew.
-
It was designed on a 27-inch monitor
The table has nine columns, the form is two columns wide, and 78% of your traffic is on a 360px phone. Everything works fine in the studio.
-
Four blues, three greys, two type scales
Nobody defined a token, so every screen invented its own. Changing your brand colour is now a three-month archaeology project.
-
The accessibility audit failed the tender
Contrast below 4.5:1, no keyboard focus ring, status conveyed only by colour. A remediation pass at the end costs six times what designing it right would have.
-
Engineering invented the missing half at 2am
No loading state, no error copy, no offline behaviour in the file. So a developer made it up under deadline, and now the product speaks in two different voices.
-
Nobody ever watched a real user try it
The flow makes perfect sense to the eleven people who built it. The shopkeeper in Kanpur abandons it at step three and calls your support line instead.
Tokens, not screenshots.
A design system is not a component library in Figma. It is a set of decisions expressed as tokens, and code is where it has to live.
The test is simple. Change your primary colour, or bump the base type scale, and count what happens. In a screenshot-based handoff, the answer is: a designer opens forty artboards, an engineer opens two hundred files, and three months later something in the checkout is still the old blue. In a token-based system, you change one value, it flows through Tailwind or CSS custom properties into every component, and the diff is one line.
So we define colour, type, spacing, radius, elevation and motion as named tokens with semantic meaning — surface-raised, not gray-100; text-critical, not red-600 — and we ship them as code, in your repository, alongside a component library where every component documents its states: default, hover, focus, active, disabled, loading, error, empty. The Figma file and the code read from the same source of truth, so they cannot drift apart the moment the designer leaves the project.
That is the difference between a design system and a mood board with rules.
What you get
The deliverables, precisely.
You should never receive a design deliverable you then have to interpret. If it needs a call to explain, we did it wrong.
Research that changed something
Contextual interviews, a competitive teardown, usability sessions with real users on real devices — reported as decisions we made and decisions we reversed, not as a persona deck.
Information architecture
Object model, navigation, taxonomy and the flows that carry money or risk. Structured around what a user is trying to do, not around your reporting lines.
A tokenised design system
Colour, type, spacing, radius, elevation and motion as semantic tokens, exported as code into your repository. Change one value, not two hundred files.
A component library, in code
Storybook with every state documented — default, hover, focus, active, disabled, loading, error, empty. Your engineers assemble screens; they do not reverse-engineer PNGs.
Accessibility, designed in
WCAG 2.2 AA contrast checked at design time, focus order specified, 44px touch targets, no status by colour alone, ARIA semantics annotated for engineering.
Motion with a purpose
Transitions that explain where a thing came from and where it went, specced with duration and easing. Respecting reduced-motion, and never animating the critical path.
Who you are designing for
Your user is not you.
Accessibility and low-end performance are the same discipline wearing different clothes: both are about not assuming your user is you.
We design to WCAG 2.2 AA as a baseline, not as a remediation pass before a government tender. Contrast is checked at design time — 4.5:1 for body text, 3:1 for large text and interactive boundaries. Every interactive element is reachable and operable by keyboard with a visible focus ring. Touch targets are 44px minimum, because a delivery partner is tapping with a thumb, in a hurry, on a cracked screen. Nothing communicates status by colour alone, because roughly one in twelve Indian men cannot reliably distinguish your red from your green.
And we design for the device that actually exists. A 360×640 viewport is the primary artboard, not the afterthought. Font sizes assume Devanagari and Tamil glyphs, which are taller than Latin and will break a tightly-set line height. Images have a defined aspect ratio so the layout does not jump when they load slowly. Forms tolerate a phone number pasted with spaces, a pincode typed with a trailing space, and a name with no surname — because that is what real Indian data looks like, and rejecting it is a design failure, not a user error.
- 360×640 is the primary artboard, not the afterthought
- Tested on a 3GB Android in daylight, in the user's second language
- Forms that accept real Indian data — spaces in phone numbers, no surname
- WCAG 2.2 AA contrast and focus states checked at design time
What it moves
Design that pays for itself.
Median movement on the products where we redesigned a core flow and then measured it properly against the previous version. Nobody gets to claim a lift they did not instrument.
Talk about your product
0%
Lift in task completion
Core flow, measured on real users
0x
Faster component delivery
Once the token system was in the repo
0%
States designed
Empty, loading, error, offline — every screen
AA
WCAG 2.2 conformance
Verified with axe on the built product
The difference
A Figma file versus a design system.
| A pretty Figma file | A design system | |
|---|---|---|
| Empty, loading and error states | No | Yes |
| Lives in your code repository | No | Yes |
| Rebrand effort | Weeks of archaeology | One token file |
| Accessibility checked at design time | No | Yes |
| Tested with real users on real devices | No | Yes |
| Engineers have to interpret it | Constantly | Never |
| Still coherent after two years | No | Yes |
The toolkit
What we design and ship with.
Figma
Figma Variables
Auto-layout systems
Rive / Lottie
Design Tokens (W3C)
Style Dictionary
Tailwind CSS
Storybook
Framer Motion
Maze
Hotjar
Axe DevTools
Real-device lab
Proof
All case studies
Interfaces in daily use.
Products where the design survived contact with real users on real hardware.
FealDeal
E-commerce — Ethnic Fashion
A high-catalogue ethnic-wear storefront for FealDeal
A Shopify storefront for a Surat ethnic-wear label — 200+ SKUs of lehengas, sarees and suits organised by type, colour, fabric and work, wit...
Shopify
Platform
0+ SKUs
Catalogue
Turant Logistics
Logistics & Supply Chain
Cutting order-to-dispatch by 62% for a 400-truck 3PL
A fleet, ePOD and route-optimisation platform built offline-first for drivers in low-connectivity corridors — because the two off-the-shelf...
0% faster
Faster order-to-dispatch on the ops floor
0% shorter
Shorter POD-to-invoice cycle (8.4 days to 19 hours)
Collection by Rehan
E-commerce — Watches & Accessories
A brand-led watch and eyewear store for Collection by Rehan
A Shopify storefront for a Surat watch and eyewear retailer — browsable by gender, brand, style and combo, with predictive search, COD check...
Shopify
Platform
Brand & style
Browse by
Both, and the second is worth very little without the first. Research is proportionate: for a consumer product it might be eight contextual interviews, a competitive teardown and a diary study; for an internal tool it is often two days sitting next to the people who will use it eight hours a day. What we do not do is a hundred-page persona deck. Research exists to change a design decision. If it cannot, we do not run it.
A Figma file with every flow and every state — including the empty, loading, error and offline ones — plus a design system delivered as code: tokens for colour, type, spacing, radius and motion, and a documented component library, usually in Storybook and Tailwind. Plus interaction specs, an accessibility annotation layer, and a written rationale for the decisions that will get questioned in six months.
That is the most common way we engage. We embed with your engineers rather than throwing a file over a wall — attending stand-up, reviewing pull requests for visual and accessibility regressions, and pairing on the first few components so the system takes hold. Design that is handed over and never revisited decays within two releases. Design maintained in the same repository as the code does not.
As a design constraint, not a fix. Contrast ratios are checked as we design — 4.5:1 for body text, 3:1 for large text and interactive boundaries. Focus order and keyboard operability are specified. Touch targets are at least 44px. Nothing conveys status by colour alone. We annotate semantics and ARIA needs for engineering and run axe on the build. WCAG 2.2 AA is our default; if you are tendering to government or a regulated buyer, we will tell you where the gaps are before the audit does.
We stop designing for ourselves. The primary artboard is 360×640, not a desktop. We test on a ₹9,000 Android with 3GB of RAM, in daylight, with a real user in their second language. Forms tolerate a phone number pasted with spaces and a name with no surname. Instructions are shown, not assumed. Icons that mean nothing outside a design studio get a label. Most of the "our users are not tech-savvy" problem is a design that never left the studio.
A focused product — research, IA, the core flows and a starter design system — is typically 5 to 8 weeks and lands between ₹4L and ₹9L. A full platform with multiple roles, a mature design system and usability testing runs 10 to 16 weeks. If you already have engineering and only need a design system extracted from an existing product, that is usually a 4 to 6 week fixed-scope piece. We quote against a scope, not a day rate.
Show us the screen your users keep calling support about.
That screen is a design brief. Send it over with the support tickets and we will tell you what is actually wrong with it — usually in the first reply, at no charge.
Proof
Shipped, measured, still running.
Swasthya Sarathi
A healthcare-companion platform for Swasthya Sarathi
A multi-service healthcare platform that helps people find hospitals, doctors, labs, medical stores,...
Read itMV Tech Education
A course and admissions platform for MV Tech Education
A course-catalogue and admissions website for a Bihar vocational institute — leading with industrial...
Read itRelated services
Web Development
Production web applications built on Laravel, Next.js and Postgres — typed, tested, observ...
ExploreMobile App Development
Flutter, React Native and native apps that hold up offline, on old hardware and on a metro...
ExploreEcommerce Development
Commerce platforms where the checkout converts and the back office reconciles — multi-ware...
ExploreLet's talk ui/ux design
Bring us the hard version of the problem.
A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.