ClayStack's Liquid Staking
Breaking Staking's Shackles.
ClayStack was the first product I ever designed—and I touched everything. The UX, the brand, the visuals. It was a solo ride through a world I barely understood at the time: Web3. I was bombarded with terms like slashing, rebalancing, and yield strategies—most of which made zero sense back then.
But instead of backing off, I dove in. ClayStack was where I learned to swim.
This wasn’t just a design exercise. It was about translating something deeply technical into an experience anyone could understand and trust. And that meant making bold choices—like a clean, stripped-back interface that felt more like a simple token swap than a staking dashboard. Intuitive, fast, no clutter.
The Product
ClayStack was a liquid staking protocol that let crypto-native users stake ETH or MATIC across multiple chains and get a liquid token (csETH or csMATIC) in return. These tokens could then be used in other DeFi protocols to earn even more rewards.
It sounds simple, but nothing about it was. Every piece had to be invented. Every assumption tested. And the experience had to make sense from the very first click.
The Challenge
Liquid staking was new. We weren’t just building a product—we were helping shape the mental model for how this entire category could work. And that came with its own set of challenges:
Explaining liquid staking: Users needed to understand they’d get a token back—and that token could be used elsewhere to earn more.
Multi-chain interactions: Stake on one network, mint on another. No product had solved this well back then.
Real-time reward visibility: Show users their rewards were growing—even when the value was constantly changing.
Instant withdrawals: Not possible by default. So we created our own liquidity pool system and abstracted it into a single toggle.
Error handling: The UI didn’t scream when users did something wrong. It nudged them gently back on track.
All of this had to feel easy—even though nothing behind the scenes was.
Designing Without a Map
There were no patterns to copy. No Mobbin shots to study. ClayStack was one of the first protocols to enter the liquid staking space. So everything—from flows to interface to education—had to be imagined from scratch.
I started with questions:
“If I were staking for the first time, what would I want to know? What would make me feel confident?”
That mindset became my compass.
User Stories
To start, I mapped out the entire journey from a user’s perspective. I broke it into clear stories: Stake an asset, Withdraw, Claim rewards. For each action, I detailed every step, every possible path, and every edge case—including what could go wrong. These user stories became the foundation of the product.
They helped us:
Identify and prioritize critical flows.
Design for both ideal and fail states (like wallet connection failures).
Communicate clearly with engineering about frontend behavior.
Build with empathy—considering beginners and advanced users alike.
This wasn’t about designing screens. It was about shaping the experience. Every step in the journey—from selecting a token to receiving staking rewards—was intentional, intuitive, and explained.
Version 1: Raw and Functional
The first version was honest. Functional. It exposed every step to the user—selecting an asset, approving tokens, staking, and receiving csTokens. It worked. But it was clunky.
There were too many prompts. Too many MetaMask pop-ups. And it assumed users already understood how staking worked—when most didn’t.
Still, it gave us a baseline. We had something to test. And more importantly, something to improve.
Version 2: One-Click Simplicity
We stripped everything down.
We removed the mint step, eliminated approval friction, and wrapped the entire stake flow into a single, clean action. One click. That was it.
User Testing On Maze
In closed tests, it looked like a win. Users reached their goals quickly. Maze reports showed high success rates. The flow felt seamless—like we had finally nailed it.
User Interview
That changed when I sat next to real users.
I ran moderated usability tests in a closed environment—real people, real devices, real interactions. I didn’t explain anything upfront. I just asked them to try staking. I wanted raw reactions.
To guide the session, I created a UX-specific questionnaire tailored to uncover friction without steering behavior. It was built to observe, not interfere—no nudges, no hints. Just watch, listen, and note where confusion crept in.
That’s when the truth surfaced: people were confused. The simplicity masked too much. They didn’t understand what was happening—or why. We had optimized the interaction, but lost the context.
And that’s when it clicked:
"good UX isn’t just about speed. It’s about clarity, trust, and control."
Version 3: Swap Mental Model
I redesigned again—this time around a token swap mental model.
One token goes in, another comes out. Rewards grow. You stay in control.
Every decision, every animation, every tooltip was crafted to keep users in the loop—even when the blockchain took time to respond.
Rewards That Made Sense
Tracking rewards in DeFi is rarely straightforward. Especially when:
Token values fluctuate constantly (ETH goes up, then down)
Rewards are accrued passively
Users have no idea what “rebasing” means
We knew this was a core part of the experience—users needed to see that staking was working. But in Web3, you can’t just say “you earned 10 ETH this month.” That number is always changing.
The Solution: Show Value Growth
Instead of showing arbitrary APYs, we compared csETH to ETH:
If csETH = 1.02 ETH, your rewards were growing.
We also showed csETH’s market price moving over time.
This combination gave users a clear sense of earning—even if they didn’t fully understand the mechanics.
We also built a reward calculator to help users simulate how much they could earn over time. It was a simple UI tool, but it made a huge impact in setting expectations and building trust.
Withdrawals, Reimagined
Instant withdrawals were never meant to be possible. The default flow? You had to unstake and wait for the protocol to cycle through epochs and unlock the funds—which could take days.
That was never going to fly.
The Hack: Abstracting Complexity
We got creative. I worked with the engineering team to:
Create a withdrawal pool that siphoned a portion of incoming deposits
Route these funds to users who wanted to exit instantly
Mask all of that behind a single “Instant Withdraw” toggle
The UI didn’t overwhelm users with options. Just a switch. Behind the scenes? Pure magic.
Multi-Chain, Without the Headaches
We supported both ETH and Polygon. And MATIC staking got tricky.
Gas fees on ETH were painful, especially for smaller users. So we launched MATIC staking on Polygon, but staked it on Ethereum.
Here’s what that meant:
Users deposited MATIC on Polygon
We bridged it to ETH and staked it on their behalf
Everything was abstracted. The user didn’t know or care.
And when network switching wasn’t automatic (back then, MetaMask didn’t support it seamlessly), we didn’t break flows or throw errors. Instead, we:
Nudged users with a gentle prompt
Made switching easy, without ever screaming at them
Making It Foolproof
Errors in Web3 are expensive. You can lose gas, send tokens to the wrong place, or get stuck mid-transaction. So I designed every edge case to feel safe and fixable.
Instead of showing scary error banners:
We nudged users gently
Pre-checked for issues (wrong network, no balance, etc.)
Kept them inside the flow
Even when the network took time to confirm a transaction, the UI made sure users knew what was happening. No spinning loaders with no context. Always feedback, always in the loop.
Collaboration That Mattered
Though I was the sole designer, I never designed in isolation. I worked closely with the CEO, CTO, and engineering team, iterating fast, testing often.
Ran usability tests with our team
Sometimes even tested flows with my mom to see if they were intuitive
Used Maze to get broader feedback from actual users
We spoke to our community, ran Discord polls, and constantly asked:
“What’s confusing? What’s getting in the way?”
Some flows were designed off specs, others emerged from direct user interviews. It was always a mix of listening, translating, simplifying.
What I Learned: From Intimidated to Involved
ClayStack was more than just design work—it was design growth. I learned how to:
Break down complex systems into digestible flows.
Work directly with engineers to make sure every detail translated.
Build a brand system that felt trustworthy and open.
Write microcopy that was calm, simple, and clear.
I also learned to lead—even when no one asked me to. I owned the process, set the tone, and became the bridge between product, engineering, and users.
Reflections
Everything Starts Somewhere
Looking back, ClayStack wasn’t just my first project. It was my first real test. It taught me to listen more, assume less, and always design with empathy.
The product didn’t just get built. It shipped. It was used. It helped people stake their tokens in ways they hadn’t before. And even though it was my first project, I knew it wouldn’t be my last.
There’s something magical about being dropped into the deep end. Because that’s where you learn to float, swim—and eventually, surf. I stayed with ClayStack from its inception to the day it came to an end. Three years of building, learning, and growing—through every high and low.