BabyDoge Web3 Ecosystem
End-to-end design of a crypto real estate MVP, building a unified 150+ screen product for mobile and desktop from the ground up — including the property catalog, apartment listings, filters, booking, payment, and the user account.
My role
Timeline
Product Designer, Design Team
Sep 2024 — May 2025
Product
Crypto, Web3, Website
I adapted the BabyDoge design system for the product: created the UI kit, light and dark themes, and component sets for cards, lists, filters, and payment steps. Visual materials, including graphics and promo blocks, were partially generated using AI tools — accelerating iterations and keeping ecosystem consistency.
Design System
The platform had to support several payment scenarios: Reservation Fee, Downpayment, and an alternative provider-specific method.
Each scenario included its own legal requirements, commissions, confirmation steps, and provider-side constraints.
In addition, the flow had to handle dozens of token and network combinations (USDT, USDC, BTC, ETH on BSC, TRC20, Polygon, etc.). This required early validation, filtering, and disabling unsupported options.
Each scenario included its own legal requirements, commissions, confirmation steps, and provider-side constraints.
In addition, the flow had to handle dozens of token and network combinations (USDT, USDC, BTC, ETH on BSC, TRC20, Polygon, etc.). This required early validation, filtering, and disabling unsupported options.
Requirements
The platform was part of the BabyDoge Crypto Web3 ecosystem.
The goal was to create a transparent real-estate purchasing flow using cryptocurrency: from selecting a property and booking to payment, legal steps and contract finalization. We designed the product specifically for the UAE real-estate market — combining local user patterns, developer requirements, and the brand style.
The goal was to create a transparent real-estate purchasing flow using cryptocurrency: from selecting a property and booking to payment, legal steps and contract finalization. We designed the product specifically for the UAE real-estate market — combining local user patterns, developer requirements, and the brand style.
Context
Result
We built an end-to-end platform that enables users to complete the entire real-estate purchase journey with cryptocurrency — from browsing and selecting a unit to payment and contract finalization.
The linear structure, early validation, and unified UX made the flow predictable and easy to follow. The final payment flow was approximately 15% faster than earlier iterations.
The completed MVP was presented at an industry exhibition in Dubai in 2025 as part of the BD Web3 ecosystem showcase.
The linear structure, early validation, and unified UX made the flow predictable and easy to follow. The final payment flow was approximately 15% faster than earlier iterations.
The completed MVP was presented at an industry exhibition in Dubai in 2025 as part of the BD Web3 ecosystem showcase.
Documentation & Handoff
UX documentation included interactive prototypes, a user-journey map, payment-flow diagrams, provider requirement tables, and UX specs for development and QA.
The project was developed over six months until the first MVP.
The project was developed over six months until the first MVP.
Multi-platform
We adopted a mobile-first approach together with the design lead to ensure a clean, scalable UX foundation.
The flow was then scaled to desktop with identical logic, step order, and state structure.
The flow was then scaled to desktop with identical logic, step order, and state structure.
Testing & Validation
We validated each iteration of the payment flows internally together with QA and the product team. These walkthroughs helped reveal unclear steps, dead-end paths, and mismatches between provider requirements and the UI.
We tested all payment scenarios end-to-end — including provider limits, supported networks, token combinations, legal-confirmation steps, and error states. Based on QA reports and team feedback, the final version became noticeably clearer and more stable, with fewer questions from the team and fewer places where users could get stuck.
We tested all payment scenarios end-to-end — including provider limits, supported networks, token combinations, legal-confirmation steps, and error states. Based on QA reports and team feedback, the final version became noticeably clearer and more stable, with fewer questions from the team and fewer places where users could get stuck.
Payment Flow
Payment flows were the most complex part. Requirements varied across three providers, so each interface had to be adapted while maintaining a shared UX framework.
During internal reviews and prototype testing, we repeatedly ran into a common industry issue: identically named tokens across different networks (e.g., USDT on TRC20, BEP20, Polygon) made it easy to misinterpret the available options. To prevent this in the final product, we added clear network differentiation, early disabling of unsupported options, and transparent fee hints. Based on our internal testing, the final payment flow became roughly 15% faster and easier to navigate than earlier iterations — measured by completion time and the number of clarification questions inside the team.
During internal reviews and prototype testing, we repeatedly ran into a common industry issue: identically named tokens across different networks (e.g., USDT on TRC20, BEP20, Polygon) made it easy to misinterpret the available options. To prevent this in the final product, we added clear network differentiation, early disabling of unsupported options, and transparent fee hints. Based on our internal testing, the final payment flow became roughly 15% faster and easier to navigate than earlier iterations — measured by completion time and the number of clarification questions inside the team.
Early Prototypes
I built the core site structure — project pages, apartment listings, filters, gallery, catalog, and navigation. We iterated several times until the flow became linear and predictable, especially around the payment scenarios.
Research
I began with an analysis of the UAE real-estate market: reviewing 10+ developer websites (DAMAC, Emaar, etc.) to understand catalog structures, project pages, apartment listings, filters, and booking UX. In parallel, we studied best practices of Web3 payments.
Within the team, we analyzed legal workflows, developer requirements, provider limits, and commission disclosure rules. This allowed us to build a correct user journey with all technical and legal constraints.
Within the team, we analyzed legal workflows, developer requirements, provider limits, and commission disclosure rules. This allowed us to build a correct user journey with all technical and legal constraints.
My Role
As the Product Designer, I was responsible for the full UX/UI of the product. I worked closely with the CPO, project managers, design lead, developers, and QA — aligning decisions through product calls, critiques, and design reviews.
I defined the site structure, designed the core flows, created prototypes, and prepared UX documentation for development. I also adapted and extended the shared design system to keep visual and structural consistency across the BD ecosystem. All screens were organized as master pages to maintain a unified UX core across desktop and mobile.
I defined the site structure, designed the core flows, created prototypes, and prepared UX documentation for development. I also adapted and extended the shared design system to keep visual and structural consistency across the BD ecosystem. All screens were organized as master pages to maintain a unified UX core across desktop and mobile.
Business Objective
Build a linear, technically correct user journey: select a property → book → pay → complete legal steps.
The biggest challenge was payment flows: government fees, commissions, requirements from multiple providers, network limits, and legal constraints. The MVP needed to reduce manual work for managers and shorten the time between property selection and payment.
The biggest challenge was payment flows: government fees, commissions, requirements from multiple providers, network limits, and legal constraints. The MVP needed to reduce manual work for managers and shorten the time between property selection and payment.