Limeroad
Case study
Nishesh Jaiswal
Nishesh Jaiswal@nisheshjaiswal · 2020

I designed Reviews and Pay Later at opposite ends of a purchase, using one principle: ask for commitment in small, clear steps. Reported photo-review coverage reached 19% of delivered orders, and about one in six eligible checkouts used Pay Later.

LimeRoad: one purchase, two trust systems

I designed Reviews and Pay Later at opposite ends of a purchase, using the same principle: ask for commitment in small, clear steps.

Company: LimeRoadRole: Product designerTimeline: 6 months, March to September 2020Team: 1 PM, 4 engineers and 2 QAPlatform: Android app

Reported project evidence

What the archive says shaped the brief

These figures come from the existing historical portfolio. They are presented as reported project evidence, not independently verified analytics.

500+

Support interactions

Six months of customer-service material was analysed for payment and product concerns.

Interaction Study
8

Competitor reviews

Eight e-commerce experiences were compared to understand review and credit conventions.

CA Reviews
40%

Reported mobile growth

The archive reports growth in mobile usage; the underlying dashboard and date window are not available here.

Mobile Growth
60%

Reported support-call growth

The archive reports higher support-call volume, mainly around payment and product concerns.

Evidence Reported

System map

One purchase, two trust lanes

The purchase connects the work, but the two journeys serve different people and happen at different moments.

Current shopperPay Later · before purchase

Explain the proposition

Show the value of credit before requesting identity details.

Verify in stages

Separate identity, approval, bank linking and card checks.

Name system work

Explain account and card verification instead of leaving an unexplained pause.

Next shopperReviews · after delivery

Begin with a reaction

A positive or negative choice is easier to start than an empty text box.

Branch the questions

Fit, material and problem prompts follow the shopper's opening response.

Show completion

Photo, comment, reward and cumulative progress close the loop.

Reading the system

The two journeys ask for different kinds of trust

Reviews happen after a purchase; Pay Later has to earn confidence before one can continue.

The Review journey starts with something the shopper already knows: whether the delivered product felt right. A small reaction can then branch into fit, material, product problems and richer comments.

Pay Later starts with uncertainty instead. The shopper needs to understand the offer before sharing identity details, then see clear milestones through approval and repayment setup.

Reviews · evidence to response

Turn one reaction into useful product evidence

Each response narrows the next question so the shopper does not have to translate every experience into free text.

The review starts against a delivered product, so the product context is already known. Asking positive or negative first creates momentum without opening with an empty text box.

The next question follows that reaction. Fit, material and product problems need different answers, so conditional prompts create more comparable evidence before the journey asks for a photo or written comment.

Archived screens · the branch

One tap, two different sets of questions

Yes and No do not lead to the same form. Setting the two next screens beside each other is the clearest evidence of what the branch is for.

Liked itYes opens on fit

The rail runs FIT, MATERIAL, REVIEW. The opening question, tell us how the product fits, is answered by choosing Too Small, Correct Size or Too Large.

Did not like itNo opens on quality

The rail carries a fourth step, QUALITY, and it runs first. What went wrong offers three checkboxes: product was different from image, material issue, wrong item received.

What the branch changesThe negative answer inserts a Quality step that the positive path never sees, and asks it first. A complaint then arrives as one of three named faults rather than as free text, so it can be counted and compared instead of read one by one.

Archived screen sequence

The Review journey in five screens

The prompt, the two structured questions, the optional evidence and the closing state, in the order a shopper meets them.

Prompt

Notice how little the first step asks for: two buttons, on the product page, against an item that has already been delivered, so there is nothing to recall. The strip above states what the interface is offering, 10 credits for a review and 20 for uploading photos.

Fit

Notice that the answer is a choice rather than a sentence. Correct Size is selected here, and because every shopper picks from the same three options, fit stays comparable across the product.

Material

Quality and feel are asked as two separate questions on one screen. Notice that ticking Transparent opens a follow-up asking whether the item is still wearable, so a vague complaint is pushed one level more specific.

Evidence

Notice where the free text sits: last, once the structured answers have already been captured, and phrased as a question (do you want to say something?) rather than as an instruction. The photo slot above it asks for a product image or a selfie.

Reward

The closing state names what has just been credited and sets it beside a running total, so a shopper can see their reviews adding up. Notice the single onward action, continue shopping, which returns them to the purchase journey rather than to another form.

Pay Later · evidence to response

Explain value before asking for sensitive information

Credit introduces a higher trust cost, so the journey separates proposition, identity, approval and repayment setup.

The entry appears inside the shopping journey, keeping the proposition connected to the purchase. The offer is explained before the experience requests identity details.

Eligibility and activation are separate states. Making approval a distinct milestone lets the shopper see the available credit before completing the remaining repayment setup.

Archived screen sequence

The Pay Later journey separates four commitments

Six archived screens in order. The offer is explained first, identity is a bounded step, approval is a milestone of its own, and repayment setup follows separately.

Proposition

Notice what is offered before anything is asked for: the amount, and the two steps it will take. The sheet opens over the shop, so the proposition stays attached to the purchase.

Identity

Every sensitive field sits inside one named step rather than being scattered through checkout. Notice the inline alternative: a shopper without a PAN card of their own is offered a family member's instead of being stopped.

Verification

The Aadhaar number stays on screen with an Edit link beside it, and the countdown next to the OTP field says how long the code has left instead of leaving the wait unexplained.

Approval

Approval is a milestone in its own right. Notice that shopping is the primary action here and repayment setup is offered separately underneath, so the credit becomes usable before the remaining admin is done.

Repayment setup

Tenure and bank are shown as settled values with an Edit link, so the terms of the arrangement can be checked before Activate is pressed.

Confirmation

The confirmation repeats what was actually set up: masked account, bank and tenure. Adding a card is offered afterwards as an option, not as a condition of finishing.

Archived system states

Naming each stage makes the waiting legible

Verification takes system time that no interface can remove. The same panel names the stage it has reached, keeps the finished ones ticked and says where the shopper goes next.

Verifying

The first state names the step that is running and says it takes a few seconds. The two stages still to come are already listed, so the wait has a visible end.

Processing

Notice the tick left behind on the finished step. Progress accumulates on screen, which is what separates a system that is working from one that looks stuck.

Successful

The middle step relabels itself from Processing e-KYC to e-KYC successful, so the outcome is stated rather than implied, and the final line says where the shopper is being taken.

Reported outcomes

What the two journeys moved

Reported after launch. The archive does not include the underlying dashboards or date windows, so treat these as reported results rather than independently verified analytics.

measured↑ 19%

Delivered orders with a photo review

Reported share of delivered orders that carried a photo review after the reward-linked, branching flow shipped, up on the previous review flow.

reported
measured↑ 17%

Pay Later adoption

Reported share of eligible first-time-buyer checkouts that used Pay Later in the first quarter after launch.

reported

Evidence boundary

What is visible, what is inferred and what remains open

A robust case study should make the strength of each claim legible, not flatten every artefact into proof.

Visible archive evidence

  • Archived Review screens show positive and negative branches, structured questions, photo and comment capture, and a reward state.
  • Archived Pay Later screens show proposition, identity, approval, account verification and bank-linking states.
  • The historical portfolio reports 500+ support interactions and comparison across eight platforms.

Reasoning inferred from the work

  • Small commitments likely reduce the trust cost of both journeys.
  • Branching review prompts are intended to create more comparable product evidence.
  • Named verification states are intended to make system progress easier to understand.

Evidence limits

  • The archive does not include raw support data, interview transcripts or competitor-review notes.
  • The reported figures, including mobile growth and the two journey outcomes, have no visible date window, baseline or analytics source.
  • Approval comprehension, full activation and repayment setup are not separated in the reported numbers.

What I would validate next

  • Instrument entry, step completion, exits and error recovery for both journeys.
  • Compare review usefulness and completion across structured and open-input variants.
  • Measure Pay Later approval comprehension separately from full activation and repayment setup.

Reflection

Trust is easier to build when progress is specific

The strongest connection between these journeys is not visual styling. It is the discipline of making each commitment small, naming what the system is doing and showing what changed. The archive demonstrates the product logic; a future version should connect that logic to instrumented behaviour and customer evidence.

Priya Nair

The pay-later flow feels so trustworthy. Lovely balance of speed and reassurance.

Marcus Chen

Great case study, the conversational review system is my favourite part.

Back to feed