Designing trust in a system that cannot move fast
Realize was a consumer platform for investing in tokenized real-world assets, starting with U.S. T-Bills. It looked like DeFi, but operated like a regulated fund. Money moved slowly: compliance checks, manual approvals, off-chain settlement. Actions took days or weeks.
The real challenge wasn’t UI polish. It was this: how do you make a slow system feel trustworthy instead of broken?
My role: I led all user-facing product experience, owning product behavior end to end and working closely with engineering, legal, and fund management. Because we were operating on a tight timeline, we partnered with Wegrow to define the brand and establish the initial UI foundation. In parallel, I managed and collaborated closely with senior freelance product designer Batuhan Karasakal, aligning flows, refining interaction details, and ensuring the system held together across dozens of states. There were multiple moving parts, and my role was to keep them coherent.
At its core, my responsibility was to translate a legally complex, process-heavy fund structure into something people could understand without reading a rulebook.
When DeFi expectations meet regulated finance
Realize lived between two mental models. Crypto users expect instant feedback and direct control. Regulated finance builds trust through verification, process, and time. We could not fake speed, remove approvals, or redesign how funds legally operate. Those constraints were structural.
The problem was not performance. It was uncertainty.
The full investment journey could stretch across weeks. First you apply to the fund. Then KYC, approvals, coordination with the fund manager, settlement windows, custody confirmations. At several points, nothing visibly happens while work continues off-chain. From a user's perspective, that silence can create doubt and hesitation.
Before designing screens, I mapped the full investor journey end to end. That clarified what could be self-serve, what required manual handling, and where the system had to explicitly say: you're waiting, and here's why. The UI didn't remove complexity. It organized it.
Designing clarity in a slow system
Applying to the fund did not mean money was instantly deployed, but it did mean committing to a multi-step process. Users needed to understand where they stood at any moment and whether they were expected to act.
The entire product revolved around two persistent questions:
- What is the exact status of my investment?
- Is anything required from me right now?
The dashboard centered on state. Each application and investment showed its current position, pending steps, and the next action when one existed. If nothing was required, that was clearly communicated.
Email was part of the product system, not an afterthought. Every message reflected a real state change and reinforced what was happening behind the scenes.
The result was a flexible architecture capable of supporting different investment products with different timelines, while maintaining a calm and predictable experience. In a regulated environment, clarity is not decoration. It is the core value proposition.
Where it broke
From a product execution standpoint, it worked. The structure was compliant. The flows were solid. The experience matched the operational reality.
The weakness was go-to-market. Fund setup took longer than expected, with dependencies outside the product team. By the time operations were locked in, the RWA market had become crowded. We didn't establish a strong edge beyond being another compliant T-Bills product. Around launch, T-Bill APY dropped, reducing demand and making differentiation even more critical.
The bigger miss was validation. We didn't validate demand early enough. Without real investor conversations and commitments up front, we were making too many decisions on assumptions: what people would value, what would block them, how we would reach them, and what proof they would need to trust the product. A well-designed experience reduces friction. It doesn't create demand.
What I took forward
This project reinforced that clarity starts before UI. If you're not precise about who you're serving and why they care, you're optimizing blindly. Distribution and validation are product decisions, not marketing afterthoughts.
It also strengthened a skill I rely on today: designing inside hard constraints without pretending they don't exist. Some systems are slow. Some processes are legally fixed. The job isn't to disguise that. It's to make it understandable and controlled.
That balance of strategic clarity and interaction precision is what I bring to every product I build.
