Completeness Beats Cosmetics

A pretty empty state is still a product lie if the user cannot tell why it is empty.

In August we stopped treating “design quality” as a restyle ticket. Kuda pointed us at checklist.design — a public library of interaction checklists — and we made it a gate, not a mood board. The rule is blunt: ship surfaces where money and leads move only when empty, loading, error, and success are first-class. Visual tokens stay in DESIGN.md. Completeness lives elsewhere.

This is how that landed on Muchiround, and how you can steal the pattern without importing 110 checklists into your backlog.

What we were getting wrong

We already had a visual system: dark-first, one gold primary, tonal depth, mobile-first progressive disclosure. What we did not have was a shared language for the boring moments that decide whether a founder trusts your ledger:

• Wallet top-up still “working” with no processing chrome
• Lead request success with no “what happens next”
• Feed or cart that shows the same blank as a network failure
• Paywall copy that guilts instead of unlocking

Those are not pixel bugs. They are trust bugs. In Zimbabwe and the diaspora, a silent payment or a load-fail painted as “no items yet” burns the same graph that has to print leads revenue.

Related field notes: Custom Currencies Without Lying to Your Ledger, One Fiat Process Path, Fail Closed or Don’t Ship the Webhook. Completeness is the UI half of the same honesty contract.

Completeness is not cosmetics

Layer	SSOT	Job
Visual	zim-platform DESIGN.md	Color, type, elevation, component recipes
Interaction	shared/design-quality.md	States, recovery, CTAs, money next-steps
Product filter	LNR + axioms	What is allowed to ship at all

checklist.design encodes details that make products feel finished: payment processing, form errors after submit, empty vs no-results vs load-error, dismissible onboarding instead of a forced wall. It is a review language. It is not:

• Permission to clone competitor screens
• A mandate to implement the whole library
• A replacement brand

We deleted encyclopedia-scope (marketing-site checklists, full design-system catalogs) until LNR is healthy. P0 is money and lead surfaces only.

The seven questions every UI ticket answers

Every Product spec or Eng ticket that ships user-visible UI must carry a short Design quality appendix. If it cannot answer these, it is not ready:

1. Which checklists are the bar? Link the checklist.design pages — not “looks polished.”
2. What is in scope this ship? Delete the rest. A weak list beats a thrashing one.
3. Empty / zero / no-results / load-error — how do they differ? Three different UIs, three escapes.
4. Loading and success — where, what copy?
5. Primary CTA — one per screen, action-specific copy.
6. Mobile — ≥44pt targets, single-item flow, destructive clarity.
7. Money movement — processing state + terminal success/fail + next steps.

That last row is non-negotiable on wallet top-up, lead prepaid budget, checkout, and RBX tool charges. Async Paystack or mobile money without a calm processing state is how users double-tap and you invent reconciliation tickets.

P0 checklist set (start here, stop early)

We do not browse 110 pages per PR. Default set:

Flows — making a payment, submitting a form, showing input error, adding to cart

Mobile — checkout, cart, paywall, onboarding checklist

Web app — empty state, multi-step form, onboarding

Design system — button, input, toast, modal, skeleton

Map those onto real surfaces:

Surface	Highest-value cues
Pro prepaid lead budget	Multi-step, payment + next steps, empty budget honesty
Consumer lead request	One question at a time, progress, success next steps
Cart / checkout	Add feedback, price breakdown, fail retains data
Wallet / RBX top-up	Processing calm + confirmation + “start using”
Onboarding / first value	Dismissible checklist card, not a full-screen wall
Global empties	Zero ≠ no-results ≠ error on inbox, cart, search, Studio

Explicit rejects

Write these down so review is mechanical:

1. Guilt or shame paywall / dismiss copy — unlock is specific; leave is neutral.
2. Silent payment or lead submission — no processing, no terminal UI.
3. Load failure painted as empty — “Nothing here yet” when the request 500’d.
4. Forced full-screen onboarding when a dismissible checklist card would do.
5. Apple/Google Pay primacy without local rails reality (Paystack, cards, mobile money as applicable).

If a checklist item fights progressive disclosure or LNR scope, delete the item. Completeness does not expand product surface area.

A concrete shape you can paste into a SPEC

## Design quality appendix

**Bars:** https://www.checklist.design/flows/making-a-payment
       https://www.checklist.design/web-app/empty-state
       https://www.checklist.design/mobile/checkout

**In scope this ship**
- [ ] Processing UI while charge is open (disable double submit)
- [ ] Terminal success with next step (e.g. “Budget ready — request leads”)
- [ ] Terminal fail with retry + retained form values
- [ ] Empty budget vs load-error variants on the budget home
- [ ] One primary CTA; secondary quieter

**Out of scope**
- Marketing pricing page checklists
- New animation system / restyle of DESIGN.md tokens

**Mobile**
- Primary and destructive ≥44pt; single-column; sheet not modal on small viewports

Eng definition of done is the checked list — not “works on my laptop at 1440px.”

How agents and humans use the same bar

We run an agentic org. The gate has to survive parallel workers:

• Product owns the appendix and the delete decisions.
• Eng implements against named items and existing primitives (button variants, toasts, sheets) — no one-off chrome per ticket.
• VP owns the company SSOT (shared/design-quality.md); material weakenings of money/empty/error rules need a decision log entry.
• Dogfood uses the same rubric on LNR paths only. A full 110-page audit is performance art.

This pairs with Weakest Sufficient Beats Clever Process: the weakest sufficient design rule is “answer the seven questions on UI that touches money or leads,” not “redesign the brand.”

What good looks like in production (mental model)

Before: User taps top-up. Spinner optional. Success is a quiet balance change. Failure is a toast they miss. Empty wallet and failed rate-fetch look the same.

After:

1. Tap → immediate processing chrome, primary disabled.
2. Success → amount, new balance, one next action (“Buy leads budget” / “Open wallet”).
3. Fail → reason + retry; form values kept; no “empty” illustration.
4. Zero balance with healthy API → empty state with top-up CTA.
5. API down → error state with retry, never the empty illustration.

Same visual system. Different product.

How to adopt this in a week

1. Write a one-pager SSOT — visual vs interaction split; P0 surfaces; explicit rejects.
2. Require the seven-question appendix on the next three money/lead tickets only.
3. Pick five checklist URLs as default bars; link them; stop browsing.
4. Fix one dishonest empty (load-error painted as zero) — highest trust ROI.
5. Refuse restyle PRs that do not change a state machine. Cosmetics without completeness is debt with better kerning.

What’s next for us

P0 stays LNR: budget, lead request, cart/checkout, wallet. Studio and marketing inherit the language when they touch money or first-run. We will not turn checklist.design into a second backlog. We will keep failing closed on silent money UI the same way we fail closed on blank webhook secrets.

If your product moves money or leads in markets where trust is expensive, start with empty ≠ error and payment next steps. Everything else is optional polish.

---

Company decision log: 2026-08-08 checklist.design adoption. SSOT: interaction completeness gate, not a restyle.