Product designer in Dubai.
Currently designing at botim business.
Two payment products became one request.
A clearer collection experience, built from merchant behaviour, transaction analysis and product simplification.
· 2026lending
Made the application understandable to merchants.
The lending journey redrawn across discovery, onboarding, document upload and support.
· 2026
Helped young people prove what they can do.
A network where students and recent graduates in the UAE gain experience, build relationships and show what they can do through practical projects.
Hi, I'm
Khansa.
I'm based in Dubai, studying Product Design and Strategic Design Management while working on projects across different industries.
I've never been good at keeping my interests in one place. Physics, maths, design, and whatever else catches my attention tend to overlap. I like asking why until I get to the root of something, then borrowing ideas from completely unrelated fields to see things differently.
That's what I love about design. It gives me a place to bring together how things work and how they could work differently.
How I work across product, research and strategy.
Let's make something people choose.
I'd love to hear what you're working on.
Looking for a product design / strategy / owner internship · Summer 2027.
Making business financing easier to discover, understand, and access.
Experience shouldn’t depend on who you know.
{{ heroLede }}
-
{{ r.n }}{{ r.k }}
{{ r.v }}
Figures rounded · some data confidential to botim
{{ ov.title }}
Too much effortto request payment.Too little clarityafter sending.
SME lending wasfragmented beforethe applicationeven began.
Your first opportunityshouldn’t requirea previous one.
{{ ov.method }}
{{ ov.body }}
{{ ov.statCap }}
{{ ov.stat2Cap }}
{{ s.v }}
{{ s.cap }}
I realised this was a system problem: the lending experience ran across six surfaces, and each one had a different owner.
The project therefore required product strategy, information architecture, UX and cross-functional alignment.
The real work turned out to be designing the whole lending system, not a better form.
Many young people already encountered development through clubs, projects, volunteering, student organisations, courses, personal initiatives and informal work.
The problem was that these experiences were fragmented, difficult to navigate, inconsistently recognised, and rarely translated into credible evidence. The research indicated a path problem as much as an opportunity problem.
Students were getting experience. It rarely led to an opportunity.
Four things the research told me that changed my original plan.
I went in thinking that better targeting and a shorter application would fix it.
The research showed I was wrong about both.
The application was only one part of the problem.
From deciding whom to approach to helping merchants recover from missing documents, the lending journey had friction well beyond the screens themselves.
A large target list wasn’t necessarily a qualified audience.
The form showed progress, but not what was missing.
Fewer screens didn’t mean less uncertainty.
The journey broke down when something went wrong.
{{ rf.from }}
{{ rf.toText }}
{{ rf.coda }}
Five stages. Five decisions.
My role was different at each stage, so each decision says exactly what I owned. Scroll to watch it work.
Fewer merchants. Stronger reasons to reach them.
A progress bar couldn’t tell merchants what was missing.
Repayment had to work beyond the screen.
A referral shouldn’t feel like starting over.
One conversation. Every document accounted for.
One journey, from offer to funds.
The redesigned application, the document thread and the recovery states, in one connected flow.
I built the journey with engineering and checked every step with credit and risk.
{{ cs.constraintsLead }}
Every simplification had a limit.
Select one to see what I chose.
One requirement, through the system.
An expired trade licence, from the rule that requires it to what the merchant sees and what shipped.
- 01 · RequirementA valid trade licenceNeeded before an offer can be made.
- 02 · Responsible ownerCredit, merchant, agentCredit and risk decide what counts as valid. The merchant renews and uploads. An agent records the document in the lending system.
- 03 · Merchant-facing state“Your trade licence has expired.”Next step: upload the renewed copy.Expired
- 04 · Recovery actionUpload, then resumeThe renewed copy goes into the approved BOTIM Business thread. The application resumes where the merchant left off.Accepted · resumed
- 05 · Release statusPartly live, partly proposedThe application states were built with engineering. Collecting documents in chat is a proposed pilot.Proposed pilot
What I delivered was a focused cohort and one connected lending journey.
We agreed who to target first and how we’d track the journey after launch.
Why did I get the offer and not everyone?
I analysed ~100,000 merchants and picked the ~10,000 ready to borrow first.
Will I actually hear about this loan?
I ran an eligibility-check campaign inside the app. ~10,000 merchants reached at launch, live 14 August, with AED 0 paid media.
Did more people actually apply?
10×+ weekly leads and ~4× submitted applications after launch.
Does it matter how I get in?
~60% of partner-referred applications reached submission, vs ~5% from in-app entry.
So where did people get stuck?
By 13 September, nearly 2,000 applications were created and about 300 submitted. About 3 in 4 of those sat in offer review, and ~2 in 3 applications never reached the first form step.
What happens next?
Stop pushing acquisition. Give the review queue an owner, retarget the banner to the strongest cohort, and follow up merchants stuck on uploads.
Met my lending manager every week to review progress and get feedback on my work.
I investigated why gaining meaningful experience remains difficult, even when learning resources, professional networks, and opportunities already exist.
How do we capture the learning school doesn’t measure?
Ambition was already there.
Students needed a path.
Trust turned out to be the real product problem.
The best MVP turned out to be the smallest question I could ask.
Three versions, each one narrowing the question.
“How could we redesign learning?”
Skills, community projects, credentials and a contribution economy, which was far too wide to test.
“How could a real contribution become portable proof?”
Verified records solved recognition, but assumed people already had the experience to record.
“How could people gain the experience their next opportunity requires?”
Evidence stays, as an input to the next experience rather than the end product.
{{ rf.from }}
A better profile only helps at the last step. It doesn’t help people find work, build skills or earn evidence.
How might we help peoplegain meaningful experiencebefore they areexpected to have it?
From presenting experience to creating it.
Four questions that shaped every decision.
Each one picks up where the last left off, from two interviews to 36,000 job postings.
Swipe sideways to read the map → Tap a tab to switch maps.
Four insights, and the six decisions that came from them.
Each decision answers something I learned in discovery. Scroll to watch it work.
Start with direction.
Instead of asking for a career, LifeMint starts with interests, goals, scenarios and emerging strengths.
Bridge interest and real responsibility.
Quests sit between curiosity and real work, so commitment can grow over time instead of being demanded on day one.
Turn real work into evidence.
Completing a Mission creates a structured record of the work.
Make trust inspectable.
Instead of asking people to trust a badge, LifeMint shows the evidence behind it.
I had to protect the MVP from the vision.
The first version keeps only what tests the core loop, and everything else waits.
Inherit and improve real work.
Let people inherit and improve real work, rather than always starting a new project. Their Mint Profile records exactly what they changed and whether the handover worked.
Every contribution shapes the next one.
Each step builds on the last.
Three groups, one network.
It starts with students and recent graduates in the UAE.
The agent drafts. People decide.
From a quest to a Mint someone can share.
Building trust meant making trade-offs.
Pick one to see where I landed.
What a verified Mint actually proves.
One existing example: a volunteer research Mission. A verification stamp should not imply more certainty than the system gives, so the record says what was checked and what was not.
Interviews with eight volunteers, coded transcripts and a drop-off memo, submitted as the Mission’s steps.
The Mission host reviews the work. Two collaborators vouch for the member’s part in it.
The host confirms the brief was delivered and records the outcome. Collaborators confirm who did what.
The brief, the work, the evidence, the role, collaborators, the outcome, the named reviewer and the context. Every record can be challenged and corrected.
The skills the member says they built. Whether a record can separate one person’s contribution from the team’s is still an open product question.
Evidence from the Mint Profile informs the next recommendation, so the record shapes the next Quest or Mission.
Status: concept. These rules are designed but not yet tested with hosts or hirers.
Is this live yet?
Not yet. Research, product model and pilot plan are done, so there are no outcome numbers and I won’t invent any.
What did the research actually show?
Entry-level jobs ask for experience students can’t prove.
So what would change for me?
A clearer path from not knowing where to start to proof you can show.
How will you know it works?
Five assumptions, each with its own test.
What’s the pilot?
Proposed: 2 high schools, 2 universities and 3 youth organisations. 100 completed Quests and 200 delivered Missions. No backend, revenue or confirmed partner yet.
I went into the data to fix two products. I came out with a different brief.
One academy. Fifty links. Every week.
Viewed, but still unpaid.
Same trade. Different payment tools.
Getting paid early was linked to coming back.
When merchants sent requests mattered · hourly bars are illustrative
Same Paylink. Four very different jobs.
When each merchant sent requests, and for how much.
{{ wkTitle }}
{{ wkCur.head }}
{{ wkCur.fr }}
{{ wkCur.why }}
Open full sizeResearch and ideation board. Select a step to spotlight it on the board.Seven bets came out of it. The first changed the question.
{{ rf.from }}
How might we help a merchantget paid, from the first requestto the money landing, without makingthem understand which product to use?
The focus moved beyond individual features to the work merchants had to do throughout the payment process.
Five decisions, and the evidence behind each one.
I made the design ask one question first: who’s paying you? Everything that used to be buried in settings follows from the answer.
Start with the payer, not the product.
Rather than choosing Paylink or Invoice, merchants start with who needs to pay: one customer, anyone with a link, or a group. The request adapts, showing additional details only when needed.
Stop rebuilding the same sale.
Merchants can repeat previous requests, save common prices, or collect from a group while tracking each payment individually.
Show what happened. Then what to do.
Give merchants a clear view of each request, from sending to payment, with relevant reminders, payment updates and receipts. Track settlement separately.
Show the money before sending.
Before sharing a request, merchants see what the customer pays, estimated fees, the amount they will receive, and expected settlement timing.
Give bigger payments a smaller first step.
Let merchants request a deposit upfront and collect the remaining balance later, with both payments tracked together.
Initial prototypes, built for chat.
Where millions of merchants and customers already talk every day. Both are live, so try them. They fed into the final Get Paid design.
Tested with merchants.
Same product, two completely different mental models.
Two daily PayLink users. Two opposite reactions to the prototypes.
The research turned two prototypes into one request.
Merchants thought in sales, not products. So both prototypes became two ways into one request.
From the first request to money in the wallet.
Every Get Paid screen, in the order a merchant meets them. Pick a stage or use the arrows.
Still to collect, in wallet and overdue on one card. Open requests sit below.
Every Get Paid path writes to the same record.
Pick a path to see what it touches. How it starts and where it goes can change. The record never does.
Four things I got wrong in the first version.
V1 made the flow shorter, but merchants were still guessing. V2 tells them what’s happening and what to do next.
Every time I unified something, I had to give something up.
Pick one to see where I landed.
One request, end to end, including a failure.
The same AED 2,600 invoice from Nadia Interiors to Maya Hassan. Each step shows what the merchant and the customer see, and which state the request is in.
- 01SentReview and sendMerchantSees the invoice as Maya will, then sends it.
- 02ViewedCustomer opens itCustomerSees Nadia Interiors and AED 2,600 before anything else.
- 03StartedCustomer taps PayCustomerStarts the payment. The amount is locked.
- 04ProcessingBank still checkingBothProcessing. It does not say Paid yet.
- 05aFailedDeclinedCustomerDeclined. Nothing was charged. Try again or use another method.MerchantAttempt failed. The request stays open.Proposed extension
- 05bPaidConfirmedCustomerPaid, with a receipt sent to Maya.MerchantPaid, only after the bank confirms.
- 06SettledMoney landsMerchantSettled shows separately, when the money reaches the wallet.
Steps 01 to 04, 05b and 06 come from the Get Paid screens and the revised payment status. The decline state is a proposed extension, built on PayBubble’s rule that a decline says whether you can retry and confirms when nothing was charged.
What I delivered, what testing changed, and what is still unproven.
- A product model: one request record behind every way of asking for money.
- Get Paid: 29 screens, from the first request to money in the wallet.
- Two prototypes, PayBubble and Invoice Autopilot, tested with merchants.
- Pilot targets and guardrails, agreed with product, data and leadership.
- Two prototypes became two ways into one request.
- Amount, expiry and who creates a request became configurable.
- Progress lists the missing fields instead of a percentage.
- The invoice type is suggested from the customer’s TRN.
- Creation split into Details, Review and Send.
- Paid shows only after the bank confirms.
- Whether requests are faster to create in real use.
- Whether repeat requests and saved prices get adopted.
- Whether reminders raise the paid rate of viewed invoices.
- Whether deposits help larger invoices get paid.
- Days to cleared money: ~17 today, 6 is a target.
Can merchants create an accurate payment request faster without losing clarity about fees and payment terms?
Measured by task completion time alongside errors and understanding. Collection outcomes are tracked separately, because faster creation does not automatically mean faster payment.
We agreed the north star and the guardrails as targets for a 10-merchant pilot.
So how much faster do I actually get paid?
Target: about 6 days from invoice to cleared money, down from ~17 today.
And making a request in the first place?
Seconds, not minutes. Repeats are one tap.
Will people actually pay on time?
Target: from 1 in 2 paid by the due date to 4 in 5.
What about the invoices people saw and never paid?
~2,000 of them, worth ~AED 5.5M. Reminders go out on day 1, 3 and 7, and stop the moment you’re paid.
Faster usually means more mistakes.
Guardrails: none of these should get worse.