Debt reminders

A cash shop runs on credit in both directions — customers who "pay next week," and suppliers you owe for stock. This screen is the one place to see both, and to act: nudge a late payer, or clear a bill on the Numpad. It's live — switch sides, remind someone, settle a debt (part-payments welcome).

9:41

The screen. One title, two sides on a SegmentedControlThey owe you (money to collect) and You owe (bills to pay). A MetricCard gives the side its one hero figure; a CoachMessage offers the single grounded move ("nudge the two late payments — Ks 16,500"); and each debt is a card with who, what it was for, how late it is, and exactly two actions: Remind and Mark collected / Mark paid. Settling opens the Numpad so a part-payment is as easy as the full amount, and clearing a debt drops it from the list with a named confirmation.

Before
9:41
After
9:41

Before. The pattern this replaces: a single red list that jams owe and owed together, stamps everything OVERDUE in alarm-red, shows a bare -24,500, and packs the only action into a tiny grey "Paid" tap. No context, no way to nudge, nothing to tell a due bill from a late one.

What changed.

  • The two directions split onto a segmented control — collecting and paying are different jobs, so they get different views (and different totals).
  • Alarm-red everywhere became honest status pills: neutral "Due in 3 days", warning/error "Overdue 9d", brand "Reminded today" — real states, not one loud colour.
  • Each row gained context (an Avatar, what it was for) and a primary way to act — a full-size teal button, plus a quiet "Remind."
  • Settling moved to the Numpad with a live read-back, so a Ks 5,000 part-payment against a Ks 8,000 tab is one obvious flow — and it's confirmed by name afterwards.

Why it changed. Red is the system's error colour — flooding a whole screen with it reads as alarm and stops meaning "late." Collecting from a customer and paying a supplier are opposite actions; showing them in one list invites a wrong tap on money. And a shop owner in a market stall needs a big, single action per row, not a 9-pixel target. Every choice here ties to getting paid — and paying on time — without stress.

Which rules apply.

  • Colour roles — teal acts, feedback tokens carry status; red is reserved for a genuine error, never décor.
  • One primary action per row; the secondary stays quiet.
  • Confirm captures — collecting or paying names the amount and who, and says what's left on the tab.
  • Big targets, offline is normal — full-width buttons, and an offline banner that promises the reminder will send when signal returns instead of failing silently.

Every state is designed. Partial payment (the tab keeps the remainder), a cleared side (a calm EmptyState, not a blank screen), offline (an Alert that says what happens next), and "already reminded today" (a brand pill so you don't double-nudge).

User outcome. The owner opens one screen, sees exactly who to chase and what to pay, sends a friendly reminder in two taps, and logs a part-payment on the same pad they use for sales — and trusts the record, because it named the amount and the person back to them.

Reusable rule

When a screen holds two opposite money actions (collect vs pay, in vs out), split them onto a SegmentedControl with their own totals — never one merged list. Status is a feedback pill, not a wall of red, and settling money always runs through the Numpad with a named confirmation.