Part 8 · 1 chapters · ~10 min
Designing Forms
Forms as the core of money products: asking for less by deriving and deferring, single-column layouts with persistent labels, the right inputs and autocomplete hints, validation on blur then live after an error, specific accessible error messages, and long flows with steps, autosave and a clear confirm screen.
16
Forms are the product
code
<label for="acct">Account number</label>
<input id="acct" name="acct" inputmode="numeric" autocomplete="off" pattern="[0-9]{10}" maxlength="10"
aria-describedby="acct-hint acct-err" aria-invalid="true">
<p id="acct-hint">10 digits, from your bank app or card</p>
<p id="acct-err" class="error">Enter the 10-digit account number</p>
<label for="otp">Code we sent to 0803 *** 4421</label>
<input id="otp" inputmode="numeric" autocomplete="one-time-code" maxlength="6">| weak message | better message |
|---|---|
| Invalid input | Enter the 10-digit account number |
| Error 500 | We could not send this transfer. No money has left your account. Try again. |
| Amount exceeds limit | You can send up to ₦200,000 today. You have ₦45,000 left. |
| Date invalid | Enter your date of birth as day, month and year, for example 14 03 1995 |
where the form meets the system
The money-safety rules from the Trust course (idempotent submit, disabled double-submit, "did the money move?") all show up on the last step of a form. Design that step with engineering in the room, because the honest message depends on what the backend can actually know at that moment.
DESIGNING FORMS
the part of a money product where users actually do things: structure, input types, validation timing, errors and long flows
swipe the figure sideways, or tap expand for full screen
1/6
ask for less
Ask for less: every field costs completion. Remove what you can derive (city from postcode, bank name from account number via name enquiry), defer what is not needed yet (ask for employer details at loan application, not at sign-up), and never ask twice for something you already have.