We interviewed community admins and members, then validated concepts through early prototypes. These insights guided a single design principle:Make every step feel intentional & explainable.‍

Rather than building a broad feature set, we focused on three core experiences centered around token-gating—making deliberate trade-offs to reduce complexity and friction.

Admins needed flexibility without feeling overwhelmed. Design decisions: Progressive disclosure instead of dense configuration screens. Attention to interaction details: Contract address open text field, Easy-to-scan multi-token settings, Visual hierarchies to separate “required” vs “advanced” options.

This was the most trust-sensitive moment. Design focus:Familiar wallet connection patterns. Clear visual feedback for success, failure, and retry states. The goal was to make verification feel more like logging in than making a transaction.

Originally TON-only, Hubz expanded to support multiple chains based on direct user demand.From a design standpoint, multi-chain support became a credibility signal—showing users that Hubz was built for authentic web3 communities.

Alongside core flows, we explored additional engagement features: Token-gated drops, Community discovery, Admin analytics, DAO-style governance concepts. These were tested through lightweight prototypes to validate interest before deeper investment.

This project pushed me to design in an environment with high uncertainty and low user trust. If I were to revisit it, I would approach a few things differently: Ecosystem > Products: We can’t solve the problem if the real issue is the ecosystem - intentionally choose where to build on. Design a Clear Visual Trust System Earlier: We relied mainly on copy and familiar patterns to build trust. With more time, I’d introduce a more explicit visual trust system—such as verification states, security indicators, or branded reassurance moments—to reduce anxiety even further.

We interviewed community admins and members, then validated concepts through early prototypes. These insights guided a single design principle:Make every step feel intentional & explainable.‍

Rather than building a broad feature set, we focused on three core experiences centered around token-gating—making deliberate trade-offs to reduce complexity and friction.

Admins needed flexibility without feeling overwhelmed. Design decisions: Progressive disclosure instead of dense configuration screens. Attention to interaction details: Contract address open text field, Easy-to-scan multi-token settings, Visual hierarchies to separate “required” vs “advanced” options.

This was the most trust-sensitive moment. Design focus:Familiar wallet connection patterns. Clear visual feedback for success, failure, and retry states. The goal was to make verification feel more like logging in than making a transaction.

Originally TON-only, Hubz expanded to support multiple chains based on direct user demand.From a design standpoint, multi-chain support became a credibility signal—showing users that Hubz was built for authentic web3 communities.

Alongside core flows, we explored additional engagement features: Token-gated drops, Community discovery, Admin analytics, DAO-style governance concepts. These were tested through lightweight prototypes to validate interest before deeper investment.

This project pushed me to design in an environment with high uncertainty and low user trust. If I were to revisit it, I would approach a few things differently: Ecosystem > Products: We can’t solve the problem if the real issue is the ecosystem - intentionally choose where to build on. Design a Clear Visual Trust System Earlier: We relied mainly on copy and familiar patterns to build trust. With more time, I’d introduce a more explicit visual trust system—such as verification states, security indicators, or branded reassurance moments—to reduce anxiety even further.