Alexander.
All selected workCase study 01

Conversational UX / AI systems / Fintech

Money, by text.
Trust, by design.

I designed and built Nomi around a simple question: can managing money start with a text, instead of another app?

Visit Nomi · textnomi.com ↗

My role
Founder · Product Engineer
Organization
Nomi, formerly WithBFF
Period
2025–present
Nomi’s live homepage hero with a phone conversation and Text nomi call to action
01 / Context

The interface is
the conversation.

“Where did my paycheck go?” is a real question. A dashboard isn’t always the right answer.

Nomi started as WithBFF, a private-beta financial assistant. I designed the product experience and built its stack: React, Python, Supabase, Plaid, Twilio, and an LLM orchestration layer.

SMS makes the details matter. A confusing answer cannot hide behind a clean dashboard. I have to get the words, timing, and financial logic right together.

A budget should feel like something
you helped make.
02 / Decisions

Three changes
that shaped the product.

01

Earn agreement before setting a budget.

The first onboarding flow generated a budget immediately after bank connection. Beta feedback showed a mismatch: a budget could be technically valid without feeling like something the user had agreed to. I redesigned the experience around a seven-day progression, from connection to confirmation to collaborative budgeting.

The tradeoff More steps before a complete budget, in exchange for explicit participation in what the product tracks.

02

Let tools compose around the question.

A rigid intent classifier struggled with compound questions and everyday language. I moved toward LLM orchestration: the model selects financial tools, retrieves the relevant data, and composes a response around the user’s question.

The tradeoff More orchestration complexity and model cost. Tool selection and financial accuracy still need careful evaluation.

03

Separate spending from money movement.

A transfer to savings should not read like overspending. I separated spending, saving, debt reduction, income, and internal transfers so the product could describe what actually happened to the money.

The tradeoff A more detailed classification layer underneath a simpler explanation to the user.

03 / Interface

One small surface.
A lot of product thinking.

Illustrative scenario · fictional data · not a customer transcript

A correction is part of the conversation.

This interaction reconstruction connects the product decisions above with the uncertainty and correction patterns I’m exploring. It demonstrates design intent, not a verified live capability or a research result.

  1. PersonHow much did I spend this week, and how much went to savings?

    Nomi · illustrative replyThe available records show $240 in posted spending and a separate $100 transfer marked as savings. A separate $40 payment is still pending and isn’t included in that total.

  2. PersonThat savings amount isn’t right.

    Nomi · illustrative replyIs the $100 amount wrong, or was that transfer for something other than savings?

    PersonThe amount is right. I moved it to my other checking account.

  3. Nomi · illustrative replyThen this summary should treat the $100 as an internal transfer, not savings. Is that right?

    PersonYes.

    Nomi · illustrative replyWith that correction, the summary is $240 in posted spending, $0 moved to savings, and $100 transferred between checking accounts. The $40 pending payment is still unresolved.

What this makes inspectable: response structure, classification boundaries, and the person’s control over a correction. Reliability and usability still need evaluation.

Nomi conversation artwork from the existing portfolio. This is a product illustration, not a measured user result.
01

Answer the actual question

Bring relevant spending context into the reply instead of sending someone to a dashboard.

02

Make the reasoning legible

A useful answer explains which spending or budget information it is based on.

03

Leave room for correction

When a user disagrees, ask whether the issue is the amount, date, or category before retrying.

04 / Reflection

What the work
changed for me.

The useful feedback came after I thought the design was done.

Onboarding, tool orchestration, and transaction classification are connected design decisions. A clearer message depends on the system underneath it being able to support that promise.

The next work is making the experience more reliable over time: evaluating compound questions, exposing uncertainty in incomplete data, and testing whether the onboarding sequence earns understanding without creating unnecessary delay.

Nomi is an independently founded product in private beta. This case study focuses on the product decisions, rather than measured adoption outcomes.

Next case studyAIE Insured PortalRead the case study
Project screen