QFind anything/
API Reference

Figma handoff — one-page outline

Single-page workshop layout: personas, swimlanes, and core flows for Payment Reconciler UX.

Use this as one artboard or document in Figma (or Miro). Terminology: incoming transaction, expected transaction, merchant, match — see Domain vocabulary.


1. Personas (top of page)

PersonaGoalMust design for
Super-adminRight tenant + environment every time; cross-tenant user supportTenant switcher / “acting as” context, user admin across customers
Org adminTheir tenant + environment correct; data sources, field mappings, rules, schedules, webhooks, API keys, usersOnboarding, settings, integration health
Reconciliation userExpected + incoming queues; match review; exceptionsLists, detail, accept/reject, search/filter
Read-only userSame visibility, no editsDisabled/hidden actions, messaging
Automation (implicit)Reliable feeds and jobsSync logs, job status, errors

2. Swimlanes — touchpoints (expanded)

Draw five lanes (super-admin is distinct from org admin). Each cell is a place users go or a task—design each as a real screen or modal where applicable.

LaneTouchpoints (grouped)
Super-adminSelect tenant + environment before any work · User lifecycle across tenants (assign/remove, roles) · Same operational screens as org admin only after context is explicit
Org adminTenant / environment (fixed to their org) · Tenant settings (matching, locale, LedgerMatch prefs, job schedules, cache) · Users & roles (within tenant) · Data sources (Stripe, EBICS, …) · Field mappings · API keys · Webhooks (create, test, deliveries) · Jobs (list, trigger, cancel)
Reconciliation userExpected transactions (list, create, edit, delete, import) · Incoming transactions (list, filters, manual create/edit, CSV upload) · Match queue / detail · Accept / reject · Trigger matching · Exception search (reference, merchant, amount)
Read-only userSame navigational structure as above; mutation entry points removed
System / backgroundScheduled sync · Matching batch · Auto-accept rules · Webhook dispatch & retry (show outcomes in admin UI)

Workshop prompt: “For each admin touchpoint, draw one arrow to the incoming or expected screen it unblocks.”


3. Flow index (columns or rows)

Use Interaction flows for step tables. Suggested nine strips (A–I):

IDNameOne-line intent
AResolve one incomingAccept/reject matches
BStripe liveData source + mapping + sync → incoming
CBank (EBICS) liveInit letter → import → incoming
DCSVUpload → incoming
EExpected lifecycleCRUD + filters + import
FField mappingPer-source rules
GWebhooksCreate, test, deliveries
HAPI keysCreate, rotate
IJobsMonitor, trigger, cancel

Core product loop remains A; B/C/D are “get incoming in”; E feeds A; F supports B/C/D.


4. Global UI checklist

  • Tenant + environment always obvious
  • Labels use merchant, incoming / expected, match
  • Viewer role: no broken primary actions
  • Errors link to data source, mapping, or expected data
  • Jobs and sync logs answer “what ran last night?”


Optional Mermaid — swimlanes

Rendering diagram…

Super-admin is a separate lane (not a step before org admin); no implied ordering between super-admin and tenant-scoped roles.