No one should have to call their bank just to check their balance

Sygnum's product had grown quickly across multiple teams, each designing and building independently. The result was inconsistent layouts, changing terminology from page to page, and no single view of a client's digital asset holdings. The interface felt dated and untrustworthy.

Clients were high-net-worth private banking clients, accustomed to personal service. They still expected immediate access to their balances, clear explanations of what they owned, and an experience comparable to modern banking. They understood financial products. The interface needed to respect that, not talk down to it.

I was the Design Lead on this project, supported by a junior designer. I defined the overall structure and interaction model, translated complex blockchain concepts into understandable UI, set and maintained the visual quality bar, and decided what to simplify and what to surface explicitly.

This project was also one of the first major product areas to use Sygnum's new design system. It had to prove the system could handle real complexity, not just simple flows. That dual responsibility — shipping the right product and validating the system under pressure — shaped every decision.

The hardest part wasn't the design. It was discovering, one system at a time, that the underlying platforms weren't connected in the ways the project assumed. We'd design a view of a client's full asset picture and an engineering team would come back and say the NFT platform couldn't surface that data, or that trading didn't connect with the portfolio service. The brief said "show clients their holdings." The reality was a set of siloed systems that had been built independently.

My response was to design in phases. Rather than one dashboard that reflected the full picture, we stepped the work out into stages, each tied to a specific technical dependency that needed to be resolved first. That's a different kind of design problem. You're not designing for a state that exists, you're designing a path to a state that doesn't yet.

Rather than designing individual screens, I focused on establishing a clear mental model for how Sygnum presents digital assets. That meant anchoring the experience in familiar banking concepts where possible, creating a single overview that reflected total holdings across asset types, and grouping assets and actions based on how clients think — not how systems are structured.

Common actions like trading and staking needed to be easy to find without turning the dashboard into a control panel. The challenge was simplifying without oversimplifying. Regulation made accuracy non-negotiable. Asset complexity — balances, fees, settlement timing, transaction states — couldn't be hidden, only structured.

The final dashboard gave clients a clear overview of what they held and its current value, supported crypto, tokenised assets, staking, and NFTs, and made common actions easy to find without intruding on the overview. It worked both as a quick check-in and a deeper exploration tool.

It also proved the design system could hold up under real complexity — which led to adoption across other teams.

Without detailed analytics, success came through qualitative signals. Clients could clearly understand their digital asset holdings. Feedback from account teams was consistently positive. Support requests related to balances decreased. Other teams adopted the design system after seeing it work in a complex context.

Most importantly, the product started to feel like a bank again.

What this project showed me is that a design system only proves itself under real complexity. The easy version is having components. The hard version is having components that hold up when things get genuinely complicated.

The most important decisions were often about what to leave out. As tools and AI make component creation faster, I think that's the part that matters more and more. The structural thinking, the "no, that's already handled by X" conversations. That's the work I enjoy most.

I left before the project was complete. I'd have liked to see it done.

In hindsight, the thing I'd change is the upfront process. The technical blockers we hit weren't unknowable. They were discoverable if all the teams had been in a room together early enough to map their dependencies. Instead we found them one by one as we tried to build. If I was doing it again, I'd insist on that session before a pixel was designed.