01 · Case study
Swift is building the shared language for tokenised assets. As lead and only designer, I was brought in while the brief was still forming.
The situation
Tokenised assets are new, and the industry has responded the way industries do: by producing several partial answers at once. Different chains, proprietary protocols, competing taxonomies, isolated settlement systems. Individually reasonable. Collectively, a market that can't talk to itself — and where liquidity gets stuck in whichever corner it was issued in.
Which makes standardisation the obvious move, and raises a less obvious question: who gets to write the standard?
Swift is owned by the banks it serves rather than by shareholders. It isn't competing with its members, and it already does this job for conventional financial messaging — it's the body the industry trusts to define how things are described. That's an unusual position, and it's why a standard proposed from there can be adopted without anyone looking for the commercial motive behind it.
So: a platform where standards for digital instruments are defined, published and consulted. Built to reuse what already exists rather than replace it — existing financial instrument standards, existing chain-level conventions — and compliant with regulatory frameworks by design.
The idea was the easy part.
The challenge
Everyone agreed on the goal at a high level. Nobody could describe what the thing actually was — what it should do, what it should look like, what someone would open it to accomplish on a Tuesday afternoon. The brief moved as we worked.
Two constraints made that harder.
No product to look at. Tokenisation is new enough that there was no incumbent to study, no competitor to benchmark, no legacy system whose failures we could catalogue. When there's no existing solution, there's also no existing behaviour to observe.
No access to end users. We spoke to the industry — market infrastructures, financial infrastructures, custodians — but those conversations were with strategic decision-makers, largely at C-level. Valuable for understanding where the industry saw the opportunity. Not a substitute for sitting next to the person who will use the platform every day.
I want to be straightforward about that second one, because it shaped everything — and because it put me in front of a problem a lot of designers are actually confronted with: I designed this without interviewing a single end user.
The rest of this page is how I worked around it.
Approach
If you can't interview users, the next best thing is to make the team's assumptions about them explicit — and then argue about them in a room, together, until they're specific enough to design against.
I ran design thinking sessions with the people who knew the domain best: the technical product owner, the product manager, developers, business analysts. We built the personas out of what they collectively knew, then pressure-tested them against what the industry players had told us.
Two sides of the platform emerged.
Persona 01
A digital asset and tokenisation specialist, defining a new instrument. Her problem isn't drawing it up — it's proving it's compliant, and making it something the rest of the industry will actually adopt. She should be able to build on standards that already exist rather than starting from a blank page every time.
Persona 02
Someone at a financial institution who needs to understand a published instrument — the rules attached to it, the specific usage guidelines, what they can and can't do with it. They arrive with a question and need an answer they can trust.
Those two need very different things from the same product. Naming that split early was the first moment the platform stopped being an abstraction.
Method
Stop asking stakeholders what they want. Instead, show them something to react to.
Three months of discovery taught me something I'd half-known: when stakeholders can't articulate what they want, more questions don't help. They produce more high-level agreement, which is the thing you already have too much of.
What breaks the deadlock is something to point at.
I started prototyping early — earlier than felt comfortable, at a stage where the concept was still moving. Not to propose an answer, but to give the room a concrete object to disagree with. A prototype makes vagueness visible. "That's not quite it" is a far more useful sentence than "yes, roughly."
Around that, a weekly design critique. Same people, same slot, every week: technical product owner, product manager, developers, business analysts. Each session, something new to look at.
That rhythm did the alignment work. Not workshops about strategy — a repeated, low-ceremony habit of looking at the same screen together and saying what was wrong with it. Over the weeks the disagreements got smaller and more specific, which is what alignment actually looks like from the inside.
The critique wasn't a design ritual. It was the mechanism that turned a concept nobody could describe into something a team could build.
The work
As the only designer, I owned the full arc:
The platform is still under construction and some detail is confidential. What's shown here is deliberately partial.
Outcome
The platform was demonstrated at Sibos 2025 in Frankfurt, Swift's annual industry gathering, with a proof of concept that put a tokenised eurobond on a public testnet. The full working product will be launched at Sibos in September 2026.
Swift made two announcements at Sibos 2025. The louder one was a blockchain-based shared ledger. Ledger Insights argued the quieter one — the standards work — "could prove bigger than its blockchain launch", on the grounds that fragmentation, not infrastructure, is what's actually holding institutional adoption back.
"Could prove bigger than its blockchain launch."
I'd still rather be honest about what that does and doesn't prove. It isn't live. There are no adoption figures, no time-saved numbers, nothing I can point to as measured impact. Attention at a conference is not a result.
What's still open
Onboarding is the honest weak point. This is a new category, and a first-time user arriving at the platform has a great deal to absorb before anything makes sense — even though the UX has been carefully designed to make the product as self-explanatory as possible. Helping someone who gets lost mid-task — orienting them without a manual — isn't solved. It's the part I'd want to work on next — alongside testing with real users, to validate the assumptions we made building the tool.
Reflection
Ambiguity is a design problem, not an obstacle to design. The brief being unfinished wasn't something to wait out. Making it finishable was the job.
Prototype before you're ready. A prototype's first purpose isn't to be right. It's to give people something specific enough to argue with.
Say what you didn't do. I didn't talk to end users on this project. Knowing precisely what that costs — and which methods partially cover for it — is more useful than pretending the gap wasn't there.