Services
Eight ways I work with teams — each with a stated scope, a list of what you actually receive and a realistic timeline. No packages, no retainers you cannot exit.
From problem statement to build-ready screens
The full arc of a product: understanding the problem, structuring the experience, designing every screen and state, and staying involved until it ships. This is how most of my engagements run, and it is where design has the most leverage.
Evidence before opinions
Interviews, competitive teardowns, journey maps and usability testing — run at whatever depth the timeline allows. Even a compressed research week routinely removes a month of building the wrong thing.
A library your engineers actually trust
Tokens, components, variants and the documentation that keeps them being used correctly. A design system is only worth building if it makes the next screen faster and the twentieth screen still consistent — that is the bar I hold it to.
iOS and Android, designed for the thumb
The majority of the 150+ interfaces I have designed are mobile. Platform conventions, one-handed reach, gesture behaviour, notification design and the awkward realities of small screens and bad connections.
Dense information, made readable
Admin panels, analytics platforms and operations tools. The hard part is never fitting the data on screen — it is deciding what a user should see first, and having the discipline to hide everything else.
Interfaces that stay honest about the model
AI features fail on interface far more often than on model quality. The design work is in confidence, correction, sourcing and expectation-setting — making a probabilistic system feel trustworthy without overclaiming what it can do.
A prioritised list of what to fix first
A structured review of an existing product against usability heuristics, accessibility standards and your own conversion goals — delivered as a ranked list of fixes, each with the effort it takes and the impact to expect.
Usable by more people, by default
Accessibility handled while designing rather than retro-fitted after an audit fails. Contrast, target sizes, focus order, semantics, motion sensitivity and text scaling — checked as part of the definition of done.
Every engagement
Whether it is a two-week audit or a ten-week product build, the phases do not change — only their depth does.
Business goals, user problems, constraints and success metrics — captured before anyone opens Figma.
Flows, information architecture and low-fidelity wireframes. Cheap to change, brutal at exposing gaps.
High-fidelity UI, a clickable prototype, and usability sessions that decide what changes before build.
Tokens, components, annotated handoff, design QA on staging, then iterate on what real usage shows.
How I work
Everything below is on the FAQ too — it is here because these are the questions that decide whether we are a fit.
You get the number before anything starts. It does not move unless scope does, and a scope change is agreed in writing first.
Full ownership of source files, components and assets on final payment. I ask only for permission to show the work — and I will wait until after your launch.
Enough for consolidated feedback. If direction changes because we learned something new, that is the process working and we re-plan together.
Much of my work is under NDA. Send yours before the first call if that is easier — it will not slow anything down.
I join your standups, work in your Figma, follow your conventions. I do not import a process that fights the one you already have.
Every enquiry gets an answer within 24 hours — including the ones I have to decline, with a reason.
Describe the problem in a paragraph. I will tell you which service fits, what it would cost, and whether you actually need it yet.
madnansakhi@gmail.com