Fashion Party
Case study
Nishesh Jaiswal
Nishesh Jaiswal@nisheshjaiswal · 2020

Fashion Party made reselling feel like work before people had seen the value. I redesigned the Android journey around browsing, building a collection and sharing it. The archive reports 38% first-session creation against a 30% target and a 45% increase in sharing.

Fashion Party: making fashion reselling easier to start and share

I redesigned the Android experience around a simple reseller loop: browse, build a collection, share it and keep track of the sale.

Company: Limeroad · Fashion PartyRole: Product designerTimeline: 4 months total, including a 30-day redesignTeam: 1 PM, 1 Android developer, 1 backend developer, 1 QA engineerPlatform: Android native app

The brief

Make fashion reselling feel like one connected job

Fashion Party was Limeroad's attempt to make fashion reselling feel more social. The business depended on people finding products, collecting them into something worth sharing and then passing that collection to friends. The existing journey made each of those steps feel like separate work.

I led the product design and rebuilt the core Android journey in 30 days. I worked with a product manager, an Android developer, a backend developer and a QA engineer across the wider four-month project.

Research summary

A focused evidence base for a fast redesign

The project archive records a compact research programme. The counts describe what was done, not the statistical strength of the findings.

8

Interviews

Women aged 18 to 26 discussed how they explored, organised and shared fashion products.

Reported archive evidence
3

Competitor journeys

Meesho, Shop101 and GlowRoad were reviewed as historical qualitative references.

Reported archive evidence
1

Information-architecture exercise

The product was organised around browsing, collections, creation, orders and profile tasks.

Reported archive evidence

The reseller loop was losing momentum

Sharing felt like extra work instead of the point of the journey

Competitor journeys often asked people to create an account before they had seen enough value. Once inside, crowded category pages and repeated navigation made collection creation hard to find. Sharing, which should have been the point of the task, arrived as an extra step at the end.

Historical qualitative comparison

Three competitor journeys exposed the same momentum risks

This comparison reflects the project-period review recorded in the archive. It is not a claim about the products' current experiences.

Meesho

ObservedThe reviewed journey asked for account commitment early.

Design implicationLet people understand the proposition and browse before requiring login.

Shop101

ObservedDense category and navigation structures increased the effort to find a useful starting point.

Design implicationUse visual collections and keep the core creation action persistently available.

GlowRoad

ObservedSharing appeared separate from product selection in the reviewed flow.

Design implicationMake sharing the natural finish to collection building.

What the research changed

Behaviour was more useful than a fictional profile

I interviewed eight women aged 18 to 26, reviewed the main journeys in Meesho, Shop101 and GlowRoad, and ran an information architecture exercise. The interviews were quick because of the timeline, but the same behaviours kept appearing. People wanted to browse before committing, thought about fashion as looks rather than catalogue structures, and expected sharing to feel immediate.

I dropped the original persona slide from this case study because the behaviour was more useful than a fictional profile. The research gave me three practical requirements: show value before asking for commitment, use visual collections as the organising model and make sharing the natural end of the task.

Evidence trace

Make every visible response traceable to a research signal

The intended result is labelled as rationale, not presented as another measured outcome.

01

Evidence

Participants wanted to browse before committing.

Product response

Show the proposition and product proof before login

Reduce early commitment before people have seen enough value.

02

Evidence

Fashion was described in looks and collections, not catalogue structures.

Product response

Use visual collections as the organising model

Give the browsing experience a unit that is meaningful to assemble and share.

03

Evidence

Collection creation was difficult to find in the reviewed journeys.

Product response

Keep a central creation control visible

The core job should not disappear inside secondary navigation.

04

Evidence

People expected sharing to feel immediate.

Product response

Place direct and WhatsApp sharing at the end of selection

The handoff becomes part of the task instead of reconstruction outside the app.

The collection model took four attempts

The hierarchy emerged through comparison

The first version was still a conventional product feed with a Share button attached. Larger images improved the second version, but every product carried roughly the same weight. In the third version I paired imagery with clearer product information. The fourth version finally gave the collection a lead product, supporting choices and a visible sharing action.

Four collection iterations

The collection moved from product rows to a visual set

The same Trending Kurtas collection, redrawn four times. The title, the starting price, the rating and the viewer count are present in every version, so what moves between them is the hierarchy around those facts.

V1

Notice that every tile is the same short crop, so the garments are cut off and no product leads. The collection facts sit in a block underneath and Share runs full width below them, which is a familiar product feed with a sharing action added to the end of it.

V2

The tiles are now tall enough to hold a whole garment and only two and a half fit across, so the row reads as a scroller. Notice that the products are still all the same size, so nothing says where to begin, and the facts and Share still sit in a full width block below.

V3

The collection is rebuilt as two columns: images on the left, and a column on the right holding the title, the starting price, free delivery, the rating and the viewer count. Notice the card edge showing behind the first image, and that the unit is now short enough for a second collection to reach the same screen.

V4

One product now leads at full height, with two supporting choices stacked beside it and See more sitting on the lower one. Notice where Share ends up: on the same line as the collection facts rather than on a bar of its own, so choosing and sharing belong to the same block.

Turning evidence into product decisions

Keep value, creation, sharing and earnings in the same thread

Let people see value before asking for commitment

The competitor review showed how quickly an early account wall could stop exploration. Fashion Party introduced the proposition first and delayed login until people understood what they could browse, share and earn from.

Keep the core action visible

Collection creation could not sit inside a secondary menu. I kept a central creation control in the bottom navigation so it stayed available while people browsed.

Make sharing part of the task

Sharing was the bridge between browsing and reselling, so I placed direct share and WhatsApp actions where people finished choosing products. They did not have to leave the flow and reconstruct their work elsewhere.

Keep earnings in context

The product page showed potential earnings beside the selling price. That margin carried into the cart and order screens, which made the reseller value visible after discovery instead of reducing the experience to a standard checkout.

The end of selection, on one screen: four products ticked, each carrying its price and its potential margin, and the share control opened into Whatsapp and Download without leaving the collection.

Core reseller loop

Keep the collection and potential margin connected

The primary recruiter narrative stays on the job the product is helping someone complete.

  1. Browse

    See the proposition and product proof before account commitment.

  2. Build

    Select products into a visual collection through a persistent creation action.

  3. Share

    Hand off the collection directly or through WhatsApp at the end of selection.

  4. Transact

    Carry selling price and potential earnings into product, cart and order states.

  5. Track

    Keep order states, returns and earnings connected to the reseller's activity.

One connected reseller loop

The collection stays visible from discovery to order tracking

The finished flow connected discovery, product selection, reseller margin, checkout and order tracking. The screens still handled familiar commerce tasks, but the thread between them was the collection someone intended to share and earn from.

Archived product sequence

The reseller thread stays visible across the flow

Two focused boards replace five consecutive screen cards: one covers collection building and sharing, the other carries reseller value into product and order states.

Browse, build and share: the collection is the thread across the first half of the reseller journey.
Transact and track: selling price, potential earnings and order status remain connected after sharing.

What changed after testing

The sharing model held; the controls needed another pass

Five participants tested the interactive prototype. They understood the sharing flow without explanation, which gave me confidence in the overall model. The controls needed another pass. The floating action icon did not explain collection creation clearly, and the language around Collections and Wishlist overlapped.

I clarified the creation control and unified the navigation language. I kept the direct sharing pattern because people already understood what would happen.

Five-session validation sequence

Testing changed clarity, not the core sharing model

The archive reports five prototype sessions. These are qualitative findings from a small sample, not a usability benchmark.

  1. Observe

    Five participants used the interactive prototype.

  2. Retain

    Participants understood the direct sharing flow without explanation.

  3. Clarify

    The floating creation icon did not explain collection creation clearly enough.

  4. Unify

    Collections and Wishlist language overlapped, so the navigation vocabulary was consolidated.

  5. Leave open

    Small text, compact targets and colour-coded states still needed build-level accessibility testing.

Supporting artefacts

The wider process is available without interrupting the primary story

Journey maps and secondary process material remain part of the case study, consolidated behind focused summaries.

Information architectureOpen artefact

Five primary jobs organise Home, Collections, Create, Orders and Profile. Earnings remains visibly unfinished and Home and Collections still overlap.

The map records the proposed structure and the unfinished Earnings destination.
Customer journey and hypothesesOpen artefact

The entry and value maps frame the first shareable collection as the aha moment. Emotional states are hypotheses because the source material does not report them directly.

Emotional states and churn points remain hypotheses to test.
Task flowOpen artefact

One decision splits the journey: share the collection immediately or continue into checkout, tracking and returns.

The flow keeps sharing and transaction paths connected to the same collection.

Reported beta outcomes

The numbers describe the loop the redesign set out to improve

The portfolio archive records a small set of reported beta figures from the launch.

Reported beta outcomes

Separate the target from the reported result

The archive reports these figures, but does not include analytics definitions, baselines, collection windows or source systems.

target30%

First-session collection-creation target

Historical beta target, not a measured result.

reported
measured38%

First-session collection creation

Reported beta result; event definition, baseline, window and analytics source are unavailable.

reported
measured+45%

Increase in sharing behaviour

Reported increase; comparison baseline, observation window and event definition are unavailable.

reported
measured4.4 / 5

Beta rating from 680+ reviews

Reported beta rating from 680+ reviews; the review-platform export and date window are unavailable.

reported

These describe a beta loop, not a proven business result. The next section sets out exactly what the archive can and cannot support.

Evidence boundary

What the archive supports and what remains uncertain

Visible archive evidence

  • Archived artwork shows the collection iterations, persistent creation action, direct sharing, product margin, orders and tracking states.
  • The historical portfolio records eight interviews, three competitor journeys, an information-architecture exercise and five usability sessions.
  • The archive reports 38% creation, +45% sharing and a 4.4/5 beta rating from 680+ reviews.

Reasoning inferred from the work

  • Showing value before login is intended to protect exploration momentum.
  • A visual collection is intended to match how participants described fashion looks.
  • Keeping sharing visible is intended to reduce the handoff effort in the reseller loop.

Evidence limits

  • Interview notes, recruitment criteria, competitor captures and the IA method are not available in the portfolio archive.
  • Reported beta figures do not include event definitions, comparison baselines, observation windows or analytics sources.
  • The five sessions are too small to establish task success rates, and the prototype still contains open accessibility risks.

What I would validate next

  • Define and instrument first-session collection creation before comparing it with the 30% target.
  • Measure share intent, completed shares and downstream order activity as separate events.
  • Test small text, touch targets, focus order and status comprehension in the built Android experience.

Reflection

A social-commerce loop only works when its handoffs feel like one job

The redesign became stronger when collection creation, sharing, margin and order tracking stopped behaving like disconnected features. The archive shows the iterations and the reasoning clearly; the next level of evidence would connect those decisions to defined events, raw research and build-level accessibility results.

Himanshu Maurya

The reseller loop is such a smart growth mechanic. Would love to see the numbers a year in!

Abhishek

Beautiful storytelling from research all the way to shipped screens ✨

Back to feed