Customer app
The customer app is one set of screens served by the BFF as screen trees
(screen), rendered by the Flutter app and as HTML for the web, so every
journey is the same whichever way it is shown. These pages describe the
app as designed: what exists today and what is proposed, each in a view
that answers one question. All three are d2; the wireframe and the
journeys are generated from the screen trees themselves, so they cannot
drift from what the BFF serves.
Screens and their wiring
One phone per screen, grouped by the state the customer is in. A wire runs
from the component that carries the action to the screen or endpoint it
opens; the tab bar's wires are drawn once per state. Dashed phones are
proposed: designed as screen trees in bff/storyboard.go, not yet served.
The storyboard is where a new screen is designed first and becomes the
served screen when its story is built.
Generated by go run ./cmd/bff -wireframe over the stub bank's fixture
customer, so the figures are sample data.
Access
| Customer's state | Session | What Home shows | Log out available |
|---|---|---|---|
| Logged out | none | the login screen | no |
| Locked out (too many failures) | none | the login screen with a wait notice | no |
| Logging in, wrong password | none | the login screen with a notice | no |
| Logged in | valid | the summary: net position, recent movements, accounts, pay | yes, on More |
| Logged in, session idle too long | expired | the signed-out screen with an expired notice | no |
| Signed out | revoked | the signed-out screen, with log in again | no |
| Applying (onboarding) | none | the step the applicant is on | no |
| Checking (onboarding) | none | the pending screen, back to log in | no |
What changes from today: a logged-in customer lands on a summary (Home) rather than the accounts list; the accounts list, activity and account detail keep their place as tabs; log out moves from the accounts list to More and lands on a signed-out screen rather than straight back at the form; an expired session lands on the same screen with a notice; and the login screen offers Open an account, the start of onboarding.
One journey through the BFF
The client only renders screen trees and follows their actions. The BFF authenticates, keeps the session (a token for the app, a cookie for the web), and reads and writes the bank through the core's queries and commands. The core is the bank; it knows nothing of screens.
Vocabulary
| Term | Meaning |
|---|---|
| Screen | one app view: header, body components, nav; a GET path returns it |
| Component | one element of a screen body (hero, row, tx, heading, text, details, form, button) |
| Action | what a tap does: open a screen, submit a form to an endpoint, or log out |
| Endpoint | a POST target that is not a screen (/v1/login, /v1/pay); on success it leads to a screen |
| Journey | the screens and endpoints a customer passes through to do one thing |
| State | where the customer stands with the bank: logged out, logged in, applying, checking |
| Storyboard | every screen the app has or is to have, as screen trees with sample data |
| Proposed | a storyboard screen the BFF does not yet serve in that form |
Where this goes
The storyboard grows by adding screen trees. Next in line: the KYC onboarding workflow (applying, identity check, checking, open), whose first three screens are already drawn; payees, so paying someone is a choice rather than a customer ID; statements.
Stories to build what is drawn, each a release: (1) Home as the summary,
the four-tab nav and More with log out; (2) signed-out screen and the
expired-session notice; (3) pay someone, over core.Transfer; (4) open an
account, over core.OpenCustomer, with the KYC checks stubbed. Story (5),
the demo's phone frame rendered from the same screen trees (roadmap item
5), is built: the demo's Bank App link opens the BFF's own HTML.