Tshwanelo Modise, Product Designer
{{ lightboxCaption }}
{{ lightboxCaption }}
 Click anywhere or press Esc to close
Tshwanelo Modise Product designer · Dubai Get in touch

Product designer with 10+ years in fintech, telecoms, and digital marketplaces.

I've partnered with organisations across Sub-Saharan Africa, West Africa, and the Middle East to design products that balance user needs, business strategy, and measurable outcomes.


What I do
01 Frame

Define the problem

Interview stakeholders Map the current journey Agree how success is measured
02 Research

Test it against reality

Talk to real customers Audit the product and its rivals Synthesise what it means
03 Design

Design it and ship it

Set the architecture and flows Design on the client system Prototype, test, hand off
04 Lead

Build the team around it

Mentor the designers Defend decisions to executives Run the engagement
Projects
Companies & clients
Recognition
{{ r.year }}

{{ r.title }}

{{ r.body }}
Interests

Exploring how thoughtful experience design can make complex information more understandable, accessible and empowering.

{{ t }}
← All projects

Pay Monthly

Designing a trustworthy rental financing experience for one of the UAE's largest property marketplaces, in partnership with Keyper.

Role Product Design Lead
Timeline 16 weeks
Platform iOS • Android
Industry Proptech/Marketplace
hero image · 1440 × 1000
The business challenge

Helping renters split their yearly rent into monthly payments.

Property Finder partnered with Keyper to introduce Pay Monthly, a service enabling renters to spread annual rent into monthly instalments. The challenge was balancing trust, speed and compliance while keeping the application simple.
How it works 9:16 explainer
The design challenge

Three constraints, none of them optional.

Each one is reasonable on its own. Together they pull in different directions, and no amount of screen design makes any of them go away.

01

Trust

People are asked to hand over payslips, bank data and identity documents to a service they have just met.

Non-negotiable The data has to be collected.
02

Simplicity

The application should feel light, even though it gathers more than most rental journeys ever ask for.

Non-negotiable The volume cannot shrink much.
03

Compliance

Financial regulation sets what must be verified, in what order, and with what evidence.

Non-negotiable No step can be removed.
The reframe

If the steps cannot go, the work is making them feel like less.

That moved the target from the number of steps to the effort people perceive, which is a design problem rather than a regulatory one.

Product hypotheses

Before designing, the team needed to validate three assumptions.

H1

Users understand Pay Monthly before starting an application.

H2

Income verification becomes the primary trust barrier.

H3

Reducing perceived effort matters more than removing mandatory steps.

Design decisions

Four decisions, and what each one cost.

DecisionWhyWhat it cost
01 Explain income verification before asking anyone to verify. People hesitate when financial information is requested without a reason. A slightly longer onboarding.
02 Reduce perceived effort rather than removing compliance steps. The regulatory requirements are fixed. The feeling of length is not. More progress indicators to build and maintain.
03 Break the application into manageable sections. Fewer decisions per screen, less to hold in mind at once. One additional transition.
04 Keep the property in view throughout the journey. People need reassurance they are still moving towards a home, not filling in a form. Extra informational UI on every step.
Service design

Three parties, one journey the renter should never have to think about.

Pay Monthly is not one product. It is Property Finder, Keyper and a bank connection, each owning part of a journey the renter experiences as a single application. Blueprinting it end to end showed where the handovers sit, and where uncertainty peaks.

Service blueprint Low Rising Peak Scroll →
01 Discover
02 Decide
03 Apply
04 Verify
05 Commit
Uncertainty Relative, from research synthesis
Low
Rising
Rising
Peak
Rising
Renter does
Browses rentals and sees a monthly figure beside the annual rent.
Enters income to see what they can afford.
Starts a three-step application.
Connects a bank account, or uploads statements.
Reviews the schedule, signs, and pays the first instalment.
Touchpoint
Search results · listing card
Eligibility sheet
Application intro
Proof of income · bank connect
Plan · agreement · card
Line of interaction
Property Finder
Flags eligible listings and shows the monthly equivalent.
Passes rent and income to Keyper.
Hands the applicant to Keyper as the regulated provider.
Keeps the listing and agent relationship intact.
Keyper
Returns an affordability range.
Owns the application and the regulatory obligations.
Assesses income. Uploads go to a human reviewer.
Issues the agreement, holds the mandate, pays the landlord annually.
Line of internal interaction
Bank connection
Read-only, one-time access under ADGM regulation.
Processes the card payment.
Design response
Put the option where people already look, not on a page nobody visits.
Answer eligibility before the application, so nobody applies to find out.
Name the partner and the time each step takes.
State the access model and the regulator before asking for anything.
Show all twelve instalments and both payments before signing.
What the map told us

Uncertainty did not build steadily. It spiked at one handover.

Every stage before verification was a decision the renter controlled. Verification was the first moment they had to trust someone else with something that mattered, and it sat exactly where the service passes from a marketplace they know to a provider they do not. That is where the design effort went.

The final experience

What shipped.

No compliance step was removed, because none of them could be. What changed is how much effort the application appears to ask for, and how much of it the applicant can see coming.

01 Set expectations before asking Income verification is explained before it is requested, so the ask arrives with a reason attached.
02 Disclose progressively Each section asks for one thing at a time. The full requirement is never presented at once.
03 Keep the property in view The application stays attached to the home being secured, so effort has something to be for.
04 Show progress throughout Where they are, what is done, and what is left, on every screen.
Final designs

The journey, screen by screen.

Nine screens, from finding a property to an activated tenancy.

01 Search for a property
02 View property details
03 Check eligibility
04 Start your application
05 Verify your income
06 Review your payment plan
07 Sign agreement
08 Make first payment
09 Tenancy activated
Validation

Did we solve the right problem?

We set out to remove uncertainty, build trust, and make a regulated financial application feel simple to complete. Rather than asking whether people could finish the prototype, the study tested whether those assumptions held.

The bottom line

The research validated the overall product strategy, shifting the focus from redesigning the experience to optimising specific moments of friction.

Strategic assumptions and validation
AssumptionOutcomeEvidence
Users understand the Pay Monthly proposition before committing to an application. Validated 11 of 15 understood the proposition well or very well.
Users can complete the journey without losing their sense of direction. Validated 14 of 15 always knew what to do next.
The application feels lightweight despite regulatory requirements. Validated 12 of 15 rated it easy or very easy to complete.
Existing trust signals are enough for users to provide financial information. Validated 13 of 15 felt confident providing personal and financial information.
Income verification is the largest remaining source of uncertainty. Partly validated The most common point of hesitation and request for clarification.
Evidence at a glance
15 Participants A mix of nationalities and ages, 20 to 50.
14 / 15 Always knew the next step Directional clarity held across the journey.
12 / 15 Rated the journey easy or very easy The experience felt manageable and light.
13 / 15 Felt confident sharing personal information Trust signals and messaging worked.
Confidence against effort
11 High confidence
Low effort
2 High confidence
High effort
1 Low confidence
Low effort
1 Low confidence
High effort
Low effortHigh effort
11 / 15 participants landed in the ideal quadrant: high confidence, low perceived effort. Which suggests the experience balanced clarity, trust and ease rather than trading one for another.
Key takeaway

We solved the right problem.

The core experience works. Participants understood how Pay Monthly works, felt guided, and trusted the process. The remaining opportunity is a single moment rather than the model itself.

What is next Optimise income verification to raise confidence further and reduce drop-off.
← All projects
{{ active.num }}
{{ active.client }}·{{ active.sector }}·{{ active.year }}

{{ active.title }}

{{ active.subtitle }}
{{ active.slot }} · 2520 × 1080
{{ n_overview }} Overview

{{ active.overview }}

My contribution
{{ con }}
{{ figPhases }} How the work ran, start to handoff
Phase Key activities Delivered
{{ ph.n }}
{{ ph.name }}
·{{ it }}
{{ ph.out }}
{{ n_context }} Context

{{ active.contextTitle }}

{{ active.context }}

The five questions we could not answer
? {{ q }}

{{ active.context }}
{{ figStakeholders }} {{ stakeTitle }}
{{ stakeInitiator }}
{{ stakeHub }}
{{ sp }}
{{ stakeNote }}
{{ n_problem }} The problem

The business problem

{{ active.bizProblem }}

The user problem

{{ active.userProblem }}

{{ figTensions }} {{ tensionTitle }}
{{ tn.t }} {{ tn.d }}
{{ tensionCallout }}
“{{ active.pullQuote }}”
{{ active.pullSource }}
{{ n_research }} Research

How we stopped guessing

{{ active.research }}

Designed for {{ pe }}
{{ figEmpathy }} What clients said, thought, did and feltOpen full size ↗
{{ figEmpathy }} What clients said, thought, did and felt
{{ q.label }}
{{ n.text }}
{{ figBench }} How we compared to the tools clients already use
Capability {{ bc.name }}
{{ br.f }} {{ bcell.glyph }} {{ bcell.t }}
● Present◐ Partial○ Absent
{{ figBench }} How we compared to the tools clients already useOpen full size ↗
Seven capabilities against HSBCnet and Mashreq NeoBiz. The pattern was hard to miss: we held our own on export and reporting, and lost on everything that let a client answer their own question.
{{ n_insights }} What we learned
{{ i.n }}

{{ i.title }}

{{ i.body }}
{{ n_principles }} The rules we set

The rules we agreed before drawing anything, so that when we later disagreed we could settle it on the principle rather than on who was most senior.

{{ p.n }}

{{ p.title }}

{{ p.body }}
{{ n_exploration }} What we tried

Three directions, one task

{{ active.exploration }}

{{ figBoard }} The three directions we testedOpen full size ↗
{{ dl.key }} {{ dl.label }} {{ dl.verdict }}
Direction A
Rejected
Direction B
Partially adopted
Direction C
Shipped
{{ n_decisions }} What we decided
#Decision{{ decisionHead }}
{{ d.n }} {{ d.what }}
{{ d.why }} Cost{{ d.tradeoff }}
{{ d.tradeoff }}
{{ n_solution }} The solution

{{ active.solutionTitle }}

{{ active.solution }}

{{ figCycle }} {{ cycleTitle }}
{{ ct.t }}
{{ cb.t }}
{{ cycleLoop }}
{{ cycleNote }}
{{ figChain }} {{ chainTitle }}
{{ ch.t }}
{{ chainNote }}
{{ figLifecycle }} {{ lifeTitle }}
{{ lc.n }} {{ lc.name }} {{ lc.note }}
{{ lifeNote }}
{{ figApproval }} {{ approvalTitle }}
{{ ap.t }}
{{ approvalGate }}
Yes {{ approvalYes }} {{ approvalYesNote }}
No {{ approvalNo }} {{ approvalNoNote }}
{{ approvalNote }}
{{ figBlueprint }} Service blueprint: what the client sees, and what it takesOpen full size ↗
Five stages, five lanes. This was the thing that finally got payments engineering, operations and compliance arguing about the same problem at the same time, and where the gaps in the correspondent chain stopped being an oversight and became a decision.
{{ n_designs }} Final designs

{{ designsTitle }}

{{ ls.name }}. {{ ls.caption }}

{{ phonesTitle }}

{{ phonesNote }}
{{ ph.n }} {{ ph.name }} {{ ph.caption }}

{{ screensTitle }}

{{ screensNote }}
{{ scr.caption }}
{{ active.slot }}
{{ slotCaption }}
{{ n_reflection }} Looking back

What changed

{{ active.outcome }}

What I would do differently

{{ active.lesson }}
Experience
Download CVPDF ↓
{{ r.dates }} {{ r.span }}

{{ r.title }}

{{ r.org }} {{ r.type }}
{{ r.place }}
{{ r.clients }}
{{ aw }}
{{ p }}