Design principles
Four principles behind every design decision in Senco.
Clarity first
Every screen answers three questions immediately: Where am I? What can I do? What just happened? Moving money across borders requires trust — show everything, hide nothing.
- Use clear, specific labels — "Send 250 USD" not "Submit"
- One primary action per screen to reduce decision fatigue
- Status feedback is immediate and unambiguous
- Avoid jargon — Senco users may not be native English speakers
- Show exact fees and exchange rate before confirmation
- Break down costs visually (transfer fee + FX markup = total)
- Use recognizable status labels (Pending → Sent → Completed)
Every line item visible: status, fee, rate, received amount. Show exact costs upfront — no surprises.
Fees may apply. See terms and conditions for details on applicable charges and exchange rates.
Vague language hides costs. User has no idea what they'll pay.
Speed over features
Users send money under pressure — reduce steps, not capabilities.
- Core transfer flow is 3 taps: Amount → Recipient → Confirm
- Pre-fill with last-used values (currency, recipient)
- Show exchange rate comparison inline, not behind a "more info" link
- Skeleton screens during loading — never blank screens
Saved methods with inline summary — select, review fee, and confirm. No extra steps.
Force the user to navigate to a separate rates page.
Design for constraints
Senco users often deal with slow or unstable connections and lower-end phones. Every screen must work fully with zero images loaded.
Core rule
Images are enhancement, never content. Financial data, transaction status, and actionable UI must render and operate with zero images. This is the baseline, not a fallback.
Touch targets
Touch targets are 48px minimum. Users may have damaged screens or use the app while moving — generous tap areas prevent errors on critical financial actions.
Text-first rendering
Critical content (balances, transaction status, amounts) loads as text first. Images like avatars and banners are lazy-loaded only when scrolled into view. The user can already act on their data before a single image appears.
Progressive image strategy
| Breakpoint | Max image size | Format |
|---|---|---|
| Mobile (≤600px) | 15 KB | WebP |
| Tablet (≤1024px) | 40 KB | WebP |
| Desktop (>1024px) | 80 KB | WebP + JPEG fallback |
Use srcset with at least 3 sizes. Never serve a single large image to all devices.
Save-Data mode
When the user has Data Saver enabled (Save-Data: on header), Senco strips non-essential images — no promotional banners, initials instead of profile photos, text rates instead of chart visualizations. The page remains branded and clean, not broken.
Cache-first loading
A service worker caches static assets and recent data. On repeat visits, the app renders instantly from cache while fresh data syncs in the background. Image cache is budgeted at 10–15 MB maximum — prioritize financial data over decorative assets.
Offline resilience
When offline, Senco shows cached data with a clear timestamp ("Updated 3 min ago"). Avatars become initial circles, banners become text. All financial information remains accessible. Transfers queue locally and sync when connectivity returns.
Text-first: names, amounts, and status render immediately. Country flags are tiny PNGs that load fast.
Everything loads together — user stares at empty skeletons while images block the render.
Respect Save-Data header — strip banners, use tiny flags, show text rates. 120 KB per session.
Ignoring Data Saver wastes expensive bandwidth on assets the user explicitly opted out of.
Show cached history with clear timestamps. User can still view transactions and status offline.
Full-screen 'No internet' dead-end. User can't see balance, can't see history, can do nothing.
Service worker caches UI assets. Repeat visits render instantly — only fresh data hits the network.
No caching — same 350 KB banner re-downloads every visit. 8+ seconds on 2G.
48px minimum for all interactive elements.
Small targets cause errors on financial actions.
System fonts, SVG, WebP budget, CSS animations — minimal payload.
Web fonts + icon packs + uncompressed images + animation libraries = 755 KB on 3G.
One path, not many
Reduce cognitive load by offering one clear path to each goal.
- Transfer flow is linear (no branching wizards)
- Bank vs. Crypto selection is a comparison, not a choice tree
- Settings are grouped by task ("Notifications", "Security") not by feature
- Navigation is flat: max 2 levels deep
Smart default — surface the most recent contact, let users change if needed.
Too many equal choices. User has to evaluate 5 options before acting.
How to apply these principles
When making a design decision, ask in order:
- Is it clear and transparent? Can the user understand what's happening without instructions? Are all costs and status visible upfront?
- Is it fast? Can we remove a step, pre-fill a field, or show info earlier?
- Does it work on constraints? Will it load on a 3G connection with a low-end phone?
- Is there one path? Are we adding complexity that could be a simpler flow?
If the answer to any question is no, redesign before shipping.