A claim feature for real estate agents to display successful deals on their profile
I designed a feature that allows property agents on Bayut to claim and display past transactions on their public profile.
Dubai Transactions is a tool on Bayut.com where anyone can find the latest sale and rental property transactions in Dubai, all of which are sourced from Dubai Land Department (DLD).
Bayut's partners use Dubai Transactions to get up-to-date data that helps them advise clients on pricing strategies for selling, or making informed offers when buying.
Bayut introduced a feature that allows agents to claim transactions they’ve made in the past and display successful deals on their public profile. This initiative aims to:
Empower agents on Bayut by enhancing their portfolio and strengthening their credibility.
Enable and incentivise agents to earn TruPoints™ and climb up the TruBroker™ leaderboard.
As the key designer for this feature, I worked with a product manager on covering all aspects of the claim flow, from discovery to conversion.
The design deliverables could essentially be broken down into the following parts:
Discover the claim feature?
Upload my supporting documents and submit my claim?
Track the status of my claims?
View my successfully claimed transactions?
+ How would they look to my clients?
Learn that I can earn TruPoints™ from successful claims?
Get notified on my claim status updates?
To begin, I had to first flesh out the core flows of the claim process before touching on items that were contingent on them.
Upload documents and submit claim flow
Agent's claimed transactions list with claim statuses (Agent's POV)
Agent's past transactions list (Property seeker's POV)
Elements that trigger the claim feature
Feature onboarding for first-time visitors
TruPoints™ allocated for each transaction claimed
Claim status notification emails
Launch email
Operationally, the moderation team would need specific pieces of evidence to verify that a transaction truly belonged to an agent. This would require agents to upload different supporting documents depending on if they were claiming a Sale transaction or a Rental transaction.
The rest of the requirements are simple. Essentially, when an agent is claiming a transaction, they should:
Have clarity on which transaction they are claiming
Be aware of what documents they should upload
Be informed on where to track their claims
Figuring out how agents would track their claims was the next crucial thing. Would they do so on the Dubai Transactions page itself, on their profile, or on an entirely new page?
I initially explored putting the claim statuses on Dubai Transactions claim column itself, but it didn’t make too much sense for a few reasons:
🤯
😵💫
😕
I also explored adding a ‘Recently claimed’ section on Dubai Transactions under the transactions table, but didn’t go through with it because it wasn’t intuitive for users to find their past claims there.
After running a few quick internal tests, I learned that the 1️⃣ profile and the 2️⃣ top navbar were intuitively where people would go if they were to revisit an action they’ve done. This led me to eventually design a Transactions tab with claim statuses on the agent profile itself.
Now that we'd figured out where agents would track their claims, it was time to play around with how they would look like.
The quickest solution was to just reuse the same transactions table from Dubai Transactions on the agent profile, but it was looking lacklustre. It needed to feel less like an information directory and more like an achievement, a plaque of honor — a section that agents would be proud to look at.
This led me to explore a map thumbnail and larger cards. Out of the grid view and the list view that I explored, the list view ended up being approved because it was more scannable and readable.
The challenge with positioning the Claim button was primarily that there was very limited screen real estate on the transactions table. The button had to be noticeable but not jarring, subtle but not hidden.
We initially placed the Claim buttons upfront in a column, but after discussions on scalability, decided we needed to use less horizontal space.
We then tried placing the Claim button within an ellipsis menu to prevent cluttering the transactions table, but this made the feature too unnoticeable.
We eventually agreed on a "Claim mode" that hid the Claim buttons by default, and enabled the user to reveal the Claim column on prompt.
Since the Claim buttons were to be hidden by default, it was important for us to create prominent entry points that draw attention to this feature.
This lead to us creating an onboarding flow as well as a new launch banner on top of a regular Claim CTA above the transactions table.
By using primary button styles for the Claim buttons and hiding other action items when Claim mode is active, we also created a more focused use of the feature by reducing distracting elements on the screen.
As standard practice, agents are to be alerted when their claims have been submitted, approved, rejected, or resubmitted. I designed the confirmation emails covering these four statuses, and assisted in developing them.
For the onboarding flow, I had to create 4 SVG assets for 4 different languages — English, Arabic, Mandarin, and Russian. That in itself wasn't the difficult part. It was the pedantic changes I had to make on each one of them after each round of review.
I learned the hard way that abstract graphics are the best way to keep things scalable, and save yourself from trouble.
We often have little control over how many lines of text a certain copy would take up in different languages. For example, in this onboarding modal, Mandarin descriptions consistently take up a single line while Russian consistenty takes up two.
I had to think about a way to make sure that there are no vertical jumps on the responsive modal for each language — either by making sure each language featured either 1 line or 2 lines of copy consistently, or designing the modal in a way that accommodates a mix of both.