← All work{{ clock }}
About Thanvi Nimmala
I’m a product designer based in the NYC metropolitan area. I like making design feel fun and useful, and I build the thing rather than a picture of it.
I graduated in 2026 with a B.A. in Information Technology & Informatics, and a minor in Digital Communication, Information & Media.
Since then I have been Product Design Lead on New Craft Society at CoCreate, where I took a capture tool from nothing to a public beta. I work end to end — research, flows, interface, design systems — and prototype in React and SwiftUI, so a decision can be tried instead of argued about.
I’m currently looking for full-time design work.
Outside of design I am usually painting, reading, or chasing a good playlist.
← All work{{ clock }}
A tool that makes your design process visible.
New Craft Society is a macOS capture tool and a web product that turns the work as it happens into a story you can hand to someone. I led design 0→1 at CoCreate, and owned the capture tool and the landing page end to end.
Overview
How might we capture work in progress with so little friction that the case study almost writes itself?
Designers lose everything that led to a finished piece. The work is scattered across Figma, chat threads and a hundred tabs, and by the time a case study is due you are doing archaeology on your own project.
CoCreate is a design platform for early-career designers. New Craft Society is its newest vertical: a capture tool that stores the work as it happens, and a web product that reads it back as a process you can show someone.
The product end to end, from its opening sequence through to a project open inside it.
Solutions
Two halves of one product, and the one I owned end to end.
Capture had to cost nothing at the moment it happens, and the return trip had to be worth scrolling. The capture tool was mine end to end; the web product that reads it back was team-led.
CAPTURE — MINE, END TO END
⌘⇧2 stores the capture before anything appears on screen. What appears afterwards is a receipt, not a gate: it states what happened and asks for nothing. The AI works after the fact, and never blocks the moment.
The shipped capture tool, uncut — the hotkey, the receipt, and the summary arriving later.
THE TIMELINE — TEAM-LED
Everything captured comes back as one continuous stream per project, read chronologically, so you can scroll back through every iteration without having decided in advance which versions were worth keeping.
Research
Designers were already using tools that were not built for this.
Thirty-plus designers, across skill levels. The sharpest answer came from Hana, an interaction design student applying for product internships. I asked how she would feel about a tool that let her show work in progress to other people.
“I already do that in Medium. I write blogs and upload screenshots to document my process. I don’t think I’ll need it.”
Hana — junior in interaction design, ArtCenter.
THE INSIGHT
Designers are missing a lightweight work-in-progress layer between raw files and a polished portfolio.
Her portfolio felt too final, so she blogged instead. That is a workaround, not a preference, and it told us what to build: a tool, not a social network. Something faster than writing a doc, that shows progress over time, and stays useful even if nobody else ever sees it.
SHARED WITH ONE TEAMMATE
Process
I designed something beautiful, then cut it for being in the way.
The capture card is the surface someone sees fifty times a day, so it got the most craft and the most ruthless editing. I built four versions rough and fast: solid enough to test, cheap enough to throw away. Each answered the same question: how little can the tool ask for at the moment of capture?
01
The full card
Thumbnail, filed process, an optional note, and four actions: save, reassign, new project, dismiss. Every decision available in the moment.
Why it lost. Four words in the dogfood review ended it: too intrusive, too complex. It had grown into a form parked in the middle of someone’s work, waiting for input.
02
Note first
“Add a thought”: the capture behind a text field, with keyboard shortcuts for filing and a confidence badge for where it would go.
Why it lost. A blank field is still a demand. It asked for words at the one moment you have none, and the shortcuts only helped people who had already learned them.
03
The pill
A small persistent counter that tallied captures as they happened, with nothing to fill in.
Why it lost. It moved the question from “what do I write” to “is it on” — a permanent presence on screen that had to be looked at to be trusted.
04
The receipt
The capture is stored first. A receipt appears afterwards, states what happened, and asks for nothing. Organising moves to a moment when the person has attention to spare.
Why it shipped. It was the only version that cost nothing at the moment of capture, and the only one people kept using after the session ended.
The versions on paper.
Version 01, annotated — every option in the moment.
MINE, END TO END
Landing page
The page had to explain capture to someone who had never seen it.
People download the tool and are thrown straight into their own work, so the page carries all of the explaining. Mine end to end: structure, copy, interface and build.
The page as it shipped, top to bottom.
SHOW BEFORE TELL
The product is hard to describe and instant to understand, so the page opens by demonstrating a capture rather than explaining one. Five sections, each with one job.
01
The hero
Two ways in: download the capture tool, or open the web app.
02
The demo
Show, don’t tell. A simulation of what the tool feels like to use, before a single line of explanation.
03
The mechanic
How to use the capture tool, in the fewest instructions possible.
04
Capture types
Every kind of capture the tool supports, proactive and ambient.
05
The payoff
What a collected process turns out to be good for: the use cases, last, once you already want it.
02 — the demo.
03 — the mechanic.
04 — capture types.
05 — the payoff.
MINE, END TO END
Engineering
Prototyping in code turned sprints into days.
Before, an alternative meant a Figma clickthrough, wired screen by screen, evaluated a sprint at a time. With AI-assisted code I built each one as a working prototype in React or SwiftUI instead, so the team could use the thing rather than click through a picture of it.
The team evaluated concepts in days rather than sprints, before any engineering time was committed. The design decisions stayed the slow part, which is the right thing to be slow about.
The alternatives running as working prototypes.
Validation
Research took our most ambitious feature off the roadmap.
Auto capture — the AI deciding what to keep, with no trigger from you — started as a P0, and was the most ambitious thing we had. The internal assumption was clean: remove documentation friction entirely and it becomes the product’s killer advantage.
Across thirty-plus sessions, four questions came back that we could not answer: what would it capture, when would it start, who stays in control, and is it actually useful? Auto capture came off P0 and went back to exploration. Trust and onboarding took its place.
30+
Test sessions run and documented.
100+
Beta signups before launch.
30→50%
Share was used by 30% of users in V1. The redesign is measured against 50%.
THE METRIC I ARGUED FOR
How many times has someone scrolled to the bottom — not just how long they stayed on the page.
SHARED WITH ONE TEAMMATE
Reflection
What I would do differently.
1
Put the rough versions in front of people before the polish.
The working prototypes are what made evaluation cheap, and they came after the craft. I spent weeks refining a card that four words in a review removed. Next time the rough ones go out first and the craft goes into whichever survives.
2
Treat the most ambitious feature as a research question, not a roadmap item.
Auto capture sat at P0 on an internal assumption for most of the project. The four questions that took it off could have been asked in week one.
3
The half still being tested is the return trip.
The honest version of this page is that the capture problem is solved and the memory problem is not, yet: making a timeline you would actually scroll to the bottom of, and turning that scroll into the case study it promised to write for you.
Up next
The rest of the work.
← All work{{ clock }}
Food delivery, pointed at food insecurity.
EcoBites borrows the most familiar pattern in modern life — the food-delivery app — and points it at New Jersey’s food banks, pantries and kitchens. A website for people who need food, and one iOS app with two front doors — one for them, one for the volunteers who drive it there.
Overview
How do you get good food to people without making them prove they deserve it?
Food insecurity is rarely a lack of food. It is a lack of access. Pantries, soup kitchens and food banks already hold what people need, but the network around them is fragmented, hard to navigate, and easy to fall through.
So the whole product had to be ordinary: open it on whatever device you have, see what is available nearby right now, reserve it — free — and choose delivery or pickup. No payment, no paperwork, no queue.
Reserving a box — the whole run, recorded from the prototype.
Where the software stops. The mark had to hold up printed on a box and carried down a street, not just at 34px in a nav bar.
Solutions
Three ways in, one live order.
The instant a request is placed it surfaces as an open route in every nearby driver’s app, and every step the driver takes flows straight back to the person waiting at home.
THE CLIENT FLOW
Browse by category, open a listing, reserve it, then choose delivery or pickup. Five screens, plain language, and reassurance on every one of them.
Filtering by diet and fulfillment — narrowed past what exists, then widened back.
THE CLIENT PORTAL
The website assumes a desktop and a quiet half hour, and the people this is for often have neither. So the volunteers’ app grew a second front door: the same shelf, the same reservation and the same tracker, on the phone they already carry.
Opening the same app as a client — choose a side, sign in, reserve a box, follow it.
THE HANDOFF
One order, two live views. The cargo check is the only step that cannot be skipped. It is what makes the handoff accountable.
One order across both surfaces — placed on the left, accepted on the right.
THE DRIVER FLOW
Claim a route, verify every box against the order before it leaves the pantry, drive it to the door. Every status the driver sets lands back on the client’s tracker in real time.
The run, in motion.
THE DIRECTORY
Reserving is one way through this. The other is to walk in, and plenty of people will always prefer that — or are looking on behalf of someone who would. So the service publishes itself as a plain list too: every food bank, pantry, mobile market and kitchen within five miles, with the hours, a phone number, which bus stops outside, and what each one will ask you for at the door.
That last line is the argument in miniature. At all eight of them it reads nothing. It is the one place in the product where dignity stops being a tone of voice and becomes a fact you can go and check.
The list on the website…
…and in the hand, standing outside, which is when it is actually needed.
Research
1.2 million New Jerseyans, and a network they cannot see.
We worked with the Community Food Bank of New Jersey as our stakeholder, and grounded the market research in existing relief programs, among them the White House Conference on Hunger, Nutrition and Health, and Project DASH.
The statewide figure is Feeding America’s Map the Meal Gap estimate for New Jersey in 2024: 13% of the state, up from 7.4% in 2020.
1.2M
New Jerseyans facing food insecurity.
4
Actors in a single order.
3
Ways into one live order.
THE INSIGHT
Dignity is a design requirement, not a tone of voice.
Every word, every wait state, every empty screen had to reassure rather than gatekeep. That is what decided the copy, the tap targets and the contrast long before it decided the visuals.
Process
Four moves, from a messy problem to a calm flow.
Map the real network: banks, pantries, kitchens, and the routes food already travels between them. Reframe delivery as a two-sided service: recipients request, volunteers and partners fulfil. Prioritise first-run, browse-by-need and order-tracking so a stressed first-time user can move without friction. Then build a warm, legible component set around them.
The same order traced across all four actors, from account creation and eligibility through pickup, delivery and feedback. This is the diagram that showed us the second app was unavoidable.
Trade-offs
It started as a waitlist. It became a delivery network.
The first version let people register on waitlists at participating pantries and coordinated surplus food out to them. The waitlist made the provider the unit of the product: you joined a queue at a place.
The reservation makes the meal the unit, and that is what forced the second app: once someone can claim a specific bag of food, someone has to move it.
The front door was the other argument. Verifying need before letting anyone in is the obvious way to protect a scarce supply, and it is the first thing a stakeholder asks for. But federal food assistance settled this years ago: TEFAP takes people at their word, and some states bar agencies from asking for proof at all — because a documentation check filters hardest against whoever is carrying the least paperwork. So the limit moved to where the scarcity actually is. What runs out is not food. It is a volunteer free to drive.
01
How you get food
Register on a waitlist at a participating provider.
Where it landed. Reserve what is on the shelf right now.
02
When you find out
When your turn comes up.
Where it landed. Immediately, with live tracking.
03
Who moves it
Coordinated distribution.
Where it landed. A nearby volunteer claims the route.
04
Who gets in
An application, with eligibility verified over three to five days.
Where it landed. One declaration, taken at its word — and the cap put on deliveries rather than on food.
The prototype
Two surfaces on one order, with no backend behind them.
Twenty-five screens — ten on the client website, seven in the driver app and eight more in the client portal that shares it — built as a React shell that every surface drives from a single store. A delivery placed on the website appears as an open route on the phone, and the driver’s progress moves the client’s tracking timeline. That handoff is the whole argument, so the default view shows both at once.
The client’s tracker…
…the screen that moves it…
…and the same order, in her pocket.
BUILT TO BE DRIVEN, NOT CLICKED THROUGH
01
A scene rail, grouped by surface
Every screen worth putting in a deck is one key away, and picking a scene fabricates exactly as much order history as that screen needs: an empty pantry, a route mid-run, a delivered box.
02
Design controls both surfaces read
Primary, accent, display face, corner radius and photography on or off. Each writes a CSS custom property that the website and the phone app both read, so retheming the system is one panel, not two files.
03
Reels that drive the real interface
A synthetic pointer clicks real targets in the running app rather than replaying a recording, so what you watch is the product working. Nine of them, including the one that traces a single order across both surfaces.
04
A capture mode
Record mode hides the rail and the panel; a query parameter renders any single surface alone at its natural size, with the order history already built. Every still and reel on this page came out of it.
Reflection
What I would do differently.
1
Pilot it with one county before designing for a state.
The model is sound on paper and untested in a pantry. A single county’s network would tell us in a fortnight what a semester of desk research could not.
2
Design the volunteer-side tooling that makes the model actually run.
We designed for the driver in the car. We did not design for the coordinator deciding which routes exist. That is the role the whole thing depends on.
3
Test the words with people who have used a pantry.
Dignity was our principle, but we were the ones deciding which sentences cleared it.
3
Resource types unified into one request flow.
1 tap
From opening the site to the nearest open pantry.
WCAG AA
Large targets, plain language, high contrast.
Up next
The rest of the work.
← All play{{ clock }}
An exhibition that could only exist on the web.
Cyberfem Networks is an online exhibition of nine net-art works, from 1993 to now, that use the internet itself as their medium. I chose the works, wrote the curatorial text, and designed and hand-coded the site as a network you explore, in the visual language of the era the work came from.
Overview
What happens when the network is the material, not the channel?
Most work about the internet is made somewhere else and put online afterwards. The nine pieces here cannot be moved: take away the jury’s submission system, the inbox, the frameset, the browser, and there is nothing left. That is the argument the exhibition makes, and the reason it had to be a website rather than a paper.
The exhibition as it opens: nine works wired to three threads, under a browser frame with a location bar and a scrolling ticker.
The works
Nine works, one medium, thirty years.
VNS MATRIX — ALL NEW GEN, 1993 TO 1994
A cyberfeminist game from the collective credited with helping coin the word, built around a non-binary protagonist sabotaging a patriarchal system. It is the period evidence that this argument is older than the platforms making it now.
MARTINE NEDDAM — MOUCHETTE, 1996 TO NOW
A website run by a thirteen-year-old girl who is not real, and has not aged in thirty years. It asks the visitor questions, invites replies, and keeps them. Thirty years of other people’s answers are part of the work now.
OLIA LIALINA — MY BOYFRIEND CAME BACK FROM THE WAR, 1996
A hypertext conversation between a couple after a war. Every click splits the browser into smaller frames, so the story fractures as you read it. The HTML frameset becomes the emotional form of the piece.
CORNELIA SOLLFRANK — FEMALE EXTENSION, 1997
Sollfrank invented hundreds of fictitious female artists and submitted their work to a museum’s first net-art competition. Two thirds of the entrants were women; all three prizes went to men. The piece reads the bias straight out of the institution that ran it.
OLD BOYS NETWORK — FIRST CYBERFEMINIST INTERNATIONAL, 1997
The first international cyberfeminist alliance, co-founded by Sollfrank. At documenta X it refused to define cyberfeminism and wrote a hundred anti-theses about what it is not instead.
SHU LEA CHEANG — BRANDON, 1998 TO 1999
The Guggenheim’s first web commission, built around the life and murder of Brandon Teena, a trans man in Nebraska. A multi-author space about gender, the body, surveillance and punishment, still running because the museum migrated its code.
SUBROSA — 1998 TO NOW
A collective working where bodies meet technology and labor: reproductive and genetic technologies, biotech, the information economy. Cyberfeminism as an organised practice, not a style.
LEGACY RUSSELL — GLITCH FEMINISM, 2012 TO 2020
An essay that became a manifesto. The glitch as refusal: a body that will not compute inside the gender binary, and the internet as a place to rehearse and build identity rather than only display it.
MOREHSHIN ALLAHYARI — SHE WHO SEES THE UNKNOWN, 2016 TO 2021
3D-modelled and printed re-figurings of female and queer jinn from Middle Eastern myth, alongside her idea of “digital colonialism” — who gets to scan, own and redistribute a culture’s heritage.
Opening a work opens a draggable window: a screenshot, the wall text, its threads, and a link out to the original.
Curation
The selection is the argument.
Nine works, chosen so that no two make the point the same way: a game, a persona, a hypertext, an intervention in a jury, an alliance, a museum commission, a collective, a manifesto, a set of 3D-printed figures. What they share is dependence — each needs a live network to be itself.
Instead of a chronology, I organised them around three threads that run through the whole field: Identity, Resistance, and Networked Bodies. Most works sit on two, so the connections between them carry as much of the argument as the works do. Sollfrank’s intervention and the alliance she co-founded are wired to each other directly.
Following the Identity thread: its works light up, everything off it dims.
Ending on Russell and Allahyari is deliberate. It shows the argument is not a 1990s period piece: the same questions moved into social media and 3D-scanned heritage, and they are still open. Two works deal with violence and self-harm, so they carry a content note before you leave for them, and every work links out to the original, still running at its own address, because sending people to the real thing is the point.
The build
The interface had to belong to the work, not to 2025.
A clean contemporary gallery layout would have flattened these pieces into content. So the site is written in the register of the work it shows: a browser frame with a location bar and a status bar, pixel and monospace type, magenta, green and cyan at full saturation on a near-black dotted grid. The curatorial statement is a README.TXT on the desktop.
The structure is the idea. Works are nodes, threads are hubs, and the wires between them are drawn live, so the exhibition’s argument is something you navigate rather than read about. Hovering a work traces its wires and the status bar reports that it is “connecting” to the work’s real address.
It sounds like the period, too. You enter through a dial-up gateway: pressing ENTER plays a modem handshake while a terminal prints the connection log, then the page dissolves into the network. Inside, every work has its own note, so running a cursor across the nodes or down the index plays a scale. Selecting a thread plays an arpeggio of the works on it, and windows open and close with system blips. All of it is synthesized live with the Web Audio API, with no audio files to load.
The way in. Browsers will not play sound until a visitor acts, so the ENTER click is both the threshold of the exhibition and the gesture that turns the sound on.
Sound is on by default but never forced: “enter without sound” sits under the button, the choice is remembered, and the gateway only appears once per visit.
An experimental interface cannot be the only way in. A second view lists the same nine works as an early-web directory listing, in date order and readable at a glance, and the threads filter it the same way they filter the network.
The Index view: the exhibition as a directory listing.
On a phone the network folds into a grid and windows become full-screen sheets. It is hand-written HTML, CSS and JavaScript with no framework and no build step, and adding a work is one entry in a data file. The exhibition should outlive its toolchain, the way the works it shows have outlived theirs.
On a phone: the works as a grid, and a work open as a sheet.
Reflection
What I would do differently.
1
Give the network a first path.
A network has no front door. A suggested route — start with one thread, end on the contemporary work — would help first-time visitors who do not know where to click.
2
Screenshots are not the work.
Each window shows a still of something that moves and answers back. Short recordings of each piece in use — answering Mouchette, clicking through Lialina’s frames — would show what the caption can only describe.
3
Let each work pull the page toward its own period.
The early-web treatment is right in principle, but it holds one house style across thirty years. The strongest version would let a 1993 game and a 2020 manifesto each change the room around them.
Up next
The rest of the work.
← All work{{ clock }}
OverviewThe calm pathReading the riskResearchIdentityThe score you can moveEngineeringThe prototypeValidationReflectionUp next
← ALL WORKShowing people why a payment was stopped, instead of asking them to trust that it was.
When a bank holds a payment you learn two things: that it was held, and that you should call someone. What tripped it stays inside the bank. Keystone is a payments app built around a fraud model that explains its own decisions. It started as a Human-Computer Interaction final with a team, and I rebuilt it on my own two years later as a working front-end shell, which is where most of what follows actually got tested.
Overview
Transparency, trust and control, in a flow where the model moves faster than the user.
The original concept had the right pieces: a security score, live alerts, biometric approval, and a model reading every transaction. It spent all of them on reassurance. Badges telling you that you were safe, which is the same black box in better packaging.
The questions I cared about were hard to answer in static frames. How much security presence is too much? Will anyone read five risk factors, or do they just want the verdict? So I rebuilt the thing as something you could use.
A payment sent, screened and approved. The prototype drives itself.
Open the working prototype ↗The calm path
Designing for the ninety-nine payments that are fine.
Almost every time, the model has nothing to say. Screening should cost the user a beat of reassurance and no more, so the send flow runs five steps on one thumb with no interruption. Four checks complete before the money moves and you never wait on them.
Screening is the one moment the product acts on a payment instead of carrying it, so it is the one screen that changes register. The interface drains to near-black and a ticked dial turns while the payment is read. Every other screen in the app has colour in it. This one has almost none.
The instrument, turning. Three of four checks set.
Reading the risk
Leading with the stop, then the evidence.
A held payment usually arrives as a wall of text. But nobody opens that screen wanting to know why. They want to know how bad it is, and what they are supposed to do about it. So the review opens on the stop itself: the amount, the merchant, and the fact that nothing has left the account yet. The evidence follows, five weighted signals in order of strength.
Unknown merchant 94, unusual amount 86, distant origin 62, off-pattern timing 34, device match 12.
THE DECISION
A hold narrows the choice without taking it. Both outcomes sit in a footer pinned to the bottom of the sheet, so the decision stays within thumb reach however long the signal list runs. “Yes, this was me” releases the payment and folds the merchant into what the model trusts. “Not me” freezes the card and states plainly that you carry no liability while it is reviewed.
Research
Twenty people, five questions, asked out loud on campus.
The original research was deliberately low-tech. We stopped twenty people across the Rutgers campuses, asked each of them the same five questions about paying online, and typed the answers into a shared sheet. We asked out loud instead of sending a form, because people qualify themselves when they speak in a way they will not when they type, and the qualifications turned out to be the useful part.
We grouped the answers on an affinity diagram under needs, wants and concerns. The concerns column set the brief. What people described was less a fear of fraud than a fear of being told nothing while it was sorted out.
THE TENSION IT LEFT US WITH
Security you cannot see does no reassuring. Security you always see becomes a checkpoint. I did not want to settle that by argument, so in the rebuild I made visibility a variable with three settings and had every screen answer to it.
01
Quiet
Present without announcing itself. No score, no trust block.
02
Default
What ships: the mark in the header, the stack in the feed.
03
Foregrounded
Something needs attention, so narration takes the top of the screen.
Default is what the build ships with. Enough that the model is visibly working, quiet enough that it is not asking for credit. Foregrounded earns its place in the minutes after a hold, when narration is genuinely wanted, and nowhere else.
Identity
The first build looked generated, so I threw the surface away.
Version one was obsidian with an iris-to-magenta gradient, glows on everything, and a radar chart in the middle of the risk review. Every one of those is a default, the thing you reach for before you have decided what the product is. It read as competent and anonymous, which for a security product is the worst tone available.
A keystone is the wedge at the apex of an arch that locks the other stones in place. Pull it and the structure comes down, which is close enough to how layered protections work that the identity could be literal. Six stones, one for each protection you have armed, with the keystone at the top. Five of six set means the keystone is still out, so nothing is locked. The score is not illustrated by the stack. It is the stack.
The mark assembles the way the object does, bottom stone first, then it holds.
THE SAME SYSTEM, ACROSS THE FLOW
Six screens in the order you meet them: the promise, the dashboard, the ledger, the screening, the held payment, the score. One ground, one rock, one typeface, and an instrument that only shows up where the product is doing something to a payment.
The score you can move
Making the number answer to something the user controls.
Trust scores in finance apps are handed down, with no visible relationship to anything you can change. Here the score is the sum of six protection weights. Switch one off and it recalculates in front of you, the stack loses a stone, and the crown stone starts to drift because the structure is no longer steady.
96 down to 64 as protections come off, then back up.
ONE SCHEME, NOT ONE ACCENT
The palette is a single object. A scheme owns the ground, the hero gradient, the screening instrument, the rock the stones are cut from, and every surface and semantic colour when it runs dark. Swapping only the accent, which is what the first version let you do, produces the same app with an odd button in it.
Engineering
Two problems I only found because the prototype was real enough to use.
The first build let the decision buttons sit at the end of the content. On a 390-point screen the signal list pushed them below the fold, which put the most important control in the product behind a scroll past every reason to distrust it. A sticky footer and a gradient fade fixed it. Both outcomes now sit pinned to the bottom of the sheet. In a static frame that screen looked finished.
The held payment, with the decision pinned under the signals.
A CHART THAT MEASURED NOTHING
The dashboard carried a line chart of payments screened per week. It looked like insight. What it actually plotted was how much the account had spent, which is the user’s own behaviour and carries no decision for them to make, and it repeated the strip forty pixels below it.
It is one mark per payment now, across four weeks, laid out by day so that busy days crowd and quiet ones leave gaps, with height standing in for the amount. You read it as texture. The only two marks carrying colour are the payment that was held and the one still being watched.
The prototype
Eleven screens you can actually walk through.
Three onboarding beats, four tabs and four overlay flows. It opens on the welcome screen and you use it the way you would use the app, with no rail, no control panel and nothing else around the device. I built it in React so the questions this project asks could be answered by using it.
EVERY COLOUR AND CORNER IS ONE TOKEN AWAY
No component in the build holds a literal colour or radius. A scheme writes all of them as CSS custom properties that the whole app reads, so changing one line re-tints the product end to end. That is how the palette got from plaster and sage to slate without a single screen being redrawn.
WHAT THE SHELL MADE POSSIBLE
01
Scripted reels, for the films on this page
Each film is a script of targets and captions that the prototype plays back to itself. A synthetic pointer travels to a control, taps it, and the narration runs underneath. The prototype ships without them, because a visitor should meet the app and not a workbench.
02
It records itself
A headless recorder drives those reels and captures real frames over the debugging protocol, so every film here is generated from the build. Change a screen, re-run one command, and the case study is current again.
03
Cards as objects
A physical card, a merchant-locked virtual number and a business card, each with its own freeze switch and spend meter.
Validation
What the build showed, and what it only asserts.
The finding that stuck: people will accept almost any safeguard once you tell them why it is there, and resent a small one when you do not. Every decision in the build follows from that. The stack you can move, the instrument that shows its working, the decision that stays on screen.
11
Screens, all navigable, in a shell rather than a clickthrough.
5
Signals behind every hold, each one weighted and shown.
0
Red walls. Every stop arrives with its reasons and both outcomes.
Reflection
What it has not earned yet.
1
The stack is a claim about legibility
I believe six stones read faster than a number, and that losing one reads as losing cover. That is a hypothesis. It needs five people and a stopwatch, not my confidence in it.
2
The dark scheme needs an accessibility pass
State is carried by colour, icon and text together, and I checked contrast by eye. It has not been through a screen reader, or tested past honouring the reduced-motion query.
3
The watching verdict needs a home
Recurring subscriptions sit between cleared and held, and that middle verdict currently gets a badge and one amber mark. It deserves a surface of its own.
4
Business mode is a switch, not a flow
Dual approval over a threshold is stated in the profile and implemented nowhere. It is the obvious next piece of work.
Up next