ux-copy

|--------|------|------|----------| | **1A** | "Card declined. Your bank didn't approve this payment. Try another card or call your bank." | Direct, brief | Narrow layouts, inline form errors | | **1B** | "We couldn't process this card. Your bank declined the payment. Try a different card or contact your bank for details." | Empathetic, soft | Users who may feel embarrassed about a decline | | **1C** | "Payment declined by your bank. Please use a different card or contact your bank." | Formal | Finance-heavy or enterprise audiences | | **2A** | "Almost there. Add at least 12 characters and one number." | Friendly | Consumer-leaning onboarding | | **2B** | "Your password is too short. Use at least 12 characters." (or) "Add at least one number to your password." | Specific, adaptive | When you can detect which rule failed | | **2C** | "Password must be 12+ characters and include a number." | Compact | Tight inline space | | **3A** | "This file is over the 25 MB limit. Try a smaller file or compress it." | Direct | Inline upload errors | | **3B** | "That file is too big to upload. Receipts must be under 25 MB. Try compressing it or taking a lower-resolution photo." | Helpful, conversational | Mobile-photo-heavy users | | **3C** | "Upload failed: file exceeds 25 MB. Choose a smaller file." | Neutral, technical | Power users, admin contexts | ### Rationale - **Declined card:** The old message exposes an internal code and says nothing useful. Naming the cause (the bank declined it) tells users the problem isn't with Tallyroom, which cuts the "is your app broken?" tickets. The two next steps (different card, call the bank) give them a path forward. - **Password:** "Invalid input" doesn't say what's invalid or why. Stating the requirements in the error removes guesswork. Showing the rules before the user types (as helper text) will reduce errors even further. - **File size:** "Something went wrong, try later" is actively misleading, since retrying the same file will fail every time. Stating the limit and the fix lets users resolve it immediately. Mentioning compression helps people who don't know how to shrink a file. - All three follow the pattern **what happened, why, how to fix**, and use the same terms the user sees in the UI (card, password, file/receipt). ### Implementation Notes - **Don't hide the cause behind a generic message.** If the system can distinguish between decline reasons (insufficient funds, expired card, etc.), consider showing the more specific message. But only if your payment provider allows it. Some banks don't return reasons, and the generic "declined by your bank" is safest. - **Keep error code 4012 in logs or a "Details" link** for support, but don't lead with it. - **Show the password requirements persistently** beneath the field, not only after an error. - **Check the file size on selection**, before upload starts, so users don't wait for a failed upload. - If a tester sees "Something went wrong" elsewhere in the app, apply the same scrutiny. It's usually a sign of a missing, specific error state. ### Localization Notes - **"Declined"** has a specific financial meaning. Make sure translations don't read as "rejected" in a personal sense. - **"Contact your bank"** may need adapting where users commonly visit a branch or use a different channel. - **Units:** Keep "MB" as is, but check whether your locales expect "Mo" (French) or "Mb" notation. - **Character expansion:** German and Finnish may run 30-40% longer. The password and file-size messages are the tightest, so leave room in the layout or use the compact alternatives (2C, 3A). - **"12 characters and one number"**: Use number formatting and plural rules properly in locales with complex plurals (e.g., Russian, Polish). Use ICU message format or equivalent for the variable counts. - Avoid idioms like "Almost there" (2A) in localized versions unless you have a vetted equivalent.