Migrating customers from one banking product to another is one of the highest-stakes things a team can do. People are trusting you with their money, their salary, their standing orders and their sense of security. When we set out to move customers into STC Bank, we knew the migration would be judged less on the database cutover and more on a single human question: did it feel safe?

Design's job in a migration is not to make screens look good. It is to make an unfamiliar change feel like continuity. This is the story of how we approached that.

Start from fear, not features

Our first research sessions weren't about flows — they were about worry. We asked people what they were afraid would go wrong when a bank they use changes underneath them. The answers were consistent: “Will my money still be there?”, “Will my card stop working?”, “Will I have to set everything up again?” Those fears became our real requirements.

Design the seams, not just the destination

Customers don't experience a migration as a destination — they experience it as a sequence of seams: the notification that it's coming, the moment they open the app mid-change, the first login, the first transaction. We mapped every one of those seams and treated each as a designed moment with its own copy, its own reassurance and its own clear exit.

What we prioritised

• Continuity of identity — familiar names, card art and balances carried across so nothing felt “reset”.
• Progressive disclosure — we revealed one confident step at a time.
• Always a status — the customer could always see what had moved, what was in progress, what needed them.
• Reversible confidence — clear support and “what happens if” answers within reach.

Words did the heavy lifting

In a migration, copy is the product. We wrote in plain, calm, active language — “Your salary will arrive here from next month”, not “Beneficiary routing has been updated.” We removed apology from error states and replaced it with direction.

Test the scary path, not the happy path

We deliberately usability-tested the anxious paths: what a customer sees if they open the app halfway through the move, if a transfer is pending during cutover, if they log in on a new device. Designing those edges is where migration trust is won or lost.

Rolling out in waves

We phased the migration in controlled waves. Each wave gave us live signal — support tickets, drop-off points, confused screens — that we fed straight back into copy and flow tweaks before the next wave.

What we'd tell the next team

1. Treat trust as the primary metric.
2. Design the transition, not just the arrival.
3. Write every sentence as if a worried person is reading it at midnight.
4. Ship in waves and let real behaviour edit your design.

A great migration is invisible. If customers barely remember it happening, that quiet is the highest compliment our craft can earn.

Fawazeer — the playful riddles families have shared during Ramadan for generations — is one of those traditions everyone in the region grows up with. So when we asked how STC Bank could show up during Ramadan in a way that felt genuinely ours, the answer wasn't a banner or a discount. It was a riddle a day.

The idea

Every day of Ramadan, open the app, solve a Fawazeer, and unlock a small reward. But simple concepts hide hard design problems. A daily ritual has to be effortless to return to, delightful enough to share, and fair enough that everyone can play — including customers using a screen reader or playing one-handed while cooking iftar.

Designing a daily loop

The heart of Fawazeer is the return visit. We designed the loop to be frictionless: a warm entry point on the home screen, a single riddle, an answer, an instant reward, and a gentle nudge that tomorrow's riddle is waiting.

What made it work

• One tap in. The day's riddle was never more than a tap away.
• Instant payoff. Rewards resolved immediately — celebration, not a spinner.
• Streaks with heart. We rewarded consistency without punishing a missed day.
• Arabic-first. Every riddle and animation was designed in Arabic first, then adapted.

Delight, on a deadline

Ramadan doesn't move for anyone's roadmap. We spent our animation budget on the two moments that mattered most — the reveal of the riddle and the burst of a correct answer — and kept everything else calm.

What happened

Fawazeer became a daily habit for a meaningful share of active customers, with strong return rates and a spike in organic sharing as people compared streaks. The number we were proudest of wasn't in a dashboard — it was the messages saying it made the app feel like part of their Ramadan.

A round-up of the biggest things the design and product teams shipped this cycle. We publish these so the whole company can see the craft moving forward.

✦ Headline changes

• International transfers, rebuilt. A clearer journey with upfront fees, live exchange rates and a status you can follow.
• Rewards & savings, seamless. The savings experience dropped several steps and now guides people to finish.
• Faster onboarding. Fewer screens between “download” and “done”.

✦ Improvements

• Refreshed home screen hierarchy — the things people do most are easiest to reach.
• New semantic color tokens across the app for consistent, accessible contrast.
• Clearer, calmer error and empty states in plain language.
• Motion pass on key transitions.

✦ For designers & developers

• Design Tokens 2.4 published to Figma and code.
• SADAD biller logos and “Pay with STC Bank” standards added to Resources.
• 12 components refreshed with dark-mode parity.

✦ Coming next

• Merchant portal redesign entering design review.
• Accessibility pass on transfers and rewards.
• A shared icon library to speed up handoff.

Saving money is something almost everyone wants to do and almost no one finds easy. Our rewards-linked savings experience was supposed to make it effortless — but the first version did the opposite. This is how we found the friction and designed it out.

The problem

The original flow treated saving like opening a product: forms, choices, and jargon before any reward was visible. People started with intent and quietly gave up. The reward — the reason to save — appeared far too late.

What research told us

• Customers wanted to see the benefit first, then the mechanics.
• The word “savings” felt like commitment and paperwork.
• People abandoned when asked to make more than one decision at a time.
• Trust dipped whenever a number appeared without explanation.

The principles we designed to

1. Reward before effort

The first screen now shows what you'll earn, in concrete terms, before asking anything.

2. One decision per screen

Every step asks for exactly one thing.

3. Sensible defaults

Where a choice could be pre-made safely, we made it — with an obvious way to change it.

4. Show the money working

A simple, honest visual shows the reward accruing.

The result

We cut the steps to start saving by roughly 40%, and completion roughly doubled. The feature stopped feeling like a financial product and started feeling like a small, satisfying habit.

What we're carrying forward

Most “complicated” flows aren't too long — they're in the wrong order, asking for effort before they've shown value. We now audit every new flow with one question first: does the reward come before the work?

For many of our customers, sending money abroad isn't a feature — it's a lifeline to family. When a transfer feels uncertain, the anxiety is real. We audited the entire international transfer journey to find exactly where that uncertainty crept in.

How we audited it

We walked the whole journey the way a customer does — from first tap to the moment money lands — and marked every point where a real person paused or reached for support, paired with support tickets and drop-off data.

The pain points we found

• Hidden costs. Fees and rates appeared late, so the amount received was a surprise.
• Silent status. After sending, customers had no honest sense of where their money was.
• Beneficiary friction. Reusing recipients was fiddly.
• Jargon. Compliance language made a stressful task feel more foreign.

The improvements we shipped

Show the real numbers, upfront

Fees and the live rate appear before the customer commits, alongside a clear “amount they'll receive.”

A status you can follow

A simple, truthful progress view — sent, processing, on its way, received.

Recipients that remember

Frequent beneficiaries are front and centre.

Plain human language

We rewrote the journey in the words customers actually use.

What changed

Drop-off at the moments we targeted fell, repeat transfers got quicker, and “where is my money?” support contacts went down noticeably.

In most products, trust is a nice-to-have. In banking, it's the whole product. People don't fall in love with a transfer screen — they decide, in a hundred tiny moments, whether they believe you with their money. Here are seven concrete ways we design for that belief.

1. Show the real number, early

Nothing erodes trust like a surprise at the confirmation screen. Fees, rates and totals belong up front, where they inform a decision rather than ambush it.

2. Never leave a status silent

Uncertainty is the enemy. A clear “processing → sent → received” tells people they can stop worrying — and stop calling support.

3. Write errors as directions, not apologies

An error should say what happened and the one thing to do next. “Something went wrong” tells the customer nothing except that they should be nervous.

4. Make the safe choice the easy choice

Good defaults, clear confirmations for irreversible actions, and gentle friction exactly where it protects someone.

5. Use plain language over banking jargon

“Beneficiary” and “remitter” are the bank's words. “The person you're sending to” is the customer's. We use theirs.

6. Design the empty and first-time states

A first impression happens on an empty screen. We treat it as an invitation to act, not a blank.

7. Be consistent, everywhere

The button that says “Send” produces a screen that says “Sent.” Consistent vocabulary is how people learn to trust the map.

None of these are clever. That's the point — trust is built by being reliably, boringly honest, one screen at a time.

“Just invert the colors” is the most common — and most wrong — instruction a design system gets about dark mode. When we built dark mode for our platform, we learned that accessibility, not aesthetics, is the hard part. Here's how we did it.

The problem with inverting

Our first attempt reused the same brand purple for buttons and for text. On a light surface that purple is crisp; on a dark surface it disappears. We discovered the root issue: several colors were doing two jobs at once — a fill and a text color — and no single value can pass contrast in both roles.

Semantic tokens fixed it

We split every overloaded color into role-based tokens: a brand color for fills, a separate brand-ink for text, an on-accent color for text sitting on fills, and dedicated surface and line tokens. Dark mode then became a matter of re-pointing those tokens, not rewriting components.

The rules we set

• Body text hits at least 4.5:1 against its surface; large text at least 3:1.
• Accent-as-text lightens in dark mode; accent-as-fill stays rich so white text still passes.
• Never rely on opacity to “dim” text — it quietly fails contrast.
• Every state (hover, focus, disabled) is checked in both themes.

Measuring, not guessing

We ran every text-on-background pair through a contrast checker as part of the definition of done. The result: AA across the board, verified — body text landing well above the minimum in both themes.

What we carry forward

The biggest win wasn't dark mode itself — it was the semantic token layer it forced us to build. Every future theme, brand or high-contrast mode now costs a fraction of what the first one did.

Microcopy is the smallest design material we have, and in a banking app it might be the most powerful. When the subject is someone's salary, rent or savings, a single word can be the difference between confidence and panic.

Be specific, not reassuring

“Don't worry, everything's fine” reassures no one. “Your transfer arrived — SAR 500 sent to Ahmed” does, because it's specific. Specificity is the real reassurance.

Name things the way people do

People don't have “beneficiaries,” they have people they send money to. We write from the customer's side of the screen, always.

Keep the verb honest

A button that says “Send” must lead to a screen that says “Sent.” If the label over-promises, trust breaks quietly.

Put the number where the decision is

Fees, totals and timings belong at the moment of choosing — not buried in terms. Copy is how we make a decision fair.

Calm beats clever

We save personality for moments of delight, and keep money moments plain. A pun has no place next to a balance.

Microcopy rarely gets credit, because when it works, no one notices it at all. That invisibility is the job done right.

The gap between downloading a banking app and actually using it is where most people quietly disappear. Our first-run experience asked too much, too early. This is how we got a new customer from install to first action in under three minutes — without cutting a single compliance corner.

Where people left

We instrumented every step and watched the cliffs. The steepest drop wasn't identity verification — it was the wall of setup we asked for before anyone had felt a single benefit.

What we changed

• Defer, don't demand. We moved non-essential setup to after the first useful moment.
• One thing per screen. Each step asks for a single, understandable input.
• Progress you can trust. An honest indicator so people know how close they are.
• Compliance in context. Required checks appear where they make sense, framed in plain language.

Respecting the rules

Banking onboarding has non-negotiable regulatory steps. The trick wasn't removing them — it was sequencing them so they never became the very first impression, and explaining why we ask, in the customer's words.

The outcome

Setup drop-off fell by about a third and first-week activation rose. The lesson generalised: onboarding is a persuasion problem before it's a form problem.

You don't need a lab, a big budget, or ten participants to learn something that changes your design. Most of the value in usability testing comes from the first few sessions — if you ask the right way.

Test the task, not the opinion

Give people a real task and stay quiet. "Transfer 100 riyals to a friend" tells you more than "do you like this screen?" Opinions are polite; behaviour is honest.

Recruit who you have

Colleagues from other teams, a friend, a customer in the branch — rough signal beats no signal. Just avoid testing with people who built the thing.

Write tasks, not questions

• Start each task from the user's goal, not a feature name.
• One task at a time; don't lead.
• Ask "what are you thinking?" only when they go quiet.

Watch for the pause

The moment someone hesitates, re-reads, or backtracks is the finding. Note it, don't rescue them.

Turn notes into fixes

Cluster what you saw, rank by pain and frequency, and fix the top three before the next round. Small, frequent tests beat one big study you run too late.

← Back to blog

When an app does many things — payments, transfers, cards, rewards, savings — the hardest design problem isn't any single screen. It's how the whole thing is organised. Good information architecture is invisible; bad IA is the reason people can't find the thing they use every day.

Structure around goals, not org charts

Menus that mirror internal departments confuse everyone outside the company. Group things by what the customer is trying to do.

Name things the way people do

Card-sorting with real users beats a naming debate in a meeting. Use their words, even when the "correct" term is different.

Shallow beats deep

• Fewer levels means fewer wrong turns.
• Surface the frequent tasks; tuck away the rare ones.
• Always show where I am and how to get back.

Test the tree, not the pixels

Run a quick tree test: can people find key tasks using only the labels, no visuals? If the structure works naked, the UI will only help.

Nail the architecture and every future feature has an obvious home. Skip it, and you'll be patching menus forever.

← Back to blog

Forms are where most digital tasks succeed or fail — and where accessibility is most often overlooked. In a banking app, an inaccessible form isn't an inconvenience; it can lock someone out of their own money.

Labels, always

Every field needs a visible, persistent label — not a placeholder that vanishes the moment someone types. Placeholders are hints, not labels.

Errors that help

• Say what went wrong and how to fix it, next to the field.
• Never rely on colour alone — pair it with text and an icon.
• Move focus to the first error so it's found immediately.

Big targets, clear focus

Generous tap targets and a visible focus ring make a form usable by keyboard, by touch, and by people with motor or vision differences.

Ask for less

The most accessible field is the one you removed. Every question you cut is one fewer chance to exclude someone.

Design the form for the person having the hardest time, and it gets better for everyone.

← Back to blog

Not everything that's easy to measure is worth measuring. Teams drown in dashboards while the questions that matter — is this easier? do people trust it? — go unanswered. Here's how we pick UX metrics with intent.

Pair behaviour with attitude

Task success and time-on-task tell you what happened; a quick "how easy was that?" tells you how it felt. You need both.

Measure the journey, not the vanity

• Completion rate for the key task, not total clicks.
• Drop-off by step, so you know where to look.
• Return behaviour — did the fix actually stick?

Watch trends, not single readings

One number on one day is noise. A line moving over weeks after a change is signal.

Pick two or three metrics per project, tie each to a decision you'd actually make, and ignore the rest.

← Back to blog

An intimate evening where senior designers from leading companies share the real story behind their work — the constraints, the wrong turns, and the decisions that actually moved the needle.

Agenda

1. Doors open & networking
2. Three 20-minute talks from invited design leaders
3. Moderated Q&A with the audience
4. Open networking & refreshments

Speakers

Invited design leaders from prominent product and fintech companies, plus senior designers from the STC Bank team.

What you'll take away

• How leaders frame ambiguous problems
• What separates a good critique from a useful one
• Career lessons from designers a few steps ahead

A hands-on first taste of UX design. Students work in small groups to solve a real, relatable problem and present their idea — learning the basics of empathy, ideation and prototyping along the way.

Agenda

1. Welcome & what is UX?
2. Empathy exercise: understand a real user
3. Sketching & low-fidelity prototyping
4. Team presentations & friendly feedback

Speakers

Facilitated by UX designers and mentors from the STC Bank design team.

What you'll take away

• What UX design actually is
• How to turn a user problem into an idea
• How to sketch and present a concept

An open, informal evening for designers working on money problems. Short talks, portfolio swaps, and honest conversation about the unique challenges of designing for trust, compliance and speed.

Agenda

1. Lightning talks (5 min each)
2. Portfolio swap in pairs
3. Open floor: your hardest fintech UX problem
4. Networking

Speakers

Community speakers plus designers from across the local fintech ecosystem.

What you'll take away

• How other teams handle trust & compliance
• Fresh patterns for money interfaces
• A wider network of fintech designers

A focused online session with local and international experts on the hardest problems in banking UX — regulation, trust, security friction, and doing it all at speed.

Agenda

1. Panel intro & framing the problem
2. Expert perspectives: compliance vs. usability
3. Case examples & teardown
4. Live audience Q&A

Speakers

Local and international banking-UX experts, moderated by the STC Bank design team.

What you'll take away

• How to balance compliance and usability
• Reducing security friction without losing trust
• Shipping quality UX under regulatory constraints

Bring your portfolio and get honest, kind, specific feedback from senior designers. Structured 1:1 slots so you leave with a clear list of what to improve next.

Agenda

1. Check-in & quick intros
2. Round 1: 1:1 portfolio reviews
3. Round 2: group feedback & patterns
4. Wrap-up: your top-3 next steps

Speakers

Senior designers and mentors from the STC Bank design team.

What you'll take away

• Where your portfolio loses the reader
• How to tell a stronger project story
• Concrete next steps to level up

A playful monthly challenge run on our social channels. We post a scenario, you reply with your best idea, and the community's favourite wins a shout-out (and bragging rights).

Agenda

1. We post the scenario & constraints
2. You reply with your concept
3. Community votes on favourites
4. We feature the winning idea

Speakers

Hosted by the STC Bank design team.

What you'll take away

• Rapid ideation under constraints
• Communicating an idea in one post
• Learning from how others think