Skip to content
Tajdid Rahman
Tajdid Rahman
Back to Work

Relay

Bringing clarity to property referrals

Role
Senior product designer
Focus
Research, Product design, Prototyping
Platform
Mobile-first web application
Year
2026
Three Relay screens on purple: the agent home, a referral that needs the agent’s help, and deals with estimated, payable and paid earnings.

Overview

A mobile-first concept exploring how property agents can refer clients, follow their progress and understand their earnings, all in one place.

The challenge
Referring a client often starts with a message to someone an agent trusts. What follows is less clear: who is looking after the client, how the deal is progressing and what commission to expect.
What I did
Three informal agent conversations and an audit of the existing experience, then three connected journeys around them: refer a client, follow progress and understand earnings.
The outcome
A working prototype with 15 scenarios in English and Arabic, and a design library shared between Figma and React, with six key screens brought back into Figma from the code.

Why use another platform when WhatsApp already works?

For many property agents, referring a client starts with a message to someone they trust. It is familiar, quick and requires very little effort.

But once that introduction happens, understanding who is looking after the client, how the deal is progressing and what commission to expect can become less straightforward.

I wanted to explore what a dedicated referral platform could offer beyond another way to submit someone’s details.

The opportunity was to make the entire referral experience more dependable.

  1. 01Introduction
  2. 02Handover
  3. 03Progress
  4. 04Earnings
The introduction is only the beginning of the referral experience.

Trust matters more than another feature

I started with three short, informal conversations with real estate agents in Dubai. I also audited the existing experience and reviewed publicly available referral, tracking, commission and reward experiences.

These conversations were exploratory. They helped identify assumptions worth investigating, rather than establishing what all agents need.

Existing relationships are difficult to replace

All three agents described internal specialists or established partners. Trust often came through an existing relationship or brokerage. A faster referral form alone would not necessarily give them a reason to change.

Follow-up preferences differ

One agent was comfortable handing everything to an in-house team. Another asked for updates daily or every few days. A third described limited visibility into progress.

The first agent expected to chase an external provider, but did not report doing so. That distinction matters: an expectation is different from observed behaviour.

Rather than assuming everyone wanted more notifications, I focused on making useful information available when it mattered.

Tracking exists, but clarity can improve

The audit showed that tracking was already part of referral products. The opportunity was not to invent it, but to explore clearer communication of the latest meaningful milestone, the person responsible and what happens next.

Evidence around earnings was more limited. One agent said a significantly higher commission might make an external provider worth considering. The other conversations did not substantively explore payment mechanics. I treated financial clarity as a design direction to test, not a universal finding.

From three agent conversations

  • Relationships

    All three described internal specialists or established partners. Trust often came through an existing relationship or brokerage.

  • Follow-up

    One was comfortable handing everything to an in-house team. Another asked for updates daily or every few days.

  • Visibility

    A third described limited visibility into progress.

From the product audit

Tracking was already part of referral products. The opportunity was clearer communication of the latest milestone, the person responsible and what happens next.

Three informal conversations informed the direction. They do not represent the wider agent population.

From submission to what happens next

I organised Relay around three connected questions.

  1. 01 · Refer

    Who is looking after my client?

    Make the handover clear, including responsibility and what happens next.

  2. 02 · Track

    What is happening with my referral?

    Communicate meaningful progress without making agents interpret every internal process.

  3. 03 · Earn

    What have I earned?

    Distinguish estimated earnings from payable or paid money, and pending points from points available to redeem.

These questions became three connected journeys: refer, track and earn.

Referral capture: the client’s needs, name and phone number.Progress tracking: the latest status and what the agent can do to help.Earnings split into estimated, payable and paid.
Three journeys shaped the concept: refer a client, follow progress and understand earnings.
  1. Introduction
  2. Handover
  3. Progress
  4. Earnings

Refer: a quicker handover

I wanted submitting a referral to feel almost as straightforward as sending a message.

The proposed flow prioritises the service, the client’s name, phone number and contact consent. Additional information can be collected later where appropriate.

Once submitted, the experience introduces the adviser and explains what happens next. I separated submission confirmation from adviser contact. Successfully submitting someone’s details does not mean they have already been contacted.

Collecting less information upfront reduces effort, but may create additional work for the adviser. The minimum information required would need to be validated with operations before implementation.

Refer a client form: service, client name, phone number, the assigned adviser and a contact consent checkbox.

  1. The service first

    Mortgage or Golden Visa, so the referral reaches the right person.

  2. Only what the handover needs

    The client’s name and phone number. Anything else can follow later.

  3. The adviser, up front

    Who will look after the client is shown before anything is sent.

  4. Contact consent

    The agent confirms their client agreed to be contacted.

Referral sent: the adviser now owns the referral and will update the agent once they have spoken to the client.

  1. Handover, not contact

    The confirmation names who now owns the referral and promises an update once they have actually spoken to the client.

Submission confirms the handover. It does not mean the adviser has already contacted the client.

<30s

Submission goal

A design target. Not a measured result.

The under-30-second submission goal is a design target. It is not a measured result.

  1. Introduction
  2. Handover
  3. Progress
  4. Earnings

Track: progress that means something

A referral can pass through several operational stages. Agents do not necessarily need to understand every internal process to know where things stand.

I explored a hierarchy that prioritises the latest meaningful milestone, the responsible adviser and the next step. Cases requiring agent action are distinguished from those already being handled.

I also designed exception states, including duplicate referrals and clients who could not be reached. These scenarios matter because the experience needs to communicate uncertainty as clearly as successful progress.

Implementation exposed a contradiction in one unreachable-client state. The status said that contact had failed, while the timeline suggested the adviser had spoken to the client. I corrected the wording and state in the prototype and the corresponding Figma screen.

That small correction changed the meaning of the experience. Visual consistency alone would not have caught it.

Referral detail for a client who could not be reached: the status, how the agent can help, the progress timeline and the named adviser.

  1. The latest milestone, in plain words

    One status at the top says where things stand.

  2. When the agent can help, that comes first

    Check the number, or let the client know to expect the call.

  3. The corrected timeline

    The adviser is still trying to reach the client. Nothing claims contact has happened.

  4. Who is responsible

    The adviser is named, with a way to message them.

Exception states should explain what is happening and who acts next.
  1. Introduction
  2. Handover
  3. Progress
  4. Earnings

Earn: making money and rewards understandable

An estimated commission is not money that is ready to be paid. Pending loyalty points are not necessarily available to redeem.

I explored a progression from estimated to payable to paid earnings, supported by explicit labels and visual treatments. I also brought rewards into the main experience so agents could understand available points, pending points and progress towards a reward.

The audit had surfaced rewards in a separate part of the existing experience. Bringing them closer to referral work was a proposed improvement in discoverability.

The hypothesis was that clearer earnings and rewards could make the platform more valuable to returning agents. Whether this would influence repeat behaviour remains unvalidated. The amounts, payout conditions and reward rules in the prototype are illustrative.

Deals overview with earnings split into estimated, payable and paid.

  1. Estimated

    Commission on deals still in progress. Not yet money.

  2. Payable

    Due, with the date it will be paid.

  3. Paid

    Money already received, deal by deal.

Rewards: available and pending points, points about to expire and progress towards the next reward.

  1. Available points

    What can be redeemed now.

  2. Pending points

    Earned on open deals, but not yet available.

  3. Points about to expire

    Called out with a way to use them.

Estimated earnings, payable money and available points communicate different things. Amounts and rules are illustrative.

Building a system across Figma and code

I wanted the prototype to feel like a connected product rather than a collection of individually designed screens.

I established a working design library in Figma, using AI to help recreate foundations and components from existing interface references. I then directed Claude Code to help translate those foundations into reusable React components and interactions.

For each screen, I inventoried existing components, mapped the design to reusable elements and identified gaps before implementing anything new.

Working in code revealed inconsistencies in interaction states and content. I brought those refinements back into Figma, eventually recreating six key screens from the implemented experience.

Building a shared language between design and code explores that workflow in detail.

Figma library board of core components: buttons, segmented control, tab bar and property card.The coded design system reference, showing the earnings stages component in English and Arabic states.
A working library connected the Figma designs and React prototype.

Making the prototype explorable

Relay includes different agent contexts, referral outcomes and exception states.

I built a custom viewer so reviewers could explore those situations without navigating every journey manually. It includes 15 scenarios, English and Arabic layouts, optional design notes and a reference for the underlying design system.

  • 15

    Scenarios to start from

  • EN · AR

    English and Arabic layouts

  • React 19
  • TypeScript
  • Tailwind 4
  • Vite

The prototype uses React 19, TypeScript, Tailwind 4 and Vite. Some handoffs and account actions are simulated or placeholders. Payment and reward fulfilment are outside the demonstrated scope.

Why I built my own prototype viewer explains the thinking behind the presentation layer.

The prototype viewer: language, design notes and scenario controls beside the Relay home screen in a phone frame.
The viewer makes 15 scenarios, language variants and design notes available for review.

What I would validate next

The biggest assumption remains unanswered: does this experience offer enough value for agents to choose it over an existing trusted contact?

  1. 01

    Referral effort

    Can agents submit a realistic referral without assistance? I would use an unseeded task to measure time, completion and errors, rather than treating a prefilled demonstration as evidence of speed.

  2. 02

    Understanding and confidence

    Can agents identify who is responsible, what happens next and whether they need to act? Can they explain estimated versus paid earnings and pending versus available points?

  3. 03

    Repeat behaviour

    Would agents return to submit more referrals? Usability sessions can explore comprehension and perceived value. Actual switching and repeat deal flow require a live pilot over service-appropriate periods.

Before production, I would also validate consent, minimum referral data, attribution, duplicate handling, commission rules, reward eligibility and Arabic localisation. Named ownership and timely updates depend on operational capability as well as interface design.

Designing for confidence

I started with a challenge around making referrals easier. The more I explored how agents worked, the more interested I became in what happened after the introduction.

Trust, responsibility and visibility became central to the experience.

Building the prototype helped me explore those ideas beyond static screens. Keeping Figma and code connected helped expose inconsistencies, while the viewer made the decisions easier to inspect.

The most valuable part of the project was reframing the problem: a better referral experience should give agents confidence in everything that follows the introduction.

Related work

All work