Create Account vs. Deploy Account

Don't know what "Deploy" means? Yeah, me neither.

I’m currently the designer for the Metri wallet. well, at least until our upcoming rebrand. Management decided it’s finally time to simplify and unify the Gnosis ecosystem under one roof. Soon, Metri will become simply Gnosis, acting as the single gateway for all Gnosis products, such as Circles, and of course, Gnosis Pay.

Gnosis Pay is among the world’s first decentralized payment networks, bridging crypto with traditional financial systems. The integration concept was straightforward: users can order a VISA card, receive an IBAN, and manage everything effortlessly in one wallet.

My roles

UX Design

UI Design

Motion

The Problem:
Technical Jargon & User Trust

While designing the onboarding flow for Gnosis Pay within the Metri wallet, I went through the usual process: checking with backend engineers if we could retrieve ENS names, customizing our third-party KYC integration (Sumsub), etc. But one detail kept nagging at me: The onboarding initially required users to: Create a Gnosis Pay account and then, deploy a Gnosis Safe account after KYC verification.

Wait… “Deploy?” Users don’t care about “deploying” anything. They care about getting their card. Showing these technical, blockchain-heavy terms not only confused users but risked breaking trust. I decided we had to abstract these details. Users just want to get started smoothly. No unnecessary blockchain jargon. I raised this issue with the Product Manager and the Head of Growth. Both quickly agreed: hiding these technical details would provide a clearer, smoother onboarding experience.

Feeling pretty proud, I shipped the simplified onboarding flow to the dev team.

But then came reality….

Just when I thought I had another victory in simplifying Web3 UX, our Tech Lead casually said:

Deploying a Safe can take up to 20 seconds due to on-chain confirmations and multiple steps behind the scenes.

In UX, 20 seconds is an eternity. Letting users stare at a blank screen would definitely create frustration or anxiety, exactly what we didn’t want.

My Quick & Dirty Solution

Obviously, I needed a visual way to reassure users something was happening, but the upcoming rebrand meant it didn’t make sense to invest significant effort (or budget) into animations that would soon become obsolete.

So, I got pragmatic:

I collaborated closely with our Tech Lead and proposed a simple yet effective solution: a clear countdown with visual steps. I asked specifically:

• Can we fetch or listen to these backend events individually?

• Can we detect when each step completes?

The answer was a quick “yes,” and I was back in action.

I immediately designed a minimal step-based progress UI. After careful consideration, I intentionally hid steps 2–4 (“setting currency,” “fetching payload,” and “signing payload”) from users to further avoid technical friction.

This simplified solution clearly communicated progress without burdening users with confusing terminology. It wasn’t fancy, but it was efficient, clear, and solved the core UX challenge effectively.

But stay tuned… animations coming

This experience reinforced my approach to UX: good design isn’t just about aesthetics or final screens, it’s about continuously questioning technical assumptions, proactively identifying UX issues, and closely collaborating across teams (Product, Growth, and Dev) to solve real user problems.