Building design ownership inside a digital bank

Context

I joined a digital banking programme in Egypt midway through design and delivery. The bank already had a three-person design team, an inherited design system and a product taking shape. With launch approaching, my role was to strengthen the team’s practice while keeping delivery moving.

Designers worked across Everyday Banking, Cards & Lending, and Lifestyle services. Individual screens looked cohesive, but journeys crossing those areas exposed inconsistencies.

The deeper issue was how work reached Design: requirements moved straight into Figma, with limited discovery, research or challenge. I focused on three changes: making work visible, improving decisions before UI, and distributing ownership across the team.

One team, one product

I introduced a shared Design Jira board, short daily check-ins and a clearer review process. Designers could see dependencies across value streams and review one another’s work before stakeholder approval.

To make the practice sustainable beyond my engagement, I assigned responsibilities around individual strengths. One designer took ownership of the design system; a senior designer began mentoring a colleague who needed more support.

System ownership also gave component changes a clear review and documentation path. For example, we proposed distinct success, information, warning and error states where the inherited system used the bank’s red brand colour for every toast message.

Inherited

• Success
• Information
• Warning
• Error

Proposed

• Success
• Information
• Warning
• Error

These changes made consistency a shared responsibility.

Better decisions before screens

The most significant change happened in design reviews.

Instead of starting with finished UI, I asked designers to explain the problem, the user, the journey, the evidence and the connection to the wider bank.

Sometimes that meant returning to flows or sketches. Sometimes it meant finding relevant benchmarks, or questioning the requirement with Business.

Before

1. Requirement
2. Figma
3. Approval

After

1. Problem
2. Evidence
3. Flow
4. Design
5. Review
6. Delivery

I also worked with Product and Business to involve Design earlier in discovery. Within roughly the first month, that relationship was beginning to change: designers had more opportunity to shape the work, and clearer expectations for the reasoning behind it.

More time for design

Copywriting exposed another delivery bottleneck. Designers manually transferred English and Arabic content between Figma and Confluence, then updated the screens after review. Larger journeys could consume hours of mechanical work.

Using AI-assisted development, I built a Figma plugin to export structured copy and re-import revisions into the relevant text layers. The mechanical part dropped to roughly 5–10 minutes.

Before

Hours

of manual copy transfer

After

~5–10 minutes

with the plugin

It was a practical bridge while a longer-term content solution remained unresolved, giving designers more time for design judgement.

What changed

The clearest progress was visible in how designers presented their work. Reviews increasingly began with the requirement, user, journey and rationale. Screens followed the explanation.

Business began involving Design earlier. Peer review and mentoring strengthened collaboration, while the design system gained a clear owner.

Research remained lightweight and delivery constraints remained real. This was an improvement in the team’s working practice, rather than a completed transformation.

“

The most valuable change was a team beginning to own its decisions, and explain them.