most property apps are a search box, hive is a room full of people.
Name & Industry
HIVE, real estate, social platform
/
/
Led the product design for a real estate community, live tours, threaded listing discussions, and agent tools on mobile, backed by a web moderation dashboard.
about hive.
Hive is a real estate platform built around community, not transactions. Buyers join live virtual tours with a real-time comment feed, react and discuss listings in threaded conversations, and message agents directly. Agents keep verified profiles and host the tours; a web-based admin moderates reported content and keeps the place safe.
I came into Hive with the wireframes and design direction already drawn by another studio. My job was to lead the product design from there. Pressure-test every flow, fix what was broken, and get the whole thing ready to be built by an AI pipeline. Three roles (buyer, agent, admin), two platforms (mobile for consumers, web for moderation), with a UI designer handling visual execution alongside me.
problem 1.0: (re)framing
I had handed over a full set of wireframes and a design language. The client wanted us to build from there. Before anyone touched a screen, I went through all of it asking four questions:
Did the wireframes covered flows without any missing touchpoints or part(s) of the flows?
Is there a room for improving, simplifying, better UX?
What's just wrong and needs fixing before UI starts?
Feasibility validation with tech team.
problem 1.1: design language
The general design direction had few issues too. We had to work on coloring. Primary color #FFCA27 was hard to work with primarily because of accessibility issues so I made decision to change it. The example screens they made were contained of custom components but that wasn't suitable for vibe coding practice. Icons had no source at all.
decisions came out of it.
A few flows were incomplete. I added the missing screens so nothing dead-ended.
The live tour couldn't be built as framed. With the tech team, we moved it onto a third-party video service Twillio instead of building it from scratch.
The primary color, a bright
#FFCA27, failed on accessibility and was hard to build around. I offered couple color palettes but client was fond of yellow, so we switched to bolder yellow.The screens leaned on custom components and a loose set of icons. Since the whole app was going to be vibe-coded, I re-founded it on Material 3 and Material Icons, and kept custom work to the bare minimum.
Then i took all of it back to the client in one meeting, walked through the reasoning, and got a yes on every change.
problem 2.0: design for the build, not just the screen.
Because this was the team's first vibe-coded product, the first job wasn't design. It was figuring out how design works when the build is prompt-driven.
a system first foundation.
The biggest upstream decision was the component system. I tested how different approaches held up through Claude Code and landed on Material 3.
a live tour that kept well known standards.
The live tour was the hardest part of the product, so I made a deliberate choice not to invent a new interaction language for it. People already know how to join and watch a live stream, so I built the experience around the social-media live format they use every day. For that task feasibility testing showed Twilio was the right answer.
what will success look like, once live.
The design is built to be measured. At launch, the things worth holding it to are live-tour join and completion rates, comment and reaction activity during tours, buyer-to-agent message rates, and how quickly the admin tools let moderators act on reports. Those are the slots where real numbers go in later.
Takeaway.
The real win wasn't a feature. It was proving that design doesn't have to slow down in an AI build pipeline. Handled right, it's the thing that keeps the velocity pointed at something people actually want to use.
