Product & Design Leader · AI & Data-Intensive Products

Your model is right. Your users still won't bet on it.

The half-second of doubt is the only thing I design. Fifteen years, five industries, one problem.

Arpit Maheshwari

Shipped for Telefónica O2 — 4M+ users  ·  PTC — NASA, Boeing, Toyota & Airbus among clientele  ·  AI products since 2019

Try it — name your problem

The receipts — four industries

What the design was worth.

3 hrs
Campaign planning, down from two weeks — once traders trusted the algorithm. Worth £69k more media value per client.
AdTech · per campaign
60%
Faster PE deal screening, after the model learned to explain itself.
FinTech · pre/post rollout
$1M
Saved every year, once the training platform moved off printed guides.
EdTech · vs 2016 print budget
4M+
Users on the two O2 products I drew, then shipped as code.
Telecom · O2 UK · publicly reported

Who you'd be hiring

Arpit Maheshwari, design leader

Arpit Maheshwari

By Friday of week one I've read your evals and sat in on your customer calls; by launch, the interface I drew is the code I shipped. Fully remote from Indore — 4–5 working hours shared with US East every day.

I read the model at the eval layer. I shape what gets measured. I ship the front-end.

On my first accessibility project I spent a week with my monitor switched off, navigating by screen-reader — designing for someone who isn't you starts by becoming them. That project started as my documented miss →

Fully remote  ·  GMT+5:30 · US-East overlap

How to read the six cases below

Every one of them runs the same four beats.

A model produces a score. A person doubts it. The design turns that doubt into an action they’re willing to take — and the action shows up in the business. The cases differ in industry and stakes; the shape never changes.

The contract behind every screen I ship

A language model has no edges. So I draw them.

Ask one anything and it answers — fluently, in or out of its depth. That is the whole danger: a user’s trust does not erode slowly, it dies in a single confident wrong answer. And most products bury their scope in a terms-of-service page and hope nobody tests it.

So before launch I write a capability contract — a one-pager the whole team signs. What the system is for, stated narrowly. Where it taps out, named specifically enough that a person can plan around it. And what it hands back to a human when it does. Then it goes in the interface, at the point of use, where the work actually happens.

In scope
It’s for
The job stated narrowly — “score deal risk from the data room,” not “analyse documents.”
Declines
It can’t
A named limit, not a hedge. “I can’t price illiquid assets” — never “results may vary.”
Hands back
Ask a human
A visible route to a person, designed with the care of the happy path. Never a silent, confident guess.

An honest “I don’t handle that” is not a weakness. It is the thing that makes “I do handle this” believable. A model that knows its own edges reads as a colleague; one that answers everything reads as a slot machine. Two rules I hold to: state the boundary once, where the user first meets the capability — a disclaimer on every screen reads as a product unsure of itself. And never write a contract you don’t enforce, because a stated limit the system quietly exceeds burns more trust than saying nothing at all.

How I Lead

Hire me and week one looks like this: I'm reading eval results before opening a design file, sitting silent on customer calls, and writing the diagnosis nobody assigned. By week two we're arguing productively.

The errata — a time I was wrong

My first accessibility pass was textbook-diligent and wrong. I loaded the interface with long, descriptive ARIA labels — the text a screen reader speaks aloud — convinced that more description meant more help.

Then I tested with blind users and watched my diligence fail. They don’t listen through sentences. They skim — jumping by headings and landmarks at speed, the way you scan a page with your eyes. My careful labels were slowing down the exact people they were built to serve.

So I switched my monitor off for a week and navigated by screen reader alone, then re-wrote the front-end with what that week taught me: terse labels, honest landmarks, headings that carry the structure. The full account, in the PTC case →

MY FIRST PASS every word, in order HOW THEY READ heading to heading More description was not more help. It was more to sit through.
Diagram — the reading behaviour I had designed against. Not a recovered artifact; the originals were never kept.

What you're hiring me to own

Human-in-the-loop design
The exact pixels where a person decides the model deserves their click, or doesn't.
The design language
A component system the next designer can run without me in the room, because it's documented, not memorized.
The ML/UX contract
A written promise between the model team and the user: here's what this system can do, here's where it taps out.

How I work with engineering, product, and customers

With engineering
Eval design before interface design, always. The front-end I own ships in the PR — commented and ready for review. When we disagree on feasibility, the cheapest experiment goes first and settles it.
With product / founder
I'll contest the roadmap when the numbers contradict it, and I sign up for outcomes rather than deliverables. The design doc is mine to write; the spec is yours.
With customers
Five calls in my first week, one a week forever after, and I read the raw support tickets myself. No AI feature ships until I've personally watched someone fail to use it.

Three things I'll refuse

  • Letting a score reach a user with no verb and no reasons attached. On the private-equity product I held the release until every claim could name its source and the model could say “I’m not sure” out loud. It shipped weeks late, on purpose, and that is the call I would make again.
  • Shipping an AI feature with no designed failure state — non-negotiable, and cheaper than it sounds: the failure state is usually one honest sentence in the interface, an hour of design work, not a sprint. Even a three-day MVP can afford the hour.
  • Pretending a design org runs itself — at founding stage I happily do all of it, Figma library to front-end, because there is no team yet. What I refuse is doing a team's ops — hiring loops, crits, tooling — while also shipping product weekly once there is one: that's two jobs, done as neither.

From the people who've shipped with me

Over the past four years at Talon, Arpit has been instrumental in shaping four distinct products from the ground up. His user-focused designs are remarkably intuitive yet adept at handling complex workflows… If you need a designer who excels at combining strategic vision with practical execution, Arpit is the person to call.
Anant EastCTO at Talon Outdoor
Arpit has worked with me for years and I value his honesty and hard work. He's been an integral part of my staff… involved in all facets of the team, from design to development to hiring and onboarding of new members.
Ryan KershnerUX Design Leader · managed Arpit directly
Arpit teams up with designers very well, not only does he flawlessly execute the UI implementations but he pushes back on design decisions using his UX expertise… I'd recommend Arpit to any team looking to improve their final product.
Katie AlterioProduct Designer · same team
Arpit consistently demonstrated exceptional speed, creativity, and attention to detail… What stood out most was his ability to present multiple design options along with clear pros and cons, which made it much easier for different stakeholders to make informed decisions and align quickly.
Sanjesh AnandaSoftware Engineering Leader · built the AdTech platform with Arpit

Proof, not philosophy

The same rules, as running code

Four of these patterns ship as trustlayer.js — a zero-dependency module with the calibration math included, and 42 tests that run in your browser. Plus a linter for the shape of an AI answer, and an honest teardown of how this site is built.

Open-source with tests.
See how I think,
not just what I ship.

0 dependencies · 42 tests · MIT
→ THE LAB

Process

Every product is a series of bets someone else has to accept. The method exists to make each bet smaller, better-evidenced, and easier to say yes to.

Act I · The wager

Desirable · feasible · viable — the overlap is the bet worth making. At PTC: four of five products killed to fund the one that worked.

Act II · The spiral

Listen → Structure → Prove → Land, in loops. Act / Review / Ignore was born in a Listen loop — watching traders override a model that was beating them.

Act III · The open loop

Shipping is the first honest data. I argued for a three-option card; the A/B made the one-option version permanent — the ship taught me what the mock couldn't.

The full method, with the diagram →

Contact

One seat. Full-time. Yours to offer.

I'm looking for one seat: founding product & design lead at an AI product company of 5–40 people — or a staff / director role where human-in-the-loop design is the actual job description. Fully remote from GMT+5:30 with 4–5 hours of daily US East overlap. Available — 4 weeks' notice.

Book 30 minutes

A real conversation, no pitch deck. If you would rather read first: the one-page hiring brief, the pattern library, or my technical screen, already answered.

Prefer email? use the form or the call link

No portfolio survives the first real week on the job. This one is just here to earn it.— Arpit

I reply within ~48 hours.

Not hiring but building something in AI? The patterns library and the founder checklist are free — take them.

LinkedIn X / Twitter