Hey, I'm Neel, a product designer and design engineer. I design software and direct AI agents to ship it, from a 9-platform design system to a freight tool that books real shipments.

I help brands create Digital Experiences

H1Frame Heading

Welcome to my UX design world, where I blend creativity & empathy to craft digital experiences that delight & inspire users.

Design Case Studies

Tho8

Graduate capstone Designed and built solo HCDE 590 / 591 2025–2026

Tho8.

I designed and built a thinking tool that shows its work. Solo, over about a month: the research, the product, the design system, and the code that runs it.

It started with one thing I kept seeing in interviews. People don't lose ideas when they write them down. They lose them on the way back.

What I did

Research, product and UI design, the design system, and the full-stack build. I directed the AI that wrote most of the code, and I owned every judgment call.

Team

Two people (Luhmann's Quorum). I owned the design and the build.

Context

MS Human-Centered Design and Engineering, University of Michigan.

Live

A working prototype at tho8.app. No users, and that is the truth of it.

00 · At a glance

The short version.

We watched six knowledge workers lose ideas, forget note titles, and give up on search in under thirty seconds. So we designed a note-taking workspace where capture is effortless, connection happens by meaning, and every AI nudge earns trust with a one-line reason and a clickable quote.

Contextual user interviews
(3 grad researchers + 3 knowledge workers)

Tools benchmarked against
user-centered tasks

Core screens designed
and prototyped

Rounds of moderated
usability testing

01 · The problem

Ideas don't die at capture.
They die on the way back.

Across every interview, the same loop kept breaking: people wrote the idea down, but couldn't find it, couldn't link it, or couldn't trust the AI that tried to help them with it.

"I know I wrote this somewhere. If I can't find it in thirty seconds, I just rewrite it."

Capture is fast; setup kills adoption.

Every participant used the lightest tool on their phone (Apple Notes, Google Keep, Drafts), then moved it into their "real" system later. Tags, templates, and required fields at capture time made ideas vanish.

Linking breaks when you can't remember titles.

Everyone had to stop writing, open search, try three queries, and often gave up. The mental model was "link by idea," but every tool asked for an exact page name first.

AI suggestions without proof get ignored.

A "related note" with no reason was treated as noise. The moment the system showed "because: shared citation with Kahneman and Tversky", people trusted it, and they used it.

02 · The vision

Four loops. One surface.

From the research, one shape kept emerging. Knowledge work isn't a funnel. It is four nested loops that reinforce each other. If any loop breaks, the system feels broken.

Capture

don't lose it
in ≤2 taps

Email / Slack handoff

Connect

link by meaning,
not titles

Can't recall titles

Retrieve

find in
≤30 seconds

No proof → ignored

Resurface

right idea,
right moment

Every resurface seeds the next capture, and the loop closes.

Capture

Quick Note (Cmd+N), Clipboard Watcher, Daily Sweep. Zero required fields, automatic context stamp.

Connect

Link-by-idea palette, fuzzy suggestions with typed relations (supports, contradicts, example-of).

Retrieve

Quick Find & Ask (Cmd+K) with natural-language queries, Answer cards with block-level preview.

Resurface

Inline nudge chip with a one-line because…, only while writing or reading, never as a push alert.

03 · Process

Two semesters,
five phases.

We stayed disciplined: problem discovery first, solutions last. Every decision had to trace back to an observation, a quote, or a measured friction point.

PHASE 01

Literature Review

Zettelkasten, personal knowledge graphs, external cognition, explainable recommenders (XAI-RS).

PHASE 02

Benchmarking

6 tools evaluated across 4 user-centered tasks: capture, connect, retrieve, resurface.

PHASE 03

User Interviews

60-min contextual sessions with 6 participants using their actual note setups. Artifact walkthroughs + task probes.

PHASE 04

Synthesis

Affinity mapping → 8 clusters, 10 underlying requirements, each traceable to ≥2 observations.

PHASE 05

Design + Test

Low-fi → hi-fi prototype on Figma, 2 rounds of moderated usability testing (V1 → V2).

04 · Benchmarking

What today's tools
get right, and wrong.

We ran the same user-centered tasks through six networked-note tools, graded each on six dimensions, and mapped the gaps to problem hypotheses. Structured relations help trust. Global graphs overwhelm. Resurfacing is rarely built-in.

Tool	Capture	Connect	Retrieve	Resurface	Trust	Our takeaway
Obsidian						Local-first power; requires setup; global graph becomes a hairball.
Notion						Structure helps trust; mobile capture is slow; no native resurface.
Logseq						Block-level precision; journal-first flow; graph hides block connections.
Tana AI						Typed supertags aid provenance; AI link quality varies.
Mem						AI-first capture; users flag silent link accuracy drift, a trust gap.
Readwise Reader						Anchored provenance inside documents; weak cross-document linking.

05 · User research

Six people.
Six setups. One story.

Sixty minutes each, screen-sharing their real vaults, thinking aloud through four task probes in the tools they already use. No hypotheticals. Every observation traces to a real moment of friction.

Doctoral student

Economics · Notion + Obsidian

Master's student

HCI · Obsidian + Drafts

Master's student

Data Science · Logseq

Product Manager

Notion + Confluence + Obsidian

Strategy Consultant

OneNote + SharePoint + Obsidian

Senior UX Researcher

Healthcare · Notion + Obsidian

"I'd remove the need to remember titles. If I type a phrase, propose precise candidates with a short because."

P2, Master's student, HCI

"The strongest trust signal is a shared citation. Tags are weak. Recency alone doesn't convince me."

P1, Doctoral student, Economics

"I never tag on the phone. It slows me down. Capture has to be a sentence and a title, that's it."

P3, Master's student, Data Science

06 · Insights

The six patterns
that shaped every decision.

Eight affinity clusters collapsed into six durable insights. Each one has a measurable threshold users will walk away from if we break.

Capture must be instant.

Zero required fields. ≤2 taps. Everyone captures on their lightest tool first. Setup kills adoption, not features.

Linking breaks on title recall.

All six participants wanted to link by idea, not by exact page name. The editor has to meet them at the cursor.

Retrieval has a 20–30s budget.

Past it, people ask a colleague or rewrite the thought. Search must tolerate natural paraphrase and show a clear next hop.

Nudges only in context.

No push notifications. A small inline chip while editing/reading, with a one-line because…, dismissible in one action.

Trust comes from block-level proof.

Shared source > 2-hop path > specific phrase > tags/recency. Page-level "related" feels vague. Quote-level proof earns a click.

Cross-tool reality is non-negotiable.

Every participant lived in 2–4 tools. The handoff between email/Slack and the main vault is where ideas actually die.

The Trust Ladder.

When we asked "what would make you trust this suggestion?", participants ranked evidence types in a strikingly consistent order. We turned that order into the design of every AI surface in Tho8.

Shared source"Both notes cite the same paper / interview / dataset."

2-hop path"A connects to B via concept C", a visible chain.

Specific shared phraseNon-generic term or exact quote.

Tags / recencyWeakest signal, ignored in testing.

Stronger evidence ↑ Weaker ↓

07 · Design principles

Rules we didn't break.

Every screen, every flow, every AI surface had to pass six gates. If it failed even one, it got rewritten or cut.

Zero-friction capture

One shortcut, one field, one sentence. No tags, no templates, no modal barriers.

Link from fuzzy cues

A phrase, a keyword, even a misspelling. The palette meets the user mid-thought. No title recall required.

Proof over polish

Every suggestion carries a one-line because… and a clickable block-level quote. No invisible magic.

30-second retrieval

Natural-language search, answer cards, one-hop helper. If the first result fails, the next hop is obvious.

Focused local graph

Scoped around the active note, ranked neighbors, capped node count. Never the global hairball.

Progressive disclosure

Normal users get simple capture → suggestions → save. Power users get typed links, filters, graph radius controls.

08 · Key screens

Eight surfaces,
one coherent workspace.

A three-pane shell anchors the product: library on the left, note canvas in the middle, intelligence panel on the right. AI never opens in its own app. It lives next to the cursor.

01 · CORE

Main Workspace

Three-pane shell: library, note canvas, insights rail. Inline suggestions appear beside the cursor, never in their own window.

02 · GRAPH

Second Brain · Holistic Graph

Local scope around the active note. Ranked neighbors. AI idea generation from the selected node, anchored to visible context.

03 · CAPTURE

Quick Capture · Cmd+N

Lightweight overlay on top of any screen. Auto-adds source + timestamp. One primary action: save to Inbox.

04 · RETRIEVAL

Quick Find & Ask · Cmd+K

Natural-language query + typed-in-own-words tolerance. Answer card on the right shows synthesized block + exact evidence.

05 · TRIAGE

Daily Sweep · Inbox triage

End-of-day review of everything captured today. One-click actions: Promote · Link now · Archive. Smart-suggestions nested.

06 · CONNECT

Link-by-idea Palette

Highlight text, hit Cmd+K. Fuzzy suggestions arrive with short because… lines. Evidence preview lives in the right rail.

07 · NUDGE

Inline Suggestion

A quiet, dismissible pill appears right after the cursor. Hover shows the exact quote; Enter inserts; Esc silences it for that note.

08 · TRUST

"Why this suggestion?" Modal

Three-step reasoning path · confidence bar · exact evidence cards. Designed so users can verify the AI in five seconds, or reject it.

09 · Where it stands

Honest about what
it is, and isn't.

Tho8 is a working, deployed prototype, built as a graduate capstone. It was never released, and it has no user numbers. That is the truth, and it is not the point.

What I can prove

I designed and coded the whole thing myself. A real full-stack app running at tho8.app, not a Figma file. Twenty-five commits, all mine, over about a month.
I ran the research. Six interviews, a six-tool benchmark, two rounds of moderated testing with real people.
I audited my own build hard enough to score it 6.5 out of 10, and I wrote down every problem I found.

What I will not claim

That anyone used it. No adoption, no active users, no growth.
Any before-and-after number. Six people is enough to find what confuses them and not enough to measure a lift, so I fixed the confusion and left the percentages alone.

I tested with six people and turned their confusion into specific fixes. A save state they could finally see. A graph that stopped crashing. A reason attached to every suggestion. That part is real, and it is the part worth judging.

10 · Design system

A quiet interface
for loud thinking.

Calm dark surfaces so the words stand out. Warm orange reserved for exactly one thing: system intelligence. If it's orange, the system is helping, never just decoration.

COLOR

Warm orange on cool neutrals.

A single warm accent against a palette of cool neutrals creates unambiguous signal. Orange = AI presence. Everything else steps out of the way.

F2572B

FFB38A

0F1114

1C2128

232831

6B7079

TYPOGRAPHY

Manrope · single family.

Display · 800 / 88px

Second brain.

Headline · 700 / 32px

Link by meaning, not title.

Body · 400 / 17px

Fast capture · recognition over recall · transparent intelligence.

Monospace · source quotes

because: shared citation · Thaler & Shefrin (1988)

10 · Reflections

What building it
taught me.

The thing I had backwards at the start was treating trust as something the model earns by being good enough. It isn't. Trust is a design problem. People believed a suggestion the moment they could see why it was there, and ignored it when they couldn't, however good it was underneath.

So the real work was never the model. It was making the reason visible, making the save state visible, making the graph start somewhere a person could actually stand. Small, unglamorous things. That is where the trust came from.

The other thing I learned is that the fastest way to find what is broken is to measure your own work a new way each round, not to walk the same screens again. Six people, two rounds, and a hard look at my own build taught me more than another week of polish would have.

See it running at tho8.app

Tho8

2025-26

A UX Design Capstone at
University of Michigan

Press esc to close Close

Lumen

DESIGN SYSTEM WARP · 2026 SOLE DESIGNER v0.15.0

Lumen.

I built Warp's design system on my own, and directed the AI that wrote most of the code. What's mine is the problem, the visual language, and every judgment call. The AI did the typing.

What I did

The token architecture, the governance, the LLM-first thesis, and the QA bar. The decision records read: Neel, mandate; Claude, implementation.

Team

One designer. I worked directly with the founders and directed the AI agents that did the build.

Context

Product design engineer at Warp, a freight company that went AI-native and ran lean.

Stack

Figma · DTCG JSON · Style Dictionary · shadcn registry · Next.js · Tailwind v4 · Playwright

00 · At a glance

The short version.

Warp ships fast with a small team, across a lot of product and marketing surfaces, on web, mobile, and native. Each one had drifted into its own look. When I audited just our transactional emails, I found three separate design systems running at once, with three different shades of brand green. Lumen makes them one, and it is built to be read by the AI agents writing most of the code, not only by people.

887

Design tokens
DTCG · 3-layer taxonomy

Components
shadcn registry · md + json

Platform targets
web · iOS · Android · macOS …

Architecture decisions
ADRs, dated and load-bearing

01 · The problem

Three failure modes
the system kept landing in.

Warp already had a brand: a loud green and a dark, dense operator feel. What it did not have was the layer that turns a brand into a system, the part that makes every screen agree with every other screen. So each team rebuilt the same pieces its own way, and every AI agent that touched the code drifted a little further from the intent.

Three or more design systems on one surface isn't a mess to clean up. It's a sign that no one was ever put in charge of it.

01 · DRIFT

Primitives forked silently.

Every team reinvented the same pieces, because there was nothing canonical to copy. Each PR that duplicated an old pattern locked in someone else's one-off, and the greens, the typefaces, and the card styles quietly forked apart.

02 · DOCS LIE

Tokens changed; prose didn't.

When we retired the green glow on shadow tokens, the check passed at the token layer, but every doc still taught the old contract. Agents read the docs and faithfully built the retired rule back into the code. A check on the tokens can't see the prose.

03 · AGENTS BLIND

LLM-first was an afterthought.

Cursor, Claude, Copilot, and Codex all touched our UI every day. None of them had a contract they could read, so they wrote what their training data suggested, a generic SaaS look, not Warp. The system had to be legible to a machine first, then friendly to a person.

02 · The synthesis

I stopped choosing
between them.

The brief asked for Apple: clean, minimal, Ive and Rams. Warp's real character is a freight Bloomberg terminal, dense and dark and full of live numbers. Those aren't opposites. They live at different layers, so I stopped choosing between them and started stacking them.

Layer 01 · Discipline

Apple, Ive, Rams.

The typographic / motion / spatial rules. How the system behaves.

1.25 modular type scale, tight tracking on display
4-pt base on an 8-pt soft grid
Hairline borders carry separation; shadows are reserved for floating UI
Decelerate, never bounce; UI motion under 200 ms

Layer 02 · Substance

Warp's material.

The palette, density, and signature gestures. What the system is made of.

Obsidian #0D0D0D canvas, a neutral near-black where R = G = B
Spring Green #00FA8A, one role only: action, live, or success
Satoshi for every role, with OpenType tabular figures carrying the numbers, no second font
Three signature primitives: Stat, LiveDot, RateTicker

Layer 03 · Psychology

50 ms halo, peak-end.

The micro-behaviors that make discipline + substance feel inevitable.

50 ms first-impression halo, where the whole chrome lands in one paint
Aggressive hierarchy: 1.5 to 2x weight gap between focal and support
Peak-end micro-interactions: hover, focus, validate, succeed
One disciplined accent; a second loud color is a brand violation

03 · Foundations

One mood. One mark.
One face.

Three families of color, one typeface, one spacing grid. I kept the palette small on purpose, because a single accent only reads as loud when nothing around it competes.

Lumen Foundations page, Obsidian canvas with Spring Green accent and Satoshi typography

Color · 3 fams

Obsidian, neutral, accent.

Obsidian #0D0D0D canvas, R = G = B, no green tilt. Cool grays carry the hierarchy. The Spring Green was already Warp's brand color, used hundreds of times in the code before me. My part was the discipline: it means action, live, or success, and it shows up nowhere else.

Type · 1 face

Satoshi, every job.

One variable family, Satoshi, carries UI, display, body, and numerals, weights 300 to 900. The tabular, monospace feel on numbers comes from OpenType features on that same face, so there is no second font to load. That one call cut four families to one.

Spatial · 8pt soft

4-pt base, 8-pt soft grid.

A 4-point base on a soft 8-point grid, with a few half-steps where the strict grid leaves an optical gap. Hairlines separate surfaces, not shadows.

Motion · decelerate

Decelerate, never bounce.

One easing family, decelerating, never bouncy. Reduced motion is a first-class spec, not a bolt-on. The one recurring animation in the whole system is a single dot that pulses when something is genuinely live.

04 · Eight surfaces

Same language.
Different density.

Lumen ships eight reference templates, the canonical answer to "is this how a Lumen surface looks?", across every density from marketing breath to operator-dense.

Landing template, type-led hero with live rate ticker

Marketing & Landing

Type-led hero. Screenshot-as-proof. Live rate ticker. Apple-disciplined chrome on Warp-substantive content.

96px
HERO

SaaS Dashboard

The operator-portal pattern. Sidebar nav, KPI grid with sparklines, sortable table, live activity rail. Dense and scannable.

24px
OPERATOR

Web Tool

Single-purpose utility. Preset rail, focused canvas, control panel, output panel. The pattern for any calculator, simulator, or one-shot job.

32px
COMPACT

Commerce

Storefront patterns for Shopify, BigCommerce, Woo. PDP with variant pickers, drawer cart, trust strip, all on the same Lumen typographic discipline.

24px
STOREFRONT

Mobile

iOS and Android, side by side. Same visual language, platform-native chrome: Apple HIG on iOS, Material 3 on Android. Same tokens, different mappings.

44pt
TOUCH

Native Desktop

macOS and Windows window chrome. Vibrancy / Mica titlebars. Where the future Lumen SwiftUI + WinUI adapters land.

NATIVE
CHROME

Foundations

The system's first principles. Color ramps, type scale, spacing, elevation, motion, micro-interactions. The route everyone reads first.

REFERENCE

Library

Every primitive in at least one default state and every variant. The "is this how a Lumen X is supposed to look?" reference.

GALLERY

// One token system, eight surfaces. Switch the mood or the density; the language holds.

05 · Architecture

LLM-first,
human-second.

Most design systems are documentation that engineers translate to code. Lumen flips it: the schema is the source. Tokens are DTCG JSON, components ship as md + json sidecars, and every AI agent gets a layered contract it can read natively.

01 · Primitives
raw, mode-agnostic

obsidian.950 obsidian.900 neutral.100 accent.500 · #00FA8A space.4 type.scale.1.25 radius.10

02 · Semantic
role-based, mode-aware

surface.page surface.raised text.primary action.bg border.hairline elevation.md

03 · Component
only when needed

button.primary.bg stat.value.color livedot.pulse.color

WebCSS vars

Tailwindv4 @theme

TypeScriptconst map

iOSSwift class

AndroidXML

ComposeKotlin

FlutterDart

ShopifyLiquid

JSONflat

For humans

component.md

Frontmatter + canonical sections. Anatomy, usage, do/don't, motion, a11y. Designers and engineers consume this directly. MDX-compatible for the doc site.

For agents

component.json

The machine-readable schema. Validated by JSON Schema, kept in lockstep with the md via CI. shadcn registry pulls from this directly: npx shadcn add <registry>/button.

For tools

llms.txt + AGENTS.md

One layered contract, all mirroring a single source so they can't drift: llms.txt for discovery, AGENTS.md for the universal rules, then tool-specific files for Claude, Cursor, and Warp. The rules are lint-enforced.

06 · The audit loop

R1 to R16.
Vigilance, retired.

Most systems drift because they lean on people remembering the rules. I replaced that with checks the build runs on its own. Each round added a new kind of measurement, not another walk through the same screens, and a new kind of measurement is what kept surfacing a new class of bug.

R1-R3

v0.12.7 → v0.12.9
3 surface bugs

Static @ desktop · interaction · contract comparison.

Sticky-header bleed; PDP variant pickers failing first click; hardcoded calendar offsets. Per-route MCP audits via Claude in Chrome.

closed inline →

v0.13.0
ADR 0023

Meta-contract integrity.

Version chips drifting across llms.txt, USING-LUMEN.md, README.md. release.mjs --banner-only rewrites them in lockstep on every release.

automation +1 →

R5-R6

v0.13.1 → v0.13.2
ADR 0024 + 0025

Mobile metrics & SSoT documents.

320 and 375 viewport audits, catching layout inflation and a11y gaps. Then a catalog drift, where the docs disagreed on how many components existed. New single-source files, auto-regenerated indices.

SSoT installed →

R11

v0.14.0
ADR 0030

Green retired from every shadow.

Brand identity = green BG fill alone. lint:shadow-no-accent walks the DTCG JSON and fails CI on any token referencing accent in a shadow. Token-source layer locked.

token-lint live →

R14

v0.14.3
ADR 0033

Docs-to-tokens drift lint.

R11's token check couldn't read prose. Agents reading buttons.md rebuilt the retired green-glow rule straight back into the code, past the token check entirely. lint-docs-no-retired-tokens.mjs now walks every .md and .txt in the repo and fails the build on any prescriptive use of a retired token. It runs off a RETIRED list, so the next retirement adds one line, not 200 find-and-replaces.

doc-lint live →

R16

v0.15.0
ADR 0035

A contrast bug becomes a system-level guard.

My own TMS, built on Lumen, shipped text at 1.66:1 on green across 11+ sites, because a developer reached for a token name that didn't exist and it quietly fell through. I added the token, a defensive component, a build-failing check, and a foundation doc. On its first run the new check caught the exact same bug hiding in Lumen's own example code. The lint paid for itself before it even left the toolbox.

1.66:1 → 14.7:1

Methodology · the lesson

A rule you have to remember is a rule that decays. Across a whole repo, with weeks between audits, someone always forgets and some tired reviewer always misses one. So each layer gets its own check: one on the tokens, one on the prose, because the token check never sees a doc and the doc check never sees a token. The build fails when either one breaks.

07 · The polish layer

Three primitives
that carry the brand.

An operator sees three small pieces of Lumen far more than any button: a number, a live dot, a rate ticker. These are where the operator-console feeling actually comes from, so they got most of the polish.

PRIMITIVE · STAT

Numbers as hero.

Big bold tabular figures, small tracked unit. Right-aligned in tables so digits stack. The most-read element on any operator surface.

98.2%

ON-TIME · LAST 7d

PRIMITIVE · LIVEDOT

One signature pulse.

8 px filled green dot, 2 px ring pulsing on a 3 s ease-out loop. The only ambient motion in the system, and it pulses only when something is genuinely live, never as decoration. Honors prefers-reduced-motion.

LIVE · 1,284 today

PRIMITIVE · RATETICKER

The marquee that earns its keep.

A horizontal stream of freight lane rates in tabular figures, on a slow continuous loop. It says operator console louder than any hero image could.

LAX → SFO$262 ORD → ATL$485 DFW → PHX$390 SEA → DEN$612 MIA → JFK$724 LAX → ORD$1,230 BOS → CLT$540 LAX → SFO$262 ORD → ATL$485 DFW → PHX$390 SEA → DEN$612 MIA → JFK$724 LAX → ORD$1,230 BOS → CLT$540

08 · Where it stands

Honest about what
it is, and isn't.

Lumen is live, and it runs real work. Our operator TMS is built on it, and the team's AI coding agents read from it directly. What it does not have is an adoption chart or a revenue line, and I am not going to draw one.

What I can prove

The size of the system, all built solo with the AI doing the typing: 887 design tokens, 98 components, 9 platform targets, and 33 written decision records.
A 16-round audit where I changed the measurement each round instead of re-walking the same screens. It kept finding a new class of bug every time.
On the reference build, in lab conditions: page load down about 31 percent, layout shift at zero, and zero unnamed controls across 714 interactive elements. Lab numbers, and I label them that way.
The contrast bug my own TMS shipped, fixed at the system level from 1.66:1 to 14.7:1 across every affected site.

What I will not claim

Adoption numbers. Real adoption is our TMS running on it and the agents reading from it, not a count across all of Warp.
Revenue or conversion. This is internal platform work. It buys coherence and prevents defects, and neither of those is a dollar figure I get to invent.

The honest value here is coherence that holds on a shrinking team, and defects caught before they ship. That is what a design system is for, and it is the part worth judging.

09 · Reflections

What building it
taught me.

The lesson I trust most from Lumen is that vigilance is the wrong thing to spend on consistency. On a team that keeps shrinking, and writes more of its code with AI every month, nobody has the attention to police a convention. So you encode the rules you actually care about, or you watch them decay.

Most of the real work was invisible. Every decision I cared about had to end up as three things at once: a token, a written record, and a check the build runs on its own. And the whole thing had to be readable by an AI agent first, because on this team the agent is usually the one holding the keyboard.

I hold Lumen to a hard bar, and I'd rather describe it as rigorous and honest than finished and perfect. The scar tissue, the bugs it found in itself and then made impossible, is the part I'm most proud of.

Lumen Design System

2026

Vertically integrated design system at
Warp · Sole designer, eight surfaces, nine platforms

Press esc to close Close

Tracking Page

TRACKING PAGE WARP · 2026 SOLE DESIGNER FRONT-END ONLY

Tracking Page.

The public page a stranger opens to see where their freight is. It is often the only piece of Warp they ever touch, and the old one lied to them in small ways they could feel. I rebuilt it as an honest-states engine. The AI wrote most of the code under my direction. The problem, the states, the honesty rules, and the judgment are mine.

What I did

Research, the before-state reverse-engineering, the IA, the visual and motion design, and a 12-rule engine that computes the true status. Every judgment call.

Team

One designer. Rahul owns the production app I was modernizing. Troy, our CRO, set the frame. I directed the AI that did the typing.

Context

Product design engineer at Warp, an AI-native freight company that runs lean and ships daily.

Scope

Front-end only, zero backend change, proven by a live network audit. Lumen design system. A vanilla prototype and an Angular drop-in.

00 · At a glance

Counts, not outcomes.

I want to be precise up front, because on this project the honest version is the strong one. There is no adoption chart here and no conversion line. What is real is the scope, the craft, and a status the page cannot fake. Everything below is counted, not claimed.

// verified scope + craft facts · re-derived from the repo

Shipment states
every failure designed

Rules in the engine
that compute the true status

Backend changes
proven by a live audit

Build stacks shipped
vanilla + Angular, one core

01 · The hard part

The page told the user
less than it knew.

The old page did not lack data. It looked like a hacker terminal, matrix green and monospace on a map, so a person opening it from a Walmart delivery email wondered if their package was even real. And underneath the look, it was dishonest. The backend knew nineteen distinct shipment states. The headline showed four. So a truck near pickup and a truck near your door both read the same two words.

The order says cancelled, and the page is asking how my delivery went. That is the page lying to someone, in a small way they feel before they can name it. my reaction, seeing the old rating widget on a cancelled order

Here is the same cancelled shipment on the old page and on the redesign. Nothing about the data changed. Only whether the page tells the truth about it.

Before · the old page shipment: cancelled

VEHO · ORDER P-57127-2619

dead button, no handler

IN TRANSIT

the shipment was cancelled

In Transit

rating on a cancelled order

Arrival alerts

on, with no recipient behind it

Four failures on one card, and none of them are a data problem.

After · the redesign shipment: cancelled

Veho · Order P-57127-2619

Cancelled

This shipment was cancelled

Cancelled Tue, May 13. No further movement.

correct Rating hidden on terminal states. Nothing left to rate.

Alerts off Set up alerts →

a two-state setup, not a toggle that lies

Same data. The page says what is true, and hides what would be false.

02 · The honesty engine

The page computes
its own truth.

Rather than trust the backend label, which leaked "In Transit" onto returned and cancelled orders, the page derives its state locally from the real fields, using twelve priority rules, and drives every visible string from that one source. So the status can never contradict itself. If the dot pulses, the shipment is genuinely moving. If it settles, it is done.

Raw fields, on the wire

mapStage stop.pillState[] disposed

semanticState

12 priority rules, one derived value

"On the way to Hialeah, FL"

pill tone · sentence · action · journey tone, all from one field

// the twelve states the page can be in, each with its own tone, sentence and action

pending

Booked, waiting on pickup

at-pickup

Driver arrived at origin

pickup-failed

"Pickup failed in Orlando, FL"

in-transit

"On the way to Hialeah, FL" · live

arrived-at-dropoff

Driver at the destination

dropoff-complete

Handed over at dropoff

delivered

"Delivered to Hialeah, FL" · rate it

cancelled

Terminal · no rating, no alerts

return-initiated

A return has started

returning

On the way back · live

returned

Back at origin · settled

disposed

Terminal · full history shown

The rule that runs the whole page

There is not a single percentage on this page. No fake progress bar, no invented ETA confidence, no "87% of the way there." When the arrival time is unknown, the page says so, and it hides the field instead of printing a comforting number that is not real. On a tracking page, a made-up number is the easiest lie to tell, so it is the one I refused to build.

03 · What I decided

Three rules,
each from a caught lie.

I did not start with principles. Each of these came from catching the design tell a small lie, and I wrote each one down so I would not repeat it. That is most of what senior looks like here: not fewer mistakes, but a rule left behind after each one.

Rule 01

Say the true thing.

The headline is computed from the real shipment state, so it can never say "In Transit" on a returned order. When a state has nothing honest to show, the page hides the field rather than faking it. An empty ETA hides its card. An empty history hides its section. No comforting placeholder.

Caught: a cancelled order rendering a five-star "how was your delivery" widget. Fixed by hiding it, not by rewriting the copy.

Rule 02

Chrome must equal function.

Every control that looked interactive had to actually do the thing it promised. I killed the decoys by building the function the chrome implied, not by deleting the chrome. The dead "More options" button became a real copy-link button. The "Contact support" button that opened an unrelated pop-up became an actual phone link.

Caught: a "More options" button with full hover and focus states and no click handler. It survived the very review that coined the rule against it.

Rule 03

Care is total, motion is earned.

Every state got the same attention, including the ugly ones. Pickup-failed and disposed auto-expand their full history, because that is exactly when a person needs the whole story. The motion is state-derived, not decorative. One flag drives the live pulse on the status dot, the driver, the newest event, and the map pin, so they can never disagree about whether the shipment is moving.

Caught: a pulse keyed to a color tone, so a delivered-and-destroyed shipment pulsed as if a truck were rolling. Re-gated on real motion.

04 · The one I got wrong twice

The alerts control,
in three tries.

The best story I have from this project is a small control I got wrong more than once in a single session. The lasting fix was not a widget. It was the habit the misses forced me into.

A toggle that opened a modal.

I built the alerts affordance as a toggle. It did not toggle anything. It opened a setup pop-up, so the control lied about what a click would do.

lies about the click

A "real" toggle that flipped on.

So I made it flip ON for real. But there was no recipient behind it, no email, no number. It was claiming a state that did not exist yet. On with nothing to send to is still a lie.

claims a false state

A two-state setup, no toggle at all.

"Off, set up alerts" when nothing is configured. "On, email to [email protected], customize or disable" once it is. The state becomes real at the moment you save, and never a click before.

state before chrome

The habit it left behind

The fix that stuck was a way of working, not a component. Before I ship a control now I run its three clicks in my head: the first click, the undo, and the cold-land. Predict what the user does with it, then criticize your own decision, before someone else has to.

05 · The handoff

Shipped twice,
guaranteed identical.

A redesign is worth nothing if it drifts on the way into production. So I froze the backend, proved it, and shipped the design in a way that makes the built UI provably match the reviewed one.

Proof

Zero backend change.

I opened a real shipment in the browser and audited every network call. Everything the redesign shows was already on the wire, so the whole thing is a front-end job. That audit is what made the port cheap.

Method

Reskin the data, not the UI.

For the Angular drop-in I refused to re-author the design in templates, because every re-typed pixel is a chance to drift. I reused the reviewed render and motion core byte-for-byte and adapted only the data layer.

Check

A four-agent audit.

I put the drop-in through an adversarial ship-readiness pass that type-checked it under the real TypeScript compiler and caught a strict-compile blocker before a developer ever would. Then it was handed off.

06 · Where it stands

Honest about what
it is, and isn't.

Deployed prototype · handed off · no adoption

This is a ship-ready, backend-audited, adversarially-reviewed redesign package. I deliberately rolled back a standalone deployable version, because a standalone app was not what the team needed. It is not a launch I can attach traffic to, and I would not draw a chart pretending otherwise.

What I can prove

Nineteen shipment states designed from one data model, including every failure and terminal state, not just the happy path.
A twelve-rule engine that computes the true status locally, so the headline cannot contradict the shipment. Verified in the shipped code.
Zero backend change, proven by a live network audit of a real shipment. Header chrome trimmed from 88px to 56px. Error text at 9.72:1 contrast.
An independent review of the validation pass came back "ship-ready, no blockers." The Angular port reuses the reviewed code byte-for-byte.

What I will not claim

Adoption or traffic. The standalone version was rolled back and production integration was handed to the team. I cannot attribute usage to it, so I do not.
Conversion or support deflection. The promo shipped with analytics hooks specified, never instrumented. No number exists, and this page of all pages has no place for a fake one.

The honest value is the craft and the judgment, which live fully in the work whether or not anyone used it yet: a status a person can trust, every state told truthfully, and a package a single engineer can integrate with a guarantee that the UI matches the design.

07 · Reflection

The smallest surface
is the honest test.

A tracking page has no room to hide behind features. There is one job and one card, and about thirty seconds of someone's attention. Every choice is either true or it is a small lie a person feels before they can name it.

So the best thing I did here was not the reskin. It was learning to predict what a user does with a control before I ship it, and to criticize my own decision before a stranger has to. On this project I turned each miss into a rule instead of a patch, and those rules outlasted the page.

The AI wrote most of the code. What I brought was the refusal to let it print a comforting number that was not real, on a surface where that would have been the easiest thing in the world to do.

Tracking Page

2026

The public page a stranger judges Warp by · Sole designer · a 12-rule engine so the status can't lie · front-end only, deployed prototype

Press esc to close Close

TMS Builder

OPERATOR TMS WARP / 2026 SOLE DESIGNER + BUILD DIRECTOR LIVE ON REAL DATA

TMS Builder.

A free operator TMS for small shippers. I had already built one version to a bar I was proud of, then rebuilt it from scratch, because the thing making it feel cheap was buried in the architecture, not the pixels. I directed the AI that wrote most of the code. The problem, the data model, the sitemap, the honesty rules, and every judgment call are mine.

What I did

Every design and IA decision, the data model, 119 recorded decisions, and the QA bar. I verified each surface in a real browser.

Team

One designer, directing AI coding agents. I set scope with Warp's CRO and reviewed every diff myself.

Context

Product design engineer at Warp, an AI-native freight company that runs lean and ships daily.

Stack

Next.js 16 · React 19 · TypeScript · Tailwind v4 · shadcn · OKLCH tokens · Supabase · Warp BFF · Claude (server-side)

00 · The afternoon this is for

An exception
just landed.

It is the middle of the afternoon. An operations manager at a small shipper is watching carrier spend and shipment status on a 27-inch monitor in a bright warehouse office. Something has gone wrong with a load and they need the answer now. The tool they open is a transportation management system, the software a shipping team lives inside all day to quote, book, track, and reconcile freight. The incumbent one answers with a wall of red they cannot trust and a three-click hunt to learn what "overdue" even means. Tools that run this job cost fifty to five hundred thousand dollars a year, and they feel like they were built for interchangeable labor, not for the person actually using them.

Warp's bet is the opposite. Give a small shipper a free-forever TMS good enough that they never leave, because the tool becomes their daily surface and Warp's freight network is the thing running underneath it.

I had already built this once, to a bar I was proud of. Then its own post-mortem told me something I did not want to hear.

01 · At a glance

The size of the build.

These numbers count the work, not its adoption, and I keep those two things apart on purpose. Across both generations of this product I directed and reviewed 1,475 commits, all under one name. This is the second generation, the clean-room rebuild.

1,011

Commits I directed
Mark II · 4 weeks · sole author

119

Decision records
ADRs · superseded, not edited

359

Test files
lock the honesty rules to the build

Routes across 8 destinations
a whole product, not a demo

// the AI wrote most of the code under my direction. the commits, the decisions, and the tests measure the scope of what I designed and drove, not a number of people using it. the last full suite ran 4,467 tests green across 345 files on 2026-06-29; the file count above is current at head.

02 · The diagnosis

The defect was
architectural, not visual.

Mark I had reached genuine Linear-grade polish, through nine screen rebuilds and six dedicated polish passes. So the uncomfortable part of its post-mortem was this: the reason it had ever felt cheap was not the theme and not the colors. It was a missing layer.

Mark I · what was wrong

No layer between tokens and screens.

There was no shared vocabulary of components, no one canonical header, heading, table, or stat card. So every new screen was a fresh styling decision, and the codebase quietly forked apart.

5 divergent KPI card implementations, none canonical
7 padding conventions competing across screens
26 pages grown under a system-shaped 7-item nav

Mark II · the harder fix

Build the layer first, then lint it.

Polishing screen by screen treats the symptom. I rebuilt from scratch, clean-room, with the semantic component layer and its checks present from the first commit, so the product cannot rot back into the state I had just climbed out of.

1 primitive layer screens read from, never raw tokens
8 destinations re-derived from the operator's jobs
+ executable checks that fail the build on drift

Mark IMAY 05 → JUN 15 · THE DONOR

464

commits

~110

sessions

S110

first deploy

Mark IIJUN 08 → JUL 07 · THE REBUILD

1,011

commits

119

ADRs

live

on real data

03 · The instrument

One triage-first order,
for everyone.

The dashboard opens with one honest sentence and leads with a ranked feed of what needs the operator, then tapers to the calm reads below. The donor offered a three-way "pick your worry" preset. I cut it, because a confident tool shows you the one right thing instead of asking you to configure your worry on first run.

Search or ask⌘K + New shipment

3 need your attention // error never renders "all clear" LIVE · synced 12s ago

Needs attentionranked · recovery window first

Exception Refused at dock, driver waiting#SH-48213 Stuart On Demand held 2h

Overdue pickup Not picked up, window closed#SH-48090 Averitt Express +1d 4h

Overdue delivery Past appointment, no scan#SH-47788 Old Dominion —

In motion

Arriving today

Delivered today

Carrier performanceverdict, not a bare %

Stuart On DemandReliable98.6%

Averitt ExpressSlipping91.2%

R+L CarriersReliable97.0%

SoutheasternToo few loads—

On-timelast 6 months

FEBMARAPRMAYJUNJUL

// a representation of the built surface, drawn in the product's own language: obsidian canvas, one green act, monospace tabular numbers. real screens run live at warp-tms-2.vercel.app.

01 · ONE GREEN ACT

The accent has one job.

Spring green means action, live, or selection, and nothing else. The only green in the whole shell is "New shipment" and the pulse on genuinely-live data. The active nav is a raised neutral, not a second green.

02 · NULL IS NEVER ZERO

An unknown renders a dash.

A missing cost shows a dash, never a fabricated 0 that would read as "free" or "nothing to do." A failed data read renders an error, never a false "you're all clear." The tests fail the build if either rule breaks.

03 · RED MEANS SOMETHING

Only true exceptions carry color.

A permanent wall of red trains an operator to panic-switch carriers. So only real exceptions and overdue loads carry a warm status, each with a dot and a word, never color alone. Everything else stays neutral.

04 · Four calls with a seam

The decisions I
can defend out loud.

Every one of these is a place I chose the harder or the smaller thing, wrote down why, and wrote the trigger for when I would revisit it. That written trade-off is the part I care about more than the screen.

ADR 0008

Eight destinations, not twenty-six.

I re-derived the whole sitemap from what the operator manages, not from the codebase's taxonomy. The donor had filed Accounting under "Network" and Invoices under "Analyze," a structure that served the code. Clustering by the user's real jobs collapsed 26 pages into 8, with the URL carrying every filter so any view is shareable.

What I gave upLabeled nav groups. At eight self-evident nouns they are chrome noise that die in a collapsed rail. Hairlines carry the clustering silently.

ADR 0014

One dashboard order. No preset switcher.

The research is that a small shipper opens this mid-crisis, judges it in the first session, and rates cognitive overload as their top complaint about incumbents. A first-run "what do you care about?" question costs a control to learn at exactly the decisive moment. So I shipped one confident triage order and poured the craft into making it impeccable.

The revisit triggerWritten into the decision: if real usage ever proves segments diverge, I do it as URL state, never a first-run interview.

ADR 0110

I removed features I had already built.

Reviewing the live quote form against the source-of-truth product, I found controls that product never had: a mode selector, a carrier-source selector, freight-class and NMFC fields. They added load for fields that are either derived or never reach the quote. So I stripped them, turned the extras into a post-rate filter, and kept the schema intact so nothing downstream broke.

The ruleThe best feature is no feature. I treat an unrequested field as a defect class, and I would rather cut working code than pad a form.

ADR 0030

One focus ring, always neutral.

Three drifted focus recipes became one outline-based ring, neutral even on destructive controls, because focus is not selection. I chose an outline over a shadow so it survives Windows High-Contrast Mode, where a box-shadow is dropped. Unified across roughly 35 files and locked by two tests, so re-fragmentation is a build failure.

The patternFix the class, never the instance. Every correction I make ends its life as a token, rule, or lint.

05 · The AI, honest by construction

The model routes.
The database answers.

This is the part I am proudest of, and it is the smallest. The command bar has a natural-language "Ask." It runs on one rule that makes it structurally incapable of making up a number.

The model can only emit a typed filter. It can never emit prose, a shipment id, a cost, or a verdict, because the schema has no such field and a validation gate rejects anything well-shaped but wrong.

You type

› exception LTL Dallas this week

→parse

The model emits only

status: [exception]
mode: [LTL]
cities: [Dallas]
date: 7d

→query

The database returns

SH-48213exception

SH-47788overdue

→ opens as a real, shareable view

Deterministic-first: the common query is parsed in zero tokens, instant and free Honest-off: the flag off is the honest absence of the affordance, not a broken feature Provenance shown: "interpreted with AI" is never dressed onto a plain parse

What I refused to build

A chatbot answer surface

The "agentic TMS" framing invites a chat box that types back sentences. A model narrating freight status in prose invites a fabricated answer, and a fake status is a dangerous lie in a tool people book loads inside. So it was never built.

What I shipped instead

A brain that reads your spreadsheet

Drop a messy lanes-and-weights file and an AI mapping brain reads the actual cell values, not just the headers, to map columns onto an editable review grid. Every AI-touched value carries a provenance marker and stays editable, and a booking re-validates the full real schema.

06 · How it runs on real freight

Designed disconnected.
Then wired live.

Live credentials arrive last, so I built the whole product to a designed disconnected state over typed fixtures first, verifiable with zero credentials. Then it was wired to Warp's real backend. Because every state was designed before any data existed, the empty, loading, error, and disconnected reads got the same care as the happy path.

The appNext.js 16 · RSC

Server Components by default semantic primitive layer one OKLCH token set optimistic writes

↓

Warp backendthe real production API

Warp gateway / BFFAES cookie pair · silent refresh Datahubread-only analytics customer_app / shipmentsJWT-scoped, per tenant

↓

Own seamsadded, not borrowed

Supabase · audit_log + search index deck.gl + MapLibre maps PostHog observability

default

populated

empty

first run

skeleton

error

never "all clear"

disconnected

designed, not blank

The whole thing has a dev-only switch to render any surface in any of these states over fixtures, and a rule that production can never render a fixture. That is what let me design honesty into the empty and error states before a single real row existed.

07 · When it met real data

The bugs only
real freight finds.

From about the halfway mark, the app was pointed at the real freight of Warp's actual enterprise customers, and I drove the visual audits live in my own browser. Surviving real Walmart and DoorDash and Gopuff data is a stronger signal than any demo, and it surfaced bugs a fixture never would.

The map that showed only circles

ADR 0088 · S75

On real Walmart lane data, short in-state lanes drawn as straight great-circle arcs collapsed into angular stubs, and lanes between coincident zips each drew as a hollow ring stacked on itself. The map became a pile of circles, with green landcover bleeding through the transparent ring centers.

The literal ask was "fix the carets." The live audit proved the rings were the real eyesore, so I went past the ask: distance-bowed arcs, and filled volume-nodes instead of hollow rings.

A query that crossed tenants

ADR 0118 · go-live

A four-agent go-live audit of auth, money, and tenant isolation surfaced one real issue. A customer filter matched on a substring, so a search for one tenant over-matched another whose name was embedded in a longer string.

I fixed it to match the whole delimited element the same session. Gopuff's carrier board fell from an over-counted 28,414 rows to a correct 16,754, and Walmart's count stayed exactly the same, which is how I knew the fix was right.

A 227-second read

ADR 0082

The quote-history read was doing a full scan of a 500,000-row collection on an unindexed sort. Measured, it took 227 seconds.

227s→~120ms

Sorting by the indexed creation id with an eight-second cap fixed it. Slowness is a design defect on a surface an operator opens dozens of times a day.

The agent that faked a pass

directing the AI

I fanned an audit out to several AI subagents. One reported back that it had completed an authenticated walk-through and everything passed. I did not take it at face value. I ran one independent check of a load-bearing claim, and the agent had fabricated the result. The auth path was still bouncing.

Now I always sample one load-bearing claim and verify it with my own tools, and I turned that specific catch into a real next phase of work.

How I build with AI

Speed comes from the agents. Trust comes from my own verification, in a real browser, on real data. The summary an agent hands back is just text, and text can describe outcomes the real side effects do not support.

08 · Scale, and what is mine

Big numbers live here.
I keep them honest.

This product renders serious freight. Those numbers describe the scale of what it displays, not revenue I drove, and I will not let one masquerade as the other. Here they are, kept in their own column.

The product's scale

The freight it renders

DoorDash tracked freight, rendered live~$402K / mo

Walmart on-time, across 687 May shipments99.7%

Enterprise orgs it ran against liveWalmart · DoorDash · Gopuff

The Warp substrate underneath12.4M quotes

// verified against source. this is what the instrument displays, tagged as the product's scale, never as my impact.

My contribution

What is actually mine

The problem framing and the sitemapmine

The data model and every design callmine

119 recorded decisions and the QA barmine

Directing the AI, and verifying its workmine

// the AI wrote most of the code. the judgment, the honesty rules, and the verification are the part that is mine.

I will never tell you I drove the $402,000 a month. I designed the instrument that renders it, and kept it from lying to the operator reading it.

09 · Where it stands

Honest about what
it is, and isn't.

It is deployed, and it ran live against the real freight of Warp's actual customers. A four-agent go-live audit of auth, the money path, and multi-tenant isolation rated it functionally launch-ready. What it does not have is an adoption chart, and I am not going to draw one.

STATUS · LIVE ON REAL DATA, PUBLIC GO-LIVE GATED BY THE OPERATOR

What I can prove

The size of the build, all directed by me with the AI doing the typing: 1,011 commits, 119 recorded decisions, 359 test files, 43 routes across a whole product.
It went live against real enterprise freight (Walmart, DoorDash, Gopuff) and I fixed real-data bugs a fixture never surfaces, including a cross-tenant query caught in the go-live audit.
Verified craft: axe-clean with a dedicated WCAG A and AA sweep, one unified focus ring locked by tests, a 44px touch floor, and a read cut from 227s to about 120ms.
The honesty rules are executable: a failed read never renders "all clear," an unknown never renders a fake zero, and the build fails if either breaks.

What I will not claim

Adoption or active users. The first real production booking is a supervised operator step I had not yet run, so there is no user count, and I will not invent one.
Revenue. Every dollar figure here is freight the product renders, never a business outcome I drove.
A conversion or task-time study. The research behind the design is external synthesis, used as rationale, not a measured result of this product.

What I would measure next

The honest measurement I do not have yet is the point of the next phase: the supervised go-live, then time-to-first-value from signup, exception-recovery rate, and whether the operator comes back the next day. Those are operator steps and real usage, not missing product.

10 · Reflections

What building it
taught me.

The most senior move here was not a screen. It was diagnosing that the defect was architectural and paying to rebuild the foundation, then compiling every correction into a token, a rule, or a check the build runs on its own, so it cannot come back.

The second lesson is that honesty is a design constraint with real teeth. The decisions I am proudest of came from one rule I would not bend, never let the tool lie to an operator. That is why I did not build the AI chat surface a model could fabricate answers through, and why an unknown value renders a dash where a lazier tool would show a confident zero. When people book real freight on a screen, a made-up number costs you their trust the first time they catch it, and you do not get it back.

And the third is about how I build now. The agents give me speed. The judgment, and the last check in a real browser, stay mine. Once, one of them handed me a passing audit it had made up, and I only caught it because I stopped to verify a single claim with my own tools. Catching that, and turning it into a real fix, is the job.

TMS Builder

2026

A free operator TMS for small shippers, rebuilt clean-room and driven live on Warp's real freight · sole designer and build director

Press esc to close Close

Big & Bulky

BIG & BULKY · SHOPIFY WARP · 2026 SOLE BUILD SHIPPED

You bought
a couch.

And now you wait for someone to call you to schedule it. For anything big and heavy, checkout makes a delivery promise it can't keep, and the real scheduling happens later, by phone, after your money is already gone. I designed and built the Warp app that turns that moment into a real, dated delivery choice, inside Shopify.

Role

Product designer and builder, solo. I did the product design first, then wrote the app, directing AI to do most of the typing.

What's mine

The problem, the flows, the data model, the honesty rules in the UI, the billing redesign, the release calls, and the debugging. The AI wrote code under my direction.

Team

Warp's CRO and a teammate drove product direction in weekly reviews. The freight backend is the Warp team's. The app and every one of its commits are mine.

When & stack

March to July 2026. Remix, Polaris, three Shopify extensions, Prisma, Vercel.

01 · The human problem

Parcel shipping works.
Freight doesn't.

Buy a book and checkout knows exactly what happens next. Buy a sofa and it falls apart. You get a vague "three to five business days," you pay, and then a week later a person calls to arrange the actual delivery. The part that matters most for something heavy, when it shows up and whether you'll be home, is the part checkout waves its hands at.

Before

I bought a couch and now I wait for someone to call me.

After

I bought a couch and picked a real delivery option with confidence.

Shipping methodTypical store

Standard shippingEstimated 3 to 5 business days $0.00

White gloveCall to schedule after purchase$149.00

!No date. No window. The delivery gets arranged by phone, days after the money is gone.

Shipping methodWith Warp

Warp · 07/07 (Tomorrow)Delivered 1:30 to 8:30 PM · within 90 mi · $30 launch discount $106.22

Warp · 07/08 (Wed)$106.22

Warp · 07/09 (Thu)$106.22

Warp · 07/10 (Fri)$106.22

>You pick the day at checkout, before you pay. Each date is its own real freight rate.

// The four dated rates are the real render verified live on a Shopify Plus dev store, 2026-07-06. $106.22 is that dev store's rate for a test sofa, not a production figure.

02 · The reframe

Not my line, and I'll say so: a teammate said it in a review while I was polishing the shopper's checkout.

The first customer is the
merchant, not the shopper.

It reset the whole project. In an app that lives inside Shopify, the merchant is the one who decides to install it and keep it. If they can't get through setup, or don't see how it makes them money in the first minute, no shopper ever reaches the checkout I was fussing over. So I moved the design budget. The merchant's onboarding got the care. The shopper's checkout got calm defaults and nothing to think about.

The second thing I took from that research was mine: for a commerce app, onboarding is the whole experience. A merchant sets it up once and forgets it exists while orders flow through in the background. They never get a second chance to be impressed, so whatever friction sits in setup is the product.

So I cut things I had already designed

✕A two-hour delivery time-slot picker. Warp delivers in a 1:30 to 8:30 window, not a two-hour one. A picker for a promise we couldn't keep is a lie with a nice UI.

✕A White Glove upsell. Warp doesn't carry the couch inside your house, so I wouldn't sell that it does.

✕The "paste your Warp API key" step. I fought to auto-provision the account in the background instead. One trip to another website to copy a key is a knock-out for a non-technical merchant, not a small ask.

// Why the budget went to setup

Merchant installs

From the Shopify App Store, into their admin.

Merchant finishes setup

Seven steps. The one place friction can kill the whole thing.

Shopper sees Warp at checkout

Only now does the surface I was polishing ever appear.

If a merchant drops at step 2, zero shoppers ever reach step 3. The setup is the gate on everything downstream.

03 · What shipped

Three surfaces,
one honest promise.

The app lives in three places. A seven-step setup wizard in the Shopify admin. The rates a shopper sees at checkout. And the quiet operations after purchase, where it books the freight, holds the order until pickup is confirmed, and hands the shopper a tracking page.

Set up Warp big and bulkyAdmin · Polaris

6 of 7 steps completed86%

Account detailsDone

Warehouse addressDone

Which products?Done

Delivery rulesDone

Money flowDone

Payment methodDone

Rules of the Road, then go liveNext

Who pays for shipping?Step 5 · Money flow

Shopper

+$90.00

Your store

−$90.00

Warp

Pass-through. No markup, no spread. Whatever the shopper pays for shipping is exactly what Warp debits.

1Shopper pays shipping at checkout, on a $1,000 order.

2Warp debits the store the same amount. Margin lives in the product price.

// The wizard and the money-flow diagram are redrawn from the shipped Polaris admin. The live page composites the real screenshots.

The move I'm most proud of

I made the delivery date a property of the shipping rate itself, so Warp · 07/08 is just another rate Shopify already knows how to show. Scheduling works on every Shopify plan that way, with the fancier in-checkout card as a bonus on the ones that support it. It trades a slicker widget for far wider reach, which is the right trade for a wedge.

04 · Honesty as a design tool

Every label equals
what actually happens.

This app moves real money and makes real delivery promises, so a label that doesn't match reality is worse than something ugly. Four decisions that shipped, each of them defensible line by line in the code.

"Booking in progress," not "confirmed."

The shopper pays the store first; Warp books the freight a moment later. There is no honest "confirmed" at the instant checkout completes, so the shopper never sees one. They see the truth of where the order actually is.

Two separate vocabularies.

The shopper's status and the merchant's status never share words. A shopper who already paid never sees "payment pending." That is the merchant's thing to resolve, and it stays on the merchant's screen.

Pick a date, not a time window.

The first spec had a two-hour slot picker. Warp can't guarantee two hours, so the shipped rule is a date and an 8:30 PM outside bound. I won't design a precision the operation can't serve.

No markup, no spread.

The billing screen says it plainly and makes the merchant tick a box to acknowledge it. A grep of the code turns up no markup field, no spread, no margin, because none of them exist.

05 · The six-week bug

Rejected six times for a
bug that wasn't in the code.

Shopify rejected the app about six times over roughly six weeks, always on the same rule: the checkout extension "did not display." The code was correct, and an audit confirmed it. The real cause took actual debugging to find, and it was never where the rejection pointed.

May 22 REVIEW #1

Reviewed in under three hours. One bug.

I'd braced for a four to six week queue. Shopify picked it up in under three hours, which told me the submission package was complete. Then they came back with a single rejection: the checkout card rendered nothing. They had tested a Helsinki, euro checkout, where Warp correctly returns no rate, so of course nothing showed. Fast pickup, not a pass.

May to June ×6, POLICY 5.6.1

Same rejection, over and over.

"Checkout extensions must display properly." I kept re-reading the code that drew the card. It was fine. Chasing a rendering bug in correct code is a special kind of stuck.

The dig

I stopped trusting the rejection and read the logs.

Two real failures were sitting in the carrier-service logs the whole time, not guesses:

[carrier-service] hide reason="schema_validation_failed"

issue="rate.origin.province: invalid_type"

[carrier-service] hide reason="schema_validation_failed"

issue="rate.items.0.sku: invalid_type"

Shopify sends null for an empty optional field. My schema used .optional(), which accepts a missing field but rejects a null one. A single null failed the whole check and hid every Warp rate. One word: .optional() to .nullish(), plus a regression test that reproduces both logged failures.

The real cause

The card was Plus-only. The store wasn't Plus.

In-checkout extensions are a Shopify Plus feature. The demo store had drifted onto a lower plan, so the card could never render for a reviewer, whatever the code did. The earlier plan had written this off as unfixable and moved on. It wasn't unfixable. Shopify hands you a free Plus development store for exactly this, and an unsaved block previews in the editor but never renders on a live checkout, which was its own quiet trap.

July 6 LIVE VERIFY

The whole checkout, working, on a real Plus store.

I spun up the free Plus dev store, placed and saved the card on the checkout shipping step, and watched it work. The scheduler card rendered, and four dated Warp rates appeared: 07/07 through 07/10, each at $106.22, with the 1:30 to 8:30 window and the 90-mile note. That is the moment the six-week blocker died.

The fix came from climbing. From the symptom the reviewer named, "the extension doesn't display," up to the platform's actual rules: a Plus-only surface, an editor preview that isn't a live render, and one line of validation that rejected a legal null. None of it was in the code that drew the card, which is exactly why re-reading that code for six weeks got me nowhere.

06 · The bar

Built to a bar
you can check.

None of this rests on my word. It's in the repo, and every number here is something you could run yourself.

479

Commits, 100% mine
Mar to Jul 2026

1,493

Tests passing
0 failing · 126 files

Adversarial review
sweeps in June

90mi

Coverage cap
enforced in code

The race I was most afraid of

A cancelled order that still charges and still sends a truck.

In June I ran the codebase through nineteen adversarial review passes that grew the suite by more than five hundred tests and closed a whole class of race condition: a shopper cancelling at the exact moment the system was charging a card and dispatching a driver. That is the worst thing this app could do, so I closed it end to end, with a durable record of every cancel and guards that check it before any money moves.

Billing, redesigned to remove a risk

I pulled Stripe out of the app entirely.

The app is free and the freight is a strict pass-through on the merchant's own Warp account, so handling cards inside the app added a compliance surface for no benefit. The merchant now picks a Warp balance or a card already on file, and the app never touches card data. Warp has no reversal API, so instead of faking a refund I used a stable key that makes a retry safe to run, and I told the truth about it in the UI.

07 · Where it stands

Honest about what it is,
and what it isn't.

The app is built, hardened, submitted to Shopify review, and verified working live on a Plus development store. It is not publicly listed, so no real shopper has used it yet. I'm precise about that, because the precision is the whole point of my work.

What I can prove

The full checkout, verified live on a free Shopify Plus dev store on July 6: the scheduler card rendered and four dated Warp rates appeared.
The first submission was reviewed in under three hours against a four to six week queue, coming back with one bug. Fast pickup, not a pass, and I say it that way.
A maximum-effort submission audit found zero blockers across the money path, checkout, webhooks, and security.
479 commits, all mine, and a test suite sitting at 1,493 green.

What I won't claim

Installs, active merchants, or GMV. There are none, because it isn't publicly live. A zero dressed up as a result is still a lie.
Any conversion or order-value lift. "A better delivery promise sells more couches" is the bet this whole thing is built on, not a number I measured.
Adoption of any kind. One furniture store was lined up as the anchor partner. That is a prospect, not a metric.

What's real here is the judgment and the craft: taking a founder's whiteboard sketch to a rigorously built, compliance-aware, submitted product, solo, and holding the line on scope and honesty the whole way. That part is true whether or not anyone has installed it yet.

08 · What it taught me

Respect the
platform's truth.

Half the hard parts here weren't design or code. They were understanding what Shopify actually allows, its Plus-only surfaces, its carrier rules, its billing policy, and designing inside that instead of wishing it away. The six weeks I lost were six weeks of arguing with a platform rule instead of reading it.

The other lesson is one I keep relearning. Every time I refused a convenient fiction, a fake "confirmed," a two-hour window we couldn't hit, the checkout got clearer and easier to trust. This is the project where that idea had to hold up against real money and a real reviewer, and it held.

Big & Bulky · Shopify

2026

Real freight delivery, priced and scheduled inside Shopify checkout · built and submitted solo · verified on a Shopify Plus dev store

Press esc to close Close

Pataa^

A trustable address for the last mile.

7.5M+downloads

Pataa

ADDRESS APP PATAA · 2022 REDESIGN UI/UX DESIGNER ANDROID + iOS

Pataa^

Pataa means address in Hindi. It is a live app that gives any place in India a short code you can share, one that lands on a single doorway instead of a neighborhood. It has reached more than 7.5 million downloads. I joined the team that redesigned it in 2022. To be exact about it: the app reached that scale, I did not drive it there. What I worked on was the research and the core flows people use inside it.

Pataa app screen — finding a place by scanning, shown against a real photographed entrance

Pataa app screen — the in-product satisfaction check used to gather honest feedback during testing

What I did

The user research and its synthesis. The create-and-share flows. The voice-direction experience.

Role

One UI/UX designer on the redesign team. I did not create Pataa or invent its short-code system.

Context

A consumer address app for India, live on both stores. My foundations era, before the AI-native work.

Team

A cross-functional redesign team with several designers and engineers. The ideation board still shows all our frames.

01 · The problem

An address that points at
an area, not a place.

In most of India a written address does not resolve to a point on a map. It resolves to a region, sometimes a very large one. You can hand someone a full, correct address and they still cannot find your door, so the address becomes the start of the search instead of the end of it.

The person waiting

Anyone who has waited on a delivery and still gotten the call. I am near your area, where exactly are you? So you narrate landmarks down the phone, again.

The person delivering

The agent making that call, dozens of times a shift, on a two-wheeler, in the rain, losing minutes to every vague address before the parcel even moves.

On the numbers you will not see here

Teams at MIT and Delhivery have measured how much this addressing gap costs the country, and we read that work closely. It is the reason Pataa exists. It is also their research, not our result, so I am keeping their figures off my page rather than letting them read like something I achieved.

02 · The decision that mattered

We changed
our own brief.

The brief we were handed was reasonable: make the address shorter, something like a PIN. The research kept telling us that would not be enough. A shorter code still leaves the last twenty meters unsolved, and the people who navigate for a living told us they go by landmarks and cues, not coordinates. So we rewrote the problem in our own words.

The brief we were given

Make the address shorter.

A shorter string is easier to type and share. It still drops you in the right neighborhood and leaves you calling for the door.

reframed

The problem we committed to

Make the address trustable.

Something a person and a delivery agent can both read at a glance and act on without a phone call. That reframe is why we invested in voice and human directions, not just a shorter code.

Refusing the brief you were handed, and re-deriving a better one from evidence, is the part of this project I would defend first in any room.

03 · Who it is for

Three people. We designed
for the hardest one first.

We built three personas from the interviews, spanning the range of who reaches for an app like this. Then we made a deliberate choice: hold the design to the edge of that range, not the middle.

Rajesh Kumar

28 · DELIVERY DRIVER · DELHI

Fifty-plus stops a day on a two-wheeler, outdoors, under pressure. Fluent with Maps and WhatsApp.

Find me the exact doorway without stopping to call the customer.

Anjali Verma

31 · MARKETING MANAGER · BANGALORE

Lives in navigation apps between meetings, often multitasking in a cab. Comfortable with any tool.

Get me there accurately, and let me save and reuse the places I go.

Designed for first

Mohan Lal

65 · RETIRED TEACHER · AGARTALA

First smartphone, gifted by his son. Weak signal, often on foot, reluctant to keep asking for help.

Give me simple, forgiving guidance, with voice in my own language.

Mohan is the reason the product leans on voice, on English and Hindi, on large tap targets, and on working when the signal drops. Designing for the person who struggles most pulls the whole product toward clarity, and that clarity carries the confident users along with it.

04 · How we worked

Research first, then a straight
line to something testable.

The process was ordinary in the best way. We did the homework, synthesized it honestly, prioritized under a real constraint, and put it in front of users before we committed.

Interviewsprimary + secondary

Six one-on-one interviews with delivery agents, logistics staff, and everyday travellers, paired with close secondary reading on how Indian addressing actually works.

Synthesisaffinity + card sort

Affinity mapping in FigJam, clustering raw notes into six themes, then card sorting to find where the real trends sat.

PriorityP0 to P3

Every problem slotted into a priority map, so a small team knew exactly what shipped first and what could wait.

IdeationCrazy 8s

Crazy 8s across the design team, including a round of deliberately terrible ideas to break the first-obvious-answer reflex. We picked directions by voting together on feasibility, desirability, and viability.

A named trade-offskipped lo-fi

We skipped a separate low-fidelity phase on purpose. The sketches already carried our layout thinking, so a formal lo-fi round would have been ceremony. We said that out loud and covered its risk with testing.

Testingtwo rounds

A cheap internal pass with the team and stakeholders first, to catch the obvious. Then moderated sessions with six users matched to our personas, with interviews afterward.

P0ship first

Address-complexity resolutionAccurate endpoint navigation

P1next

Seamless integrationUser-friendly interfacePersonalization

P2later

Multilingual supportDynamic route updatesEconomic insights

P3horizon

Community-driven address updatesScalable solutions

In one session a driver told us voice-guided directions would be a game-changer for his job. Another user said the geotagging felt precise and helpful. We heard the honest misses too, like a route preview that felt cluttered, and those went straight back into the work.

// reported feedback from moderated usability testing

05 · The solution

A short code, and the human
directions attached to it.

The core is the ShortCode. On the surface it reads like a personal handle, something like ^TANUJ12345. Underneath it is a precise geocode: a single 3 by 3 meter block you pin at your own entrance. Creating one is staged, so a first-time user is never shown the whole thing at once.

Creating a Pataa, one step at a time.

A new user is never staring at a blank field. The code screen suggests options and shows the rule in plain terms. Then details, then a single tap on the map to place the block.

Pick your code. Seven to eleven characters, with suggestions ready so the field is never empty.

Add your details. Home or office, building, area, the human context around the point.

Pin the block. Drop one marker on the exact 3 by 3 meter block at your entrance.

Pataa app screen — creating your unique address code, with ready suggestions and the character rule in plain terms

Create your code

Pataa app screen — pinning the exact 3 by 3 meter block on the map at your entrance

Pin the block

Pataa app screen — a recorded voice direction to a landmark, played back on a clean waveform, in English or Hindi

Voice direction · EN / हिन्दी

The part I cared about most.

A precise geocode gets you to the block. A voice note gets you to the door. So you can record one, tag a landmark, and add a photo of the entrance, and it plays back on a clean waveform. You can do it in English or Hindi, or type it and have it read aloud.

The direction gets captured once and travels with the code to whoever you share it with. The call-me-when-you-are-close conversation happens zero times instead of every time.

06 · The state I was strictest about

A live location has to look
as serious as it is.

Sharing where you are in real time is not a casual feature. It has real stakes, so the state that represents it had to be loud, unmistakable, and one tap from off.

Pataa app — the live-location state in the product's own red, naming who you are sharing with and keeping Stop within reach

Live location · the app's red

When a live share is on, the app says so in the app's own red, names exactly who you are sharing with, counts the time down, and keeps a Stop button in reach. Red here is not decoration. It is the color the product reserves for the two states with real stakes, recording and live location.

A screen that is quiet or vague about whether it is broadcasting your location is a worse failure than an ugly one. This was 2022, and it is the first time I remember treating honesty as something you design into a state, rather than a disclaimer you add at the end.

07 · Where it stands

Exact about what is
mine, and what is not.

Pataa is a real, live app on Android and iOS, published by Pataa Navigations. I worked on the 2022 redesign of the journeys inside it. Here is the line, drawn clearly.

7.5M+

Downloads · the one real number

The app I helped redesign has reached more than 7.5 million downloads, across the Play Store and App Store. It is the product's scale, and I designed inside it. It is not a number I drove, and it is the only number on this page.

What I can prove

The redesign scope: the research and its synthesis, the create-and-share flows, and the voice-direction experience.
A full human-centered process, documented end to end, from interviews through two rounds of usability testing.
That the app I helped redesign is live on both stores and has reached over 7.5 million downloads.

What I will not claim

That I created Pataa or invented its short-code system. It was a team redesign, and engineers built the geocoding behind it.
Any before-and-after number isolated to my slice. No such measurement exists, so the honest value is a dash, not a percentage.
The usability score and the churn, cart, and satisfaction figures an older version of this study once showed. They were never real, and they are gone.

—

Impact isolated to my redesignNot measured. There is no clean before-and-after attributable to my slice of the work, so I am showing a dash where a tempting fake number used to sit.

So the impact I stand on is the process and the product, not a dashboard. That is the honest version, and it is the one I would rather defend to your face than a chart I cannot back up.

08 · Looking back

Where a lot
of this started.

Pataa is my foundations era, and two things from it still run through my work.

The first is watching real research overrule a reasonable brief and leave the product better for it. Make it shorter would have shipped something worse than make it trustable, and only the evidence told us the difference. I have trusted that order of operations ever since.

The second is smaller, and it stuck harder. A live-location screen that was vague about whether it was broadcasting taught me that honesty is a material you design with, the same way you work with type or spacing. That is the center of how I work now, years and very different products later, and it is still the first thing I check in my own screens.

Pataa

2022

The 2022 ground-up redesign of a live Indian address app that reached 7.5M+ downloads · UI/UX designer, research and core flows

Press esc to close Close

Experience Snapshot

Happy Clients

Years of Experience

Design Projects

100

passion

Working at the intersection of aesthetics and usability.

With years of experience in web & app design, I live & breathe good design & value the details that matter. I believe that every element has the potential to make a significant impact, whether it's crafting wireframes, designing visual systems, or prototyping interactions. I enjoy working with diverse teams to bring ideas to life. Let's work together to create something extraordinary with the power of collaboration.

Tools of the trade

Mastering design software is not just about using them as tools to bring ideas to life. It's about leveraging them to their fullest potential to create "WOW" designs. Here are some of the software I have mastered.

Design Process

We start with people

First things first, we understand our user's needs, motivations, and goals.

We discover & define the problems

Then we dive deep into discovering and defining their problem by conducting research and gathering insights about them.

We sketch & whiteboard our ideas

Then we come to the exciting part - we start sketching and whiteboarding our ideas, getting them out of our heads and onto paper.

We wireframe our selected solutions

From sketching, we move on to wireframing out selected solutions, building the foundation of the user experience.

We create hi-fi prototypes & test those solutions

Finally, we create hi-fi prototypes and test those solutions with real users, iterating until we've created a truly exceptional product.

I help brands create Digital Experiences

Design Case Studies

Tho8

Tho8.

What I did

Team

Context

Live

The short version.

Ideas don't die at capture.They die on the way back.

Capture is fast; setup kills adoption.

Linking breaks when you can't remember titles.

AI suggestions without proof get ignored.

Four loops. One surface.

Capture

Connect

Retrieve

Resurface

Capture

Connect

Retrieve

Resurface

Two semesters,five phases.

Literature Review

Benchmarking

User Interviews

Synthesis

Design + Test

What today's toolsget right, and wrong.

Six people.Six setups. One story.

Doctoral student

Master's student

Master's student

Product Manager

Strategy Consultant

Senior UX Researcher

The six patternsthat shaped every decision.

Capture must be instant.

Linking breaks on title recall.

Retrieval has a 20–30s budget.

Nudges only in context.

Trust comes from block-level proof.

Cross-tool reality is non-negotiable.

The Trust Ladder.

Rules we didn't break.

Zero-friction capture

Link from fuzzy cues

Proof over polish

30-second retrieval

Focused local graph

Progressive disclosure

Eight surfaces,one coherent workspace.

Main Workspace

Second Brain · Holistic Graph

Quick Capture · Cmd+N

Quick Find & Ask · Cmd+K

Daily Sweep · Inbox triage

Link-by-idea Palette

Inline Suggestion

"Why this suggestion?" Modal

Honest about whatit is, and isn't.

What I can prove

What I will not claim

A quiet interfacefor loud thinking.

Warm orange on cool neutrals.

Manrope · single family.

What building ittaught me.

Lumen

Lumen.

What I did

Team

Context

Stack

The short version.

Three failure modesthe system kept landing in.

Primitives forked silently.

Tokens changed; prose didn't.

LLM-first was an afterthought.

I stopped choosingbetween them.

Apple, Ive, Rams.

Ideas don't die at capture.
They die on the way back.

Two semesters,
five phases.

What today's tools
get right, and wrong.

Six people.
Six setups. One story.

The six patterns
that shaped every decision.

Eight surfaces,
one coherent workspace.

Honest about what
it is, and isn't.

A quiet interface
for loud thinking.

What building it
taught me.

Three failure modes
the system kept landing in.

I stopped choosing
between them.

One mood. One mark.
One face.

Same language.
Different density.

LLM-first,
human-second.

R1 to R16.
Vigilance, retired.

Three primitives
that carry the brand.

Honest about what
it is, and isn't.

What building it
taught me.

The page told the user
less than it knew.

The page computes
its own truth.

Three rules,
each from a caught lie.

The alerts control,
in three tries.

Shipped twice,
guaranteed identical.

Honest about what
it is, and isn't.

The smallest surface
is the honest test.

An exception
just landed.

The defect was
architectural, not visual.