2026

Designing Trust for Informal Debt

Role:

Product Designer

& UX Writer

Team:

1 Product Designer

1 Product Manager

2 Software Engineers

Timeline:

6 weeks

Skills:

UX Research & Design

Prototyping & UX Writing

Overview

A promise that only exists in conversation is a promise with no proof

Lending money to friends, colleagues, and family is common. Someone needs help with rent, a bill is due before payday, or a family member promises to repay next month. The agreement is often made in a message or conversation, then left to memory.

Repay brings structure to these informal agreements by creating a shared record that both lender and borrower acknowledge. It does not move money or issue loans. It records what was agreed, when it should be repaid, and what both people accepted.

The project challenged me to design for a financial relationship built on clarity, accountability, and trust.

The Problem

Informal lending needs accountability

The absence of a shared record creates uncertainty before, during, and after a loan. Lenders have little context when deciding who to lend to, both parties can lose track of the agreement, and documentation often appears only after a dispute.

The three major problems:

No visibility

Lenders have little information about a borrower's repayment history before making a decision.

No accountability

Both parties need a record they can refer back to throughout the loan.

Late documentation

People often seek documentation only after a dispute begins.

Product Vision

Give informal lending the structure it needs

Repay records a loan through mutual confirmation. The lender creates the record, the borrower reviews the details, and the agreement only becomes active when both parties confirm it.

This creates a shared reference for the loan from the start, giving both parties the same record to return to throughout the repayment period.

My task was to give informal lending a clear record that both parties could acknowledge and return to.

Design Approach

Designing for trust.

Repay serves two people with different concerns. Lenders need confidence that a debt is recorded. Borrowers need to know what has been recorded and have the opportunity to challenge it.

Because the project was completed under a tight deadline, research came from conversations with the founder, existing lending behaviour, and current ways people document informal agreements. One insight guided the product: People need a shared record of the agreement, not just a record of the payment.

Debt registration

The lender enters the borrower, amount, and loan details. The borrower then receives a verification request through SMS or WhatsApp.

The debt becomes active only after the borrower confirms it.

Verification protects both parties

Without verification, anyone could create a debt record against another person. Borrowers can verify, dispute, or ignore a request. Only verified debts enter the public credibility record. Disputed and ignored requests remain unpublished.

Accountability without exposure

The public profile communicates credibility without exposing someone's complete financial history. Amounts, detailed records, and sensitive information remain private.

Information should follow consent

Repay uses different levels of access. Regular users see the information needed to assess repayment credibility. More detailed access is reserved for verified organisations through approved API access.

Language matters

Terms such as “Debtor's Response” and “Disputed” describe the situation without assigning blame. The interface gives both parties room to respond before a claim becomes a public record.

Design Constraints

The MVP had to prove the core idea first

Repay was developed under a tight deadline, with limited access to primary research and usability testing. The focus was on defining the product strategy, core interactions, and interface for future validation.

API integrations, escrow, and expanded notifications were left for later phases.

The constraint kept the work focused on the decisions that mattered most to the product.

Product Experience

A shared record for every agreement

Repay follows a simple flow: the lender records the debt, the borrower reviews and verifies it, and the confirmed record becomes part of their repayment history.

Borrowers can respond to pending requests and review their records. Lenders can check repayment credibility before lending. Verified organisations can access additional information through approved permissions.

Each party has defined control

The borrower has control over the debt from their side, including making payments or raising a dispute. The lender can track repayment progress but cannot alter the record after it has been created.

Borrowers have the autonomy to dispute a debt

The borrower can review the recorded details and raise a dispute if they believe the debt is incorrect.

Lenders can check repayment history first

A borrower’s record helps lenders assess their repayment history before lending.

Future Considerations

The next chapter for Repay

The next phase would extend Repay beyond its core record-keeping experience through four areas:

API access for verified financial institutions
Escrow for higher-value lending
Clearer consent controls for personal data
Automated repayment reminders through SMS and WhatsApp

What I learned

A shared record requires shared agreement

Repay taught me that documenting a debt is only part of the problem. The harder task is creating a record that both people recognise as accurate. This shifted my thinking toward consent, privacy, accountability, and the rules that shape financial products.

2026

Designing Trust for Informal Debt

Designing Trust for Informal Debt

Designing Trust for Informal Debt

Overview

A promise that only exists in conversation is a promise with no proof

A promise that only exists in conversation is a promise with no proof

Lending money to friends, colleagues, and family is common. Someone needs help with rent, a bill is due before payday, or a family member promises to repay next month. The agreement is often made in a message or conversation, then left to memory.

Repay brings structure to these informal agreements by creating a shared record that both lender and borrower acknowledge. It does not move money or issue loans. It records what was agreed, when it should be repaid, and what both people accepted.

The project challenged me to design for a financial relationship built on clarity, accountability, and trust.

The Problem

Informal lending needs accountability

Informal lending needs accountability

The absence of a shared record creates uncertainty before, during, and after a loan. Lenders have little context when deciding who to lend to, both parties can lose track of the agreement, and documentation often appears only after a dispute.

The three major problems:

Product Vision

Give informal lending the structure it needs

Give informal lending the structure it needs

Repay records a loan through mutual confirmation. The lender creates the record, the borrower reviews the details, and the agreement only becomes active when both parties confirm it.

This creates a shared reference for the loan from the start, giving both parties the same record to return to throughout the repayment period.

My task was to give informal lending a clear record that both parties could acknowledge and return to.

Design Approach

Designing for trust.

Designing for trust.

Repay serves two people with different concerns. Lenders need confidence that a debt is recorded. Borrowers need to know what has been recorded and have the opportunity to challenge it.

Debt registration

The lender enters the borrower, amount, and loan details. The borrower then receives a verification request through SMS or WhatsApp.

The debt becomes active only after the borrower confirms it.

Verification protects both parties

Without verification, anyone could create a debt record against another person. Borrowers can verify, dispute, or ignore a request. Only verified debts enter the public credibility record. Disputed and ignored requests remain unpublished.

Accountability without exposure

The public profile communicates credibility without exposing someone's complete financial history. Amounts, detailed records, and sensitive information remain private.

Information should follow consent

Information should follow consent

Repay uses different levels of access. Regular users see the information needed to assess repayment credibility. More detailed access is reserved for verified organisations through approved API access.

Language matters

Terms such as “Debtor's Response” and “Disputed” describe the situation without assigning blame. The interface gives both parties room to respond before a claim becomes a public record.

Design Constraints

The MVP had to prove the core idea first

The MVP had to prove the core idea first

The MVP had to prove the core idea first

Repay was developed under a tight deadline, with limited access to primary research and usability testing. The focus was on defining the product strategy, core interactions, and interface for future validation.

API integrations, escrow, and expanded notifications were left for later phases.

The constraint kept the work focused on the decisions that mattered most to the product.

Product Experience

A shared record for every agreement

A shared record for every agreement

A shared record for every agreement

Repay follows a simple flow: the lender records the debt, the borrower reviews and verifies it, and the confirmed record becomes part of their repayment history.

Borrowers can respond to pending requests and review their records. Lenders can check repayment credibility before lending. Verified organisations can access additional information through approved permissions.

Each party has defined control

The borrower has control over the debt from their side, including making payments or raising a dispute. The lender can track repayment progress but cannot alter the record after it has been created.

Borrowers have the autonomy to dispute a debt

The borrower can review the recorded details and raise a dispute if they believe the debt is incorrect.

Lenders can check repayment history first

A borrower’s record helps lenders assess their repayment history before lending.

Future Considerations

The next chapter for Repay

The next chapter for Repay

The next chapter for Repay

The next phase would extend Repay beyond its core record-keeping experience through four areas:

API access for verified financial institutions

Escrow for higher-value lending

Clearer consent controls for personal data

Automated repayment reminders through SMS and WhatsApp

What I learned

A shared record requires shared agreement

A shared record requires shared agreement

Repay taught me that documenting a debt is only part of the problem. The harder task is creating a record that both people recognise as accurate. This shifted my thinking toward consent, privacy, accountability, and the rules that shape financial products.