Skip to content

E-Commerce Platform

Parv Online

ROLE
Product Designer (end-to-end, research through delivery)
TIMELINE
6 months, continuous research-and-design loop with the client
CORE PRODUCT
Parv Online, fashion e-commerce platform with custom sourcing requests
IMPACT
30+ screens shipped across the full purchase funnel; business discontinued after ~1 year due to legal and filtering restrictions, unrelated to product performance

01 / Context & The Bottleneck

Parv Online was selling through Instagram and word of mouth. That’s a ceiling, not a channel. No cart, no checkout, no way to scale past however many DMs one person could answer in a day.

The business wanted an actual storefront. Not just a place to list products, but something that could hold two very different catalogs at once: items physically in stock, and items the client didn’t own yet but could source on request from international retailers. Both needed to feel like the same store to the person shopping.

catalog.merge(in_stock, on_demand)
Two product sourcing models, in-stock inventory and on-demand international sourcing, unified under one storefront experience

The harder problem wasn’t inventory. It was trust. This is cross-border fashion e-commerce in a market where “online store selling imported brands” has a credibility problem before a user even scrolls. Two buyer mindsets had to be designed for at the same time:

  • Someone deciding whether this site is legitimate enough to hand over a card number to
  • Someone who already trusts it, now hunting for the best possible deal before they commit

Get the first one wrong and nobody buys anything. Get the second one wrong and the people who do trust you never come back.

buyer.mindset
Two coexisting user mindsets, trust-building for new visitors and deal-seeking for returning bargain hunters, both shaping the same flows

Scope, for context: Over 6 months, more than 30 screens were designed end to end, covering everything from browsing and the custom sourcing request form to checkout, account management, empty states, error states, and the blog. Research and design ran in parallel rather than sequentially, each section moved from research into design and was checked with the client before the next one started, so the business could get to market without waiting for a single big-bang launch.

flow.map()
End-to-end flow map, from landing through browse, custom sourcing request, cart, checkout, and account management
Worth saying upfront

One more thing worth saying upfront, since it shapes the rest of this case study: Parv Online shut down roughly a year after launch. Not because the product failed, but because of legal restrictions and filtering issues tied to cross-border sales, something outside what any interface decision could fix. That distinction matters for how to read everything that follows.

02 / Architecture & The Fix

Prioritization frameworks, before a single screen existed.

Research didn’t turn into a wishlist. MoSCoW sorted what had to exist for launch against what could wait, must-have versus nice-to-have, stated plainly so the client and I were deciding from the same list. KANO sat alongside it, separating features that would genuinely delight a buyer (the custom sourcing request, for instance) from features that were simply expected and invisible when done right (cart, checkout). That combination kept scope honest in both directions, not under-built, not bloated.

prioritize(moscow, kano)
MoSCoW and KANO applied together to separate must-have functionality from genuine differentiators before design began

Design decisions weren’t made alone in a vacuum.

Each section ran through mood boards holding multiple directions side by side, not one polished option presented as the only answer. A rating system scored those directions against the project’s actual goals (trust, conversion, brand fit) before one was carried forward into high-fidelity design. Key flows, especially checkout and the sourcing request form, went through A/B comparisons to pressure-test which version actually reduced friction rather than just looking cleaner.

evaluate(directions) · a/b
Mood boards and rating scorecards used to evaluate design directions, with A/B comparisons applied to key conversion flows

What “UX and UI best practices” actually meant here, specifically.

Saying “we followed UX principles” means nothing on its own. Here’s what that looked like applied:

  • Fitts’s Law on mobile tap targets across the cart and checkout flow, buttons sized and spaced so a thumb could complete a purchase without a mis-tap slowing someone down
  • Jakob’s Law in the checkout sequence itself, following the exact step order shoppers already know from major e-commerce platforms, because introducing a novel checkout flow in a trust-fragile category is a cost with no upside
  • Hick’s Law in category navigation, keeping filter and sort options to what a shopper actually needed to decide, instead of exposing every possible attribute and turning a quick browse into a research project
  • Von Restorff Effect on sourced-item labeling, making the distinct tag visually stand out against in-stock listings so the shipping-time difference registered before a shopper added it to cart, not after
  • Peak-End Rule applied to the post-purchase confirmation screen, closing the funnel on a clear, reassuring note since the last screen a buyer sees shapes whether they come back
heuristics.map(screen)
Specific UX and UI heuristics mapped to the exact screens they were applied to, Fitts's Law in checkout, Jakob's Law in flow sequencing, Von Restorff Effect in product labeling

Metrics the product was actually designed against.

Before design work started, a short set of target metrics gave the project something concrete to evaluate against as it shipped:

  • Checkout completion rate, the percentage of users who started checkout and finished it, the clearest signal of whether trust and friction were actually solved
  • Sourcing request submission rate, how many browsing sessions converted into an actual custom request, the core differentiator’s real test
  • Time to first add-to-cart, how quickly a new visitor found something worth buying, a direct read on whether navigation and labeling were doing their job
  • Return visit rate, whether the people who bought once came back, the bargain hunter’s vote on whether the store was worth checking again
metrics.targets
Target metrics defined before design began, each tied to the specific problem it was meant to measure (illustrative trend shapes)

Where Parv had to stand apart.

Competing stores were benchmarked on the things that decided this category: how visible their trust signals were, how honest they were about where a product shipped from and how long it would take, and how many steps stood between a product page and a paid order. Most were strong on one and weak on the rest. The goal wasn’t to beat anyone on catalog size, it was to be the store that left a shopper the fewest open questions.

benchmark(competitors)
Competitive benchmark across trust signals, sourcing transparency and checkout friction, with Parv Online's target position highlighted (illustrative)

Two catalogs, one honest label.

Merging in-stock and on-demand items into one grid only works if the difference between them is impossible to miss. Every product card carries a source label: a quiet, solid tag for items ready to ship, and a distinct, higher-contrast tag that states the sourcing time outright for items that still have to be ordered. Nobody should find out about a two-week wait on the confirmation screen.

label(product.source)
Labeling system that separates in-stock items from sourced items at a glance, so delivery time registers before add-to-cart, not after

The sourcing request, the feature that made the store different.

If a shopper couldn’t find what they wanted, they could ask for it. The request form was kept to the minimum needed to price an item: a link or description, size and color, and room for a note. The shopper got a confirmation straight away and a quote back with the item price, international shipping, and an expected delivery time, then could accept it straight into the cart. A DM conversation, turned into a flow.

sourcing.request() → quote
Custom sourcing request flow: a short form, a confirmation, and a priced quote returned to the shopper

Trust, placed where the doubt actually shows up.

Trust signals weren’t piled into a footer. Each one was placed at the stage of the funnel where its matching doubt surfaces: a real address and contact details on landing, reviews on the product page, the return policy in the cart, and payment security at checkout. The question gets answered at the moment it gets asked.

trust.inject(funnel)
Trust signals placed at the funnel stage where each doubt actually surfaces, not stacked in the footer

Designing for the bargain hunter.

For returning shoppers, the store had to reward checking back. Price drops and time-boxed sales were surfaced directly on the product grid, with the original price kept visible next to the new one, so a deal reads as a deal at a glance instead of something a shopper has to work out.

deals.surface()
Deal mechanics for returning shoppers: price drops and time-boxed sales surfaced directly on the product grid

An information architecture built for search, not just navigation.

A store that can’t afford paid acquisition at scale needs to be found. The structure stayed shallow, storefront into a small set of categories into product pages, with every product reachable in a few clicks and given its own descriptive, indexable page. The blog fed the same structure, giving long-tail searches somewhere real to land.

ia.tree(storefront)
Information architecture built for both navigation and search: shallow categories that branch into long-tail product pages

One UI kit behind 30+ screens.

A compact UI kit held the whole thing together: a short type scale, a small set of color roles, and every component state defined up front. Consistency here isn’t decoration, in a trust-fragile category, a screen that looks slightly off is a reason to leave.

ui-kit / foundations
A compact UI kit, type scale, color roles and component states, shared across all 30+ screens

Accessibility, checked rather than assumed.

Contrast was checked across interactive elements, with primary actions like “Place order” held to the strictest level. Tap targets, focus states, and readable type sizes were reviewed as part of each section, not saved for a final pass.

a11y.contrast(cta)
Contrast checks run on every interactive element, with primary actions held to the strictest level

03 / Impact & Outcome

What shipped.

  • 30+ screens designed end to end over 6 months, from browse and the custom sourcing request form to checkout, account management, empty and error states, and the blog
  • Two catalogs, in-stock and on-demand, presented as one storefront with a labeling system that made the difference clear before add-to-cart
  • A launch delivered section by section, so the business got to market without waiting on a single big-bang release
dashboard / post-launch
The post-launch dashboard the team used to read the target metrics as the store ran (illustrative shape, not client data)

How it ended, and why that matters.

Parv Online closed roughly a year after launch. Not because shoppers stopped buying, but because legal restrictions and filtering issues tied to cross-border sales made the business impossible to keep running. No interface decision could have changed that. The product did what it was designed to do, the market it operated in stopped allowing it to.

trajectory(year_1)
Growth was still climbing when legal and filtering restrictions on cross-border sales ended the business, a stop the product itself didn't cause (illustrative shape)

That’s the honest version of this case study: the design work holds up on its own terms, even though the business around it didn’t get to continue.

04 / The Interface