The distance between deciding something and it being real —
I lead a design team that stopped delivering Figma files. We design directly in Claude Code, in the client's repo — and I wrote the delivery standard that makes that safe for complex, regulated products. The proving ground: US healthcare, where getting it wrong is expensive.
Two of these came out of client engagements. One is under an NDA that isn’t going anywhere, so I rebuilt it from scratch — same problems, same decisions, my own data, on my own domain. On the other I took the client’s name and branding out, because those were never mine to publish. The third had no client on the other side of it at all. Everything below is open; the two client names are the only part I’m holding back.
A design sprint fails in the gaps — the decision made on a call nobody wrote down, the constraint that lived in one person's head. So we removed the gaps. Nothing is allowed to live only in someone's head.
One project per client; every document, call, email and correction joins the same running conversation. Transcripts join it only after I have read them and corrected what the model misheard — what becomes canonical has to be my judgement, not the model's. The artefacts the client signs are then built straight out of that thread, so the sheet and the conversation cannot drift apart. The client signs the list and the diagram, and only then does the thread change carrier.
There is no second thread. Everything that arrives later joins this one, which is what makes the sheet and the conversation impossible to drift apart — they are built from the same context.
“…the centre has thirty minutes to accept the kidney.”
“…the centre has thirty minutes to respond. Accepting is a separate act — it names patients.”
transcript · corrected before it was pasted inEvery client call is recorded and transcribed; internal calls too. But a transcript joins the thread only after I have read it and fixed what the model misheard. That one word is the difference between a thirty-minute timer and a thirty-minute decision — and the whole product was drawn from the corrected version.
Drafts Active Completed Archived. Ten columns; seven of them sort. OR/CIT counts from cross-clamp.KDPI rangeOR/CIT has four: none yet · in theatre · running (red) · stopped at handoverpublish to the boardA combined list hides which role is missing which screen. Split by role, the gaps are on the face of the document: four of the seven nav items are designed empty states, and five built screens are in no nav at all — reachable only from inside a donor or a run.
The list says what each screen holds. The diagram adds the thing a list cannot show: the boundary — the eight places where one role's screen writes something the other has to live with.
Only now does the thread change carrier. Everything after this point is code on a branch that auto-deploys to the client — which is why the gate is a signature and not a nod.
The most fragile point in the whole flow. It crosses on .md files, into every repo, on the right branch.
What isn't written down doesn't make it across.
The coded deliverable auto-deploys to the client's review site, so one fact drives everything: a merge is a publication. The standard I wrote has two jobs beyond tidy code — make an accidental publication impossible, and make a bad deploy detectable rather than merely unlikely.
I review in a browser against the spec, never by reading the diff — the defects that matter pass typecheck, lint and build while being plainly wrong on screen. The design PR is mine to merge, deliberately, because merging publishes; the dev PR belongs to the engineering team, on their schedule, so a naming comment never holds up a client demo. And a green tick only says the job ran, so a wave ends by diffing the deployed asset hashes against my own build.
Nothing in the standard is theoretical. Every warning in it is something that went wrong once — and cost real time to find.
M.Des in User Experience Design, AI specialisation — Jindal School of Design & Architecture, O.P. Jindal Global University. Earned in the margins of a full-time job.
Nearly five years of it. Regulated workflows, many roles, real accessibility requirements, and stakeholders who know their domain far better than I know mine. It's the environment that taught me to write everything down. The domain is the proof, not the ceiling — the same discipline carries anywhere the stakes are real.
I'm from Panchkula, near Chandigarh — studied here, live here, never particularly wanted to leave. I did my master's in the margins of a full-time job: two years of intensives, immersions and a great many late nights.
The thing I'm actually good at is finishing. I like the part most people find tedious — the state nobody designed for, the edge case in the role matrix, the fourth review pass. My work reads as pedantic until the week it saves someone.
Away from the desk: snooker, cricket, and an unreasonable number of Nolan rewatches.
I asked that publicly and never got a good answer. If you're hiring for the thing I actually do — design judgment carried all the way to the merge — let's talk.