Product designer, making design fun & useful.

Recently graduated. Four projects I can talk about for an hour each.
NYC METROPOLITAN AREAOPEN TO FULL-TIME
{{ ascii }}
(ABOUT)

I've always been a creative.

I approach design with a sense of quiet intention. My work lives at the intersection of structure and softness, where clarity is not forced but carefully shaped. 

I graduated in 2026 with a B.A. in Information Technology & Informatics, with a minor in Digital Communication, Information, & Media (DCIM). Since then I've been working as the Product Design Lead for New Craft Society at CoCreate. I'm currently looking for full-time work in design roles. When I'm not designing, I'm usually painting, reading, or chasing a good playlist.
DOING
End-to-end product designUser research & interviewsPrototypingDesign systemsVisual & brand identity
USING
FigmaFramerHTML / CSSAfter EffectsAn easel, occasionally
(001) — COCREATE — MACOS + WEB

New Craft Society

A capture tool that gives your design process memory. I led design 0→1 at CoCreate.
(001) OVERVIEW
IN SHORT
Designers lose everything that led to a finished piece. I led design on New Craft Society — a macOS tool that captures the work as it happens, and the web product that turns it back into a story you can hand to someone. Thirty-plus test sessions took our most ambitious feature off the roadmap and put trust and onboarding in its place.
ROLE
Product Design Lead. A design team of four, working with a product owner, a UXR/testing lead and two engineers.
SCOPE
Concept through a dogfooded, publicly tested beta.
WHAT I DID
The capture tool and the landing page, end to end. Research, insights and prioritisation shared with one teammate.
PLATFORM
A macOS capture tool and a companion web app.
Your design process finally has memory.
CoCreate is a design platform providing education and products to early-career designers. New Craft Society is its new vertical: build tools that help top junior designers land jobs.
(002) WHY DO CREATIVES NEED THIS?

The finished piece gets saved. Everything that led to it gets lost.

Where does your work actually live? Figma, Claude chats, a hundred tabs. By the time the case study is due you are doing archaeology on your own work.
SHARED WITH ONE TEAMMATE
30+ DESIGNERS INTERVIEWED, ACROSS SKILL LEVELS
A KEY EXAMPLE — WE HAVE TO BUILD FOR REAL DESIGNERS DAILY
JUNIOR IN INTERACTION DESIGN @ ARTCENTER
I ASKED HER
How would you feel about a tool that lets you show your work-in-progress projects to others?
SHE SAID
“I already do that in Medium. I write blogs and upload screenshots to document my process. I don’t think I’ll need it.”
THE INSIGHT
Designers are missing a dedicated, lightweight WIP layer between raw files and polished portfolio.
THE OPPORTUNITY
Build a tool, not a social media.
CORE PROBLEM STATEMENT
How might we give designers a low-friction way to capture work in progress so that a future case study almost “writes itself”?
THE PITCH
A web app that tracks a designer’s work in progress — faster than writing a doc, progress visible over time, and useful even if nobody else ever sees it.
(003) INSIDE THE PRODUCT

Capture is the easy half. The return trip is the product.

TEAM-LED — CONTEXT FOR THE SECTIONS THAT FOLLOW
Everything captured has to come back as something you would actually scroll. The site makes the promise; the product has to keep it. That meant one unit of content and a timeline that reads chronologically.
New Craft Society from its opening sequence through to a project open inside the product.FIG. 01
THREE VIEWS OF THE SAME MATERIAL
Timeline, moodboard and canvas are not three features. They are three readings of one set of blocks.
TimelineIteration history, read chronologically.
CanvasThe same blocks read as references at scale.
MoodboardThe same blocks read as a wall.
(004) THE CAPTURE TOOL

I designed something beautiful, then cut it for being in the way.

The surface someone sees fifty times a day got the most craft, and the most ruthless editing. Every version that asked for something at the moment of capture lost.
MINE, END TO END
WHAT I PROTOTYPED
I built the alternatives rough and fast — solid enough to test, cheap enough to throw away. Each answered the same question: how little could the tool ask for?
The prototypes I built to test the concept, before any of them had a shape worth defending.FIG. 02
EARLY CONCEPTS
The first pass offered a thumbnail, a filed process, an optional note and save-and-assign — every decision available in the moment.
ANNOTATED — EVERY OPTION IN THE MOMENT
THE VARIANTS BEHIND IT
THE DOGFOOD VERDICT
Four words in the review, and they ended it: too intrusive, too complex.
WHAT THE TEAM SAID

The card had grown into a form parked in the middle of someone’s work, waiting for input. The fix was to stop asking.

Organisation did not disappear — it moved to a moment when the person has attention to spare.

WHAT SHIPPED
⌘⇧2 fires the capture, and it is stored before anything appears on screen. What appears afterwards is a receipt, not a gate — it states what happened, and asks for nothing.
THE SHIPPED CAPTURE TOOL — ⌘⇧2, RECEIPT, NOTHING TO FILL IN
(005) SHARING WITHOUT BUILDING A FEED

Uploading an iteration notifies nobody.

That refusal is where this feature comes from. We had already decided to build a tool and not a social media, so the hard part was holding that line once sharing entered the product.
TEAM-LED — INCLUDED FOR CONTEXT
The link goes out, and the recipient opens it — what changed, one row per iteration, and a name against every stamp.FIG. 03
WHO OWNS THE BYLINE
Two ways a story gets its author. Not two personas — the same designer both times. What differs is where the story came from, and so who owns the byline.
THE PLANS THAT WERE TURNED DOWN
Every rejected version put the tool back in charge of the moment. Writing them down next to the reason is how the shipped answer stayed defensible: you publish, manually, numbered.
PLANWHO DECIDESWHY NOT
Auto-post every iteration
The tool
You start curating what you upload. The rough work stops going in and the diary becomes a feed.
Weekly digest the tool sends
The tool
It owns your cadence. A week where you shipped nothing arrives as a reprimand.
“Since last share” delta
The tool
If it can say what you have not shared, it can imply you are behind. Built, then turned down.
Read receipts, open counts
The number
Once you can see who opened it, you write for the number instead of the record.
Manual publish, numbered
You
Shipped. You choose the moment, the series stays legible, nobody is nagged.
THE FLOW UNDERNEATH
WHAT ARRIVES — A FROZEN NOTE, ONE ROW PER ITERATION
(006) LANDING PAGE

The landing page had to explain capture in terms they already understand.

Users download and are thrown straight into the work, so the page carries all the explaining. I built the capture section to demonstrate the tool rather than describe it.
MINE, END TO END
newcraftsociety.com
THE PAGE AS IT SHIPPED  TOP TO BOTTOM, AS RECORDEDFIG. 04
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.
The heroTwo ways in — download the capture tool, or open the web app.
The demoShow, don’t tell. A simulation of what the tool feels like to use.
The mechanicHow to use the capture tool, in the fewest instructions possible.
Capture typesEvery kind of capture the tool supports, proactive and ambient.
Use casesThe different things a collected process turns out to be good for.
The landing hero
(007) ACTIONABLE INSIGHTS

30+ sessions, turned into a report someone could act on.

We turned issues from 30+ testing sessions into a UXR report — prioritised findings, design recommendations, bugs separated from feature gaps, open questions turned into next steps.
SHARED WITH ONE TEAMMATE
WHAT THE INSIGHTS TURNED INTO
Invisible
The capture and documentation process should be ambient and invisible.
Reflect
The tool should feel like insurance. When you do want to revisit something, none of the process is lost.
Earn trust
Familiar instructions and mental models that build trust with users.
Visual
Uniquely visual ways to interact with and refine captures for accuracy.
AND INTO THE IA
Onboarding/Share & collab/Edit, refine & canvas
(008) FROM RESEARCH TO PRIORITIES

Research only mattered if it changed what we built.

Thirty-plus sessions are just a pile of notes until someone decides what they cost. So we sat down with the product owner and the engineering lead and turned findings into P0, P1 and cut.
SHARED WITH ONE TEAMMATE
SCOPE IT. SEQUENCE IT. CUT IT.
Every feature had to earn its place through demonstrated user value and a realistic build cost. Plotting them against each other is what made the argument unavoidable.
A HARD PRODUCT DECISION

Auto capture started as a P0. It was the most ambitious feature we had.

The internal assumption was clean: remove documentation friction entirely and the feature becomes the product’s killer advantage. Across 30+ sessions, UX logic exposed four gaps we could not answer.
What would it capture?
When would it start?
Who stays in control?
Is it actually useful?
RESEARCH CHANGED THE ROADMAP
The most ambitious feature was not the most valuable. Auto capture came off P0 and went back to exploration; trust and onboarding took its place.
The roadmap before and after the research.FIG. 05
THE NEW SEQUENCE
01
Build trust
Explain what is captured, what is not, and how the user stays in control.
02
Make work useful
Organise and edit captures into a coherent process.
03
Share meaningfully
Save, share and hand process to somebody else.
(009) WHERE IT LANDED

Success is understanding how the work actually gets used.

Everything we measured had to do one of two things: show how the product was being used, or point at a next step.
SHARED WITH ONE TEAMMATE
30+
Desktop app sessions, run and documented.
~50
Live tests in total across the prototypes.
~50
Async tests alongside the live ones.
A METRIC WITH A TARGET ON IT
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.

The half still being tested is the return trip — 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. The honest version of this page is that the capture problem is solved and the memory problem is not, yet.

NEXT (002) EcoBites →
(002) — ACADEMIC — WEB + iOS

EcoBites

A food-delivery model pointed at food insecurity — connecting New Jersey’s food banks, pantries and kitchens to the people who need them.
(001) OVERVIEW
ROLE
UI/UX design and research, on a project team.
TIMELINE
2024 — one semester.
PLATFORM
A client website and an iOS driver app.
CONTEXT
Academic, with the Community Food Bank of New Jersey as stakeholder.
Getting good food to people shouldn’t depend on knowing where to look, having a car, or arriving before the shelves empty.
EcoBites borrows the most familiar pattern in modern life — the food-delivery app — and points it at that gap. The same ease people expect when ordering takeout, redirected toward dignity and nourishment.
(002) THE CLIENT FLOW

Request food in a few taps. No payment, no paperwork.

Open the site and see what is available nearby, right now. Browse by category, open a listing, reserve it — free — then choose delivery or pickup.
RESERVING A BOX — THE WHOLE RUN, RECORDED FROM THE PROTOTYPE
EcoBites — Home
001 — HOME
EcoBites — Browse
002 — BROWSE
EcoBites — Listing detail
003 — FOOD DETAIL
EcoBites — Checkout
004 — CHECKOUT
EcoBites — Confirmed
005 — CONFIRMED
THE FIVE SCREENS IN ORDER — THE CLIP ABOVE RUNS THEM END TO END
FILTERING BY DIET AND FULFILLMENT — NARROWED PAST WHAT EXISTS, THEN WIDENED BACK
(003) WHERE THE TWO APPS MEET

One shared order, two live views.

EcoBites is really two products sharing one 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.
ONE ORDER ACROSS BOTH SURFACES — PLACED ON THE LEFT, ACCEPTED ON THE RIGHT
EcoBites — Client — Finding A Driver
SAME
ORDER
EcoBites driver app — Driver — Open Route
FIG. 04 — THE HANDOFF
(004) THE DRIVER FLOW

Claim a route, verify the items, drive it to the door.

01 RoutesOpen routes waiting to be claimed.
02 DetailWhat the run involves before committing.
03 PickupCollecting from the partner pantry.
04 En routeLive to the person expecting it.
05 DeliveredConfirmed, and closed out.
Driver — open routes
Driver — route detail
Driver — pickup
Driver — en route
Driver — delivered
THE RUN, IN MOTION
Accepting a route, verifying every box against the order before it leaves the pantry, then driving it to the door. The cargo check is the only step that cannot be skipped — it is what makes the handoff accountable.
…AND BACK TO THE CLIENT
Every status the driver sets lands back on the client’s tracker in real time — here, marked delivered.
EcoBites — Delivered
(005) MAPPING THE SYSTEM

Four moves, from a messy problem to a calm flow.

Map the network
Catalogued the real organizations — banks, pantries, kitchens — and the routes food already travels between them.
Define the model
Reframed delivery as a two-sided service: recipients request, and volunteers or partners fulfil.
Design the flows
Prioritized first-run, browse-by-need and order-tracking so a stressed first-time user could move without friction.
Build the system
A warm, legible component set — large tap targets, plain language, reassurance on every screen.
Context diagram — EcoBites sits in the middle, brokering what each party gives and gets: logistics with pantries, delivery info with drivers, food and status with clients.FIG. 01
Cross-functional flow — the same order traced across all four actors, from account creation and eligibility through pickup, delivery and feedback.FIG. 02
Process flows — every screen and decision mapped per role, client above and driver below, down to onboarding, verification and each tab.FIG. 03
(006) THE PROBLEM

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.
1.2M
NEW JERSEYANS FACING FOOD INSECURITY
4
ACTORS IN ONE ORDER
2
APPS SHARING ONE LIVE ORDER
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.
(007) WHAT CHANGED

It started as a waitlist. It became a delivery network.

The first version of EcoBites let people register on waitlists at participating pantries and food banks, and coordinated surplus food out to them. The version here replaces the waitlist with a live request.
ORIGINAL CONCEPTWHERE IT LANDED
HOW YOU GET FOODRegister on a waitlist at a participating providerReserve what is on the shelf right now
WHEN YOU FIND OUTWhen your turn comes upImmediately, with live tracking
WHO MOVES ITCoordinated distributionA nearby volunteer claims the route
WHAT YOU SEEA list of providersOne order, two live views
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.
(008) WHERE IT LANDED

Dignity is a design requirement.

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.

EcoBites reframed a heavy, bureaucratic experience as something gentle and immediate. The biggest lesson was not visual — it was that dignity is a design requirement. Every word, every wait state, every empty screen had to reassure rather than gatekeep.

If I took it further, I would pilot it with a single county’s pantry network and design the volunteer-side tooling that makes the model actually run.

NEXT (003) Catalogue →
(003) — SELF-DIRECTED — WEB + EXTENSION

Catalogue

Online shopping reimagined as editorial storytelling — save products from across the web and assemble them into magazine-like collections.
(001) OVERVIEW
ROLE
Product design — UX, UI and systems.
TIMELINE
2025 — present (wip).
PLATFORM
Desktop web and a browser extension.
CONTEXT
Self-directed concept.
The whole web is a shop — but saving things to it feels like dropping them into a junk drawer.

Wishlists, screenshots, open tabs, “saved” folders that never get reopened. The way we collect things to buy is messy, context-less and joyless — the opposite of how it feels to flip through a beautiful magazine.

Catalogue treats every saved product as a clipping you can compose with. Save from anywhere, then arrange your finds into editorial spreads — typography, layout and white space included.

(002) THE PRODUCT

A canvas that behaves like a page.

catalogue.app/editor/modernist-interiors-vol-04
Catalogue — Editorial canvas
FIG. 04 — THE EDITORIAL CANVAS, WITH AN AI CAPTION CO-PILOT
catalogue.app/editor/modernist-interiors-vol-04
Catalogue — Theme and palette
FIG. 05 — AI PROPOSES A PALETTE AND FLAGS CONTRAST FAILURES INLINE
catalogue.app/library
Catalogue — Curated library
catalogue.app/read/nordic-home
Catalogue — Published issue
FIG. 06 — THE CURATED LIBRARY, AND A COLLECTION PUBLISHED AS A SHOPPABLE ISSUE
(003) THE APPROACH

From clipping to composition.

Capture anywhere
A browser extension that pulls the image, title, price and source into a clean, consistent product card.
A flexible card system
One product, many sizes — a component scale that lets a card be a hero, a thumbnail or a footnote without redrawing it.
The editorial canvas
A grid that snaps but bends — drag, resize and caption products into spreads that feel printed, not pasted.
Share the issue
Collections publish as scrollable issues — sendable, followable, shoppable.
catalogue.app/import
Catalogue — Import editor
catalogue.app/settings
Catalogue — Extension preferences
FIG. 02 — THE IMPORT EDITOR REFINES EACH CAPTURE; PREFERENCES TUNE WHAT THE ENGINE EXTRACTS
catalogue.app/editor/new
Catalogue — Page templates
FIG. 03 — EVERY SPREAD STARTS FROM A FLEXIBLE PAGE TEMPLATE
(004) THE TENSION

Saving should feel like curating, not hoarding.

Existing tools force a choice: structured but sterile, like spreadsheets and wishlists, or beautiful but shallow, like image boards that lose the price, the link, the why. Catalogue had to hold real product data and still feel like design.
OnboardingInstall once, then it stays out of the way.
In contextRight-click anything, on any site.
The popupConfirm and file without leaving the page.
Extension onboarding
In-context capture
Capture popup
FIG. 01 — ONBOARD ONCE, THEN CAPTURE FROM ANY SITE WITH A RIGHT-CLICK OR THE POPUP
(005) WHERE IT LANDED

One card and one grid carried the whole thing.

1
Card component that flexes across every layout.
3
Surfaces — extension, canvas, published issue.
Spreads from one snapping-but-bending grid.

Catalogue taught me how much a single, well-built component can carry. Most of the design effort went into one card and one grid — and once those were right, the editorial feeling came almost for free.

The open question I would tackle next: how do you keep a feed of other people’s issues inspiring without turning it into another endless scroll?

NEXT (004) TruePay →
(004) — FINTECH CONCEPT — MOBILE

TruePay

A payments app built around a fraud model, rebuilt as a working front-end shell to test one claim — that showing a security model’s reasoning reassures people more than asserting its verdict.
(001) OVERVIEW
ROLE
Product design and the front-end build — research framing, flows, UI, and the working prototype.
TIMELINE
2023 — 6 weeks.
PLATFORM
Mobile. Built as a real React app, not a clickthrough.
CONTEXT
Academic fintech concept.
A security model people can read is worth more than one they are told to trust.

When a bank stops a payment you learn two things: that it was stopped, and that you should call someone. You never learn what tripped it. The suspicion is real, the reasoning is sealed, and the cost lands on you — a dead card at a counter, twenty minutes on hold, a dispute form that asks you to prove a negative.

TruePay started as a concept with the right ingredients: a security score, live alerts, biometric approval, a model watching every transaction. But it spent them on reassurance — badges telling you that you were safe. That is the same black box in nicer packaging.

So I rebuilt it as a working front-end shell, because the interesting questions here are not answerable in static frames. How much security presence is too much? Does anyone actually read five risk factors, or do they just want the verdict? Does making the model legible calm someone down, or hand them a new thing to worry about?

The forty-second version
Onboarding, then home, then a payment sent, screened and approved. If you watch one thing on this page, make it this — the prototype drives itself.
(002) THE QUESTION

Security you never see is invisible. Security you always see is a checkpoint.

This is the tension the whole product sits on, and I did not want to settle it by argument. So I built visibility as a live variable with three settings, and made every screen answer to it.
TruePay home — quiet
Quiet
Present, but not shouting. No score, no trust block.
TruePay home — default
Default
As it ships: score in the header, trust block in the feed.
TruePay home — foregrounded
Foregrounded
Something needs attention, so narration takes the top.
FIG. 01 — ONE SCREEN, THREE POSTURES, SWITCHABLE AT RUNTIME

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 right after a hold, when narration is genuinely wanted, and nowhere else.

(003) THE CALM PATH

Most payments are fine. The design has to believe that.

Ninety-nine times out of a hundred the model has nothing to say, and the screening should cost you nothing but a beat of reassurance. Five steps, one thumb, no interruption — and the security work stays visible without ever asking permission.
TruePay — Recipient
01 — PICK
TruePay — Amount
02 — ENTER
TruePay — Screening
03 — SCREENED
TruePay — Biometric confirm
04 — APPROVED WITH FACE ID
TruePay — Sent
05 — SENT & VERIFIED
FIG. 02 — FOUR CHECKS RUN BEFORE THE MONEY MOVES, AND THE USER NEVER WAITS ON THEM
(004) READING THE RISK

People need to know how bad it is before they need to know why.

A held payment normally arrives as a wall of text. But the first question is never why — it is how bad. So the review leads with the shape of the suspicion, and only then explains itself.
THE SHAPE, THEN THE REASONS
Silhouette first
Five signals on five axes. A shape pulled hard toward two of them means something specific is wrong — not that everything is faintly off. You read that in under a second, and confidence sits as one number in the middle.
Then the list
Strongest-first, each signal’s weight drawn as a bar. The radar answers how much; the list answers which. Splitting those two jobs is what stops the screen reading as model output dumped on a user.
FIG. 03 — UNKNOWN MERCHANT 94, UNUSUAL AMOUNT 86, DISTANT ORIGIN 62, OFF-PATTERN TIMING 34, DEVICE MATCH 12
Colour before you read a word
The same tension runs underneath the whole app: a drifting field behind every screen shifts from calm, to screening, to held, to cleared. It never carries state alone — every mood is paired with text, an icon and a token — but it is what makes the app feel read before the review screen explains itself.
FIG. 03B — CALM · SCREENING · HELD · CLEARED
(005) THE DECISION

Held is not blocked. The model narrows the choice; it never takes it.

There is no path where the review resolves itself and tells you afterwards. Both outcomes sit in a footer pinned to the bottom of the sheet, so however long the signal list runs, the decision stays one thumb-reach away.
Yes, this was me
Releases the payment and folds the merchant into what the model trusts — it will not stop you there again.
Not me
Freezes the card, opens a dispute, and says plainly that you are not liable while it is reviewed. Neither outcome is a dead end.
TruePay — Transaction detail
CLEARED — WITH THE PROOF
A fix, not a plan
The first build let the buttons sit at the end of the content. On a 390-point screen the signal list pushed them below the fold — the single most important control in the product, reachable only by scrolling past every reason to distrust it. Sticky footer, gradient fade, problem gone.

I only caught it because the prototype was real enough to scroll. That is the argument for building the thing.
(006) THE SCORE

A number you cannot move is decoration.

Trust scores in finance apps are usually handed down, with no visible relationship to anything you control. Here the score is the sum of six protection weights. Switch one off and it recalculates in front of you.
TRUST BLOOM — 72 TICKS ON A STANDING WAVE
Why not a ring
The visual had to be able to degrade, which ruled out a progress ring — a ring at 42% looks like a ring at 96%, only shorter. Instead the score is 72 ticks riding a standing wave. Lit ticks encode the value; a second, rougher harmonic scales with how much cover you have lost.

So a weakened score does not merely shrink. It visibly frays. The number and the feeling move together.
FIG. 04 — PROTECTIONS COME OFF, THE WAVE FRAYS, THEN THEY GO BACK ON
(007) THE CRAFT

Dark fintech has a house style. I went to banknotes instead.

Following the house style would have produced a competent app nobody remembers. The material I reached for was security printing — banknotes, share certificates, cheque stock — not as pastiche, but for the two things it does well: fine line-work that signals value, and typography that treats numbers as the subject.
Guilloché under the money
Real spirograph geometry sits beneath the balance and every card face — the same construction used on currency to make forgery expensive. Drawn faintly enough that most people never consciously notice it, which is the point: it makes those surfaces read as an object with value rather than a coloured rectangle.
Four faces, one job each
A grotesque for display and balances, one italic serif word carrying the pitch in the headline and never appearing again, a humanist sans for interface prose, and a mono for every micro-label — so timestamps and card numbers line up down the screen instead of drifting.
Acid lime for verified
The one deliberate oddity. Green on violet goes muddy; lime cuts. It is the colour the eye finds first in a feed of cleared payments, which is exactly the job.
A spectrum that derives itself
The two companion gradient stops are not hand-picked — they rotate off the chosen accent in hue, so the brand gradient stays coherent whichever accent is set.
TruePay — Balance card
THE BALANCE AS AN OBJECT
Tactility
The balance card tilts under the pointer and catches a specular sweep that tracks the cursor. On a payments surface that is not decoration — it is the difference between a number on a screen and a thing you own.
(008) THE SYSTEM

Every colour and corner in the build is one token away from changing.

The prototype ships with its own control panel. Accent, corner radius, type pairing and AI presence are all live, and each writes a CSS custom property the whole app reads — no component holds a literal colour or radius. It exists so a design review can change the argument mid-sentence instead of asking for another round of comps.
WELCOMECALIBRATINGFACE IDHOMEACTIVITYSECURITYPROFILESEND MONEYHELD PAYMENTTRANSACTIONCARDS
ELEVEN SCENES — THREE ONBOARDING BEATS, FOUR TABS, FOUR OVERLAY FLOWS — ALL REACHABLE BY ARROW KEY
FIG. 05 — THE STAGE: SCENE RAIL, DEVICE, AND THE LIVE TOKEN PANEL
Autoplay, for people who will not click
Seven scripted reels drive the prototype hands-free — a synthetic pointer travels to each control, taps it, and a caption narrates underneath. A record mode strips the stage chrome so a screen capture comes out clean.
Built to be recorded
At a viewport around 945 points tall the device renders at exactly 390 × 844, so a retina capture gives clean 2× pixels with no resampling. The prototype is its own asset pipeline.
Cards
A physical card, a merchant-locked virtual number, and a business card — each with its own freeze switch and spend meter, drawn with the same banknote line-work as the balance.
(009) WHERE IT LANDED

Security as a relationship, not a gauntlet.

11
Screens, all navigable — a shell, not a clickthrough.
5
Signals behind every hold, each one weighted and shown.
0
Red walls. Every stop comes with its reasons and both outcomes.

The insight that stuck: people will accept almost any safeguard if you tell them why it is there, and resent the smallest one if you do not. Every decision in this build follows from that — the radar, the ambient field, the score you can move, the decision that never leaves the screen.

Rebuilding it as a working shell rather than a prototype deck was the right call for a second reason I did not expect: the sticky-footer problem in (005) is invisible in static frames. You only find it by scrolling a real screen at a real size.

What it has not earned yet
Does the radar actually read?
I believe the silhouette is faster than a list. That is a hypothesis, and it needs five people and a stopwatch, not my confidence.
An accessibility pass on the ambient field
State is carried by colour, icon and text together — but I have not tested it with a screen reader, or at reduced motion beyond honouring the media query.
The watching verdict needs a home
Recurring subscriptions sit between cleared and held, and that middle verdict currently only appears as a badge. It deserves a surface.
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 build.
BACKAll work →
THANVI NIMMALA © 2026{{ clock }}