Lori

Who it’s for

• Early-career earners with irregular or partially informal income (the default currency is Naira, with multi-currency support for NGN, USD, EUR, CAD, GHS, KES, ZAR), who find Western budgeting apps’ assumptions about salaried income and bank-linked accounts a poor fit.
• People who already save with an informal mental model (“rent money,” “travel fund”) and want that model reflected back at them, rather than being forced into generic “budget categories.”
• Users who will only sustain a finance habit if logging an expense is as fast as sending a text.

Product pillars

• Chat, don’t type forms — natural-language logging is the primary input, not a bolt-on assistant.
• Goals that track themselves — every naira/dollar recorded is attributed to a goal automatically.
• Real analytics — spend-by-category and cash-flow are computed from actual transactions, never rounded estimates.
• A plan built around you — onboarding derives a target, timeline, and weekly contribution from one conversation, sized to the income the user actually reports.
• Speaks your currency — currency is a first-class setting, not a hardcoded “$” string.

Research questions

• Why do people who want to save money stop using budgeting apps within weeks of installing them?
• What does “saving” actually look like day-to-day for someone with irregular or partially informal income?
• Where does the mental effort of budgeting live — is it the math, the categorization, the memory, or the shame of looking?

Methods I used

Competitive audit

What I found

• 68% of my screener respondents had installed and abandoned at least one budgeting app in the past year; the single most-cited reason (54%) was “too much manual entry.”
• Participants with irregular income described existing apps’ monthly-budget assumption as actively discouraging — a missed “budget” for an income-less week felt like a moral failure rather than a data point.
• Every person I interviewed already narrated spending to themselves or a partner in natural language (“I spent way too much on food this week”) before ever opening an app — the app was translating a sentence they’d already formed into a form they hadn’t wanted to fill out.
• My diary studies showed a consistent lag: money was actually logged 1–3 days after the transaction, usually in a batch, because the in-the-moment friction of opening an app and picking a category was enough to defer it.

“I know exactly what I spent it on when it happens. By the time I sit down to put it in the app, I’ve forgotten half of it and I just guess.”— P07, diary study participant

“Budgeting apps are built for someone with one salary that lands on the 1st. Mine doesn’t work like that.”— P03, screener follow-up interview

Current-state journey map — Adaeze

Problem statement

“People who want to save money don’t fail at the math — they fail at the logging. Every existing tool asks for structure (a category, a plan, a monthly budget) before it will accept a single naira of information, and that upfront cost is enough to make people quit within a month.”

How-might-we questions

• How might we let someone log a transaction in the same three seconds it takes to send a text?
• How might we propose a savings plan instead of asking a first-timer to invent one from a blank field?
• How might we make “irregular income” a supported case rather than an edge case?

Success metrics I set at this stage

Information architecture

I scoped five destinations directly from the persona needs, then ran a closed card sort (8 participants, 22 cards) to confirm the labels matched participants’ own mental model rather than my internal vocabulary — “Goals” beat out “Plans” and “Targets” by a wide margin in the sort.

Full destination-by-destination breakdown in 10 — Information architecture below.

Prototyping

• Lo-fi: grayscale wireframes in Figma, chat thread + dashboard only, which I used for the first usability round.
• Mid-fi: full IA, real copy, no motion or brand color — I used this stage to pressure-test comprehension of the goal-progress bar concept before investing in the segmented “barcode” treatment.
• Hi-fi: the dark theme, brand gradient, and heat-gradient progress fill applied — used for the second usability round and carried into the eventual build.

Usability round 2 — hi-fi prototype (n = 6, incl. 2 repeat participants)

Accessibility pass

• I contrast-checked every text/background pairing in the dark palette against WCAG AA; two muted-text tokens got darkened slightly after failing on the darkest card surface.
• I verified the app is fully operable with prefers-reduced-motion enabled — the animated gradient shimmer and glow were the two surfaces most likely to violate this, so I tested them explicitly.
• I confirmed goal status and savings deltas never rely on color alone — text labels and directional icons carry the same information redundantly.

Dev handoff

I handed off using a shared Figma library mapped 1:1 to the CSS custom properties that shipped (color, spacing, radius tokens), so “the token is called --accent-solid in the file” was also true in the codebase — removing the usual translation step where a developer has to guess which design token maps to which implemented variable.

Post-launch results (first 6 weeks)

Color

The palette is dark-mode only by design (color-scheme: dark is set at the document root, with no light theme) — appropriate for a product whose primary screen is effectively a running ledger, where a bright white surface would compete with the numbers rather than recede behind them.

The brand gradient (orange → red → orange, #FD8A48 → #EA0707 → #F67606) is reserved for AI-attributed moments: the active sidebar item, the send button, the “Ask AI” pill, and the Lori’s Insight card border. It never appears on purely structural chrome, so its appearance reliably signals “this is Lori talking,” not just “this is a button.” A second, distinct gradient (orange → yellow → green, #FD8A48 → #FFD34F → #84EA18) is used only for onboarding progress and the plan-reveal card, deliberately different from the brand gradient so “you are warming up toward a plan” reads as its own state, not a re-skin of the AI accent.

A full-spectrum “heat” gradient (violet → pink → orange → amber → green) drives every progress visual — the smooth savings bar and the segmented “barcode” goal bars — so a new chart type automatically inherits the same ramp instead of a designer having to redefine it.

Typography

Geist Sans/Mono, self-hosted rather than loaded from Google Fonts — avoiding a third-party network request on every page load and guaranteeing the exact numeral and letterform rendering the design was built against, which matters for a product where large animated numbers are a focal point.

Elevation & structure

Surfaces are distinguished by fill and a hairline border (rgba(255,255,255,0.08) subtle / 0.14 strong) rather than drop shadows — shadows read poorly on a near-black background and would need to be faked with lighter fills anyway, so the system skips that step and commits to flat, bordered cards throughout.

Motion principles

• Purposeful, not decorative: animated numbers count up once (to draw the eye to a value that changed), progress bars ease in, but nothing loops indefinitely except the handful of surfaces that represent “AI is present” (see below).
• AI presence has its own signature: a slow (3.5s+), low-amplitude gradient-border shimmer plus a breathing glow, applied only to the AI Insight card and the Ask AI button — a deliberately quiet “living” accent rather than a flashing one, so it reads as ambient intelligence rather than an alert.
• Every animation and transition collapses under prefers-reduced-motion: reduce — including a blanket safety-net rule (0.01ms duration, single iteration) so no future component can accidentally ship an animation that ignores the preference.
• Hover states use a mouse-tracked radial “spotlight” (a Stripe/Linear-style highlight that follows the cursor position via CSS custom properties, not JS-driven repaint) — cheap, GPU-friendly, and consistent with the rest of the system’s preference for CSS-native effects over animation libraries where possible.

Two structural notes worth calling out: dashboard sections were deliberately reordered post-launch so the Total Savings card sits immediately after the greeting — the highest-value number is the first thing a returning user sees, not the third. And every sidebar icon that doesn’t yet have a real destination stays visually present but inert (documented in code as “visual-only demo”), rather than being hidden — preserving the intended eventual IA in the UI while being explicit in code about what is and isn’t live.