Skip to main content
← Back to Work
E-commerce / Creator commerce2014 to 2018

Print-on-demand marketplace for sellers, staff and customers: original look

Seller, staff and customer screens and flows of a print-on-demand marketplace, reconstructed in its original look. Every seller design passed two staff reviews before sale.

ClientDressify.in
RoleSenior UX Designer
Year2014 to 2018
ToolsFigma, Photoshop, OpenCart
3
user roles: seller, staff and customer
13
pre-defined rejection codes in the design review

Context

Dressify.in was a print-on-demand and creator-commerce marketplace, founded and run by Anupam Guleria, who was also its only designer. Sellers uploaded artwork, placed it on products and set their own markup. Staff reviewed every design before it went on sale, and customers bought the printed products.

The original screens no longer exist. Every image on this page is a reconstruction, made in 2026 from memory, using the visual style of the original storefront.

How a design moved from seller to customer

Three diagrams describe the process: the three user roles and two review stages, the stages of a submitted design with its rejection codes, and the reminder rules for overdue work.

Three user roles, two design review stages. A seller's design passed an L1 review by two graphic designers and an L2 cross-check by the store admin before customers could buy it. Staff handled design approvals and customer orders in one merged admin dashboard.
Stages of a submitted design, from draft to sale. Sellers were promised a decision within 48 working hours. Every rejection carried one of 13 pre-defined rejection codes and an optional note, and a seller could resubmit a design any number of times.
Reminder and escalation rules for design approvals and payout requests. After 24 working hours with no action, staff received an email, and any of the four staff tiers could resolve the case.

Structure and flow

The information architecture groups the screens under the storefront, the seller area and the store admin. The screen flow shows how each action leads to the next screen.

The twelve screens that were designed or amended, grouped under the storefront, the seller area and the store admin. Standard OpenCart pages that were not changed appear as dashed boxes. The screen IDs in this diagram match the IDs in the screen captions below.
How the screens connect, and which action moves a seller, a staff member or a customer from one screen to the next. An equals sign marks two views of one screen: C1 and S4 are the same storefront, and C5 and S5 are the same design tool.

Seller screens

Sign-up, dashboard, account details, storefront, the design tool, designs, commission and orders.

S1 Seller sign-up. A new seller entered personal details, a store name and a password. The store URL was filled in from the store name, and the seller could edit the URL before continuing.
S2 Seller dashboard. After login, the seller landed on a grid of links to every seller page. The same links stayed in a side column on every seller page, so the seller never had to return to the dashboard to move between pages.
S3 Edit account. The seller updated the store name and URL, contact details and bank details for payouts. A warning stated that Dressify was not responsible for a payout that failed because the seller entered incorrect bank details.
S4 My storefront (owner view). An edit icon on the header let the seller change the profile picture, description, social links, header background and colour without leaving the page.
S5 Design tool, seller mode. The seller placed PNG artwork or text on a product, chose the product colour for the product image, and set a markup on top of a fixed base price. The product page URL was built from the product name the seller entered.
S5 Use on other products. After saving the price, the seller chose which other products should carry the same design. Every product ticked here received the same markup.
S5 Sent for approval. After the seller clicked Send for approval, a confirmation stated that approval takes up to 48 working hours from submission, and that an email would follow when the status changed.
S6 My designs. Every design the seller submitted was listed with its approval status: Awaiting approval, In review, Approved or Rejected.
S7 Commission. The seller saw the available balance, requested a withdrawal, and tracked each withdrawal request with its amount, status and payment date.
S8 Orders. Sales were listed per design, with units sold and commission earned. Sellers did not see customer details or order totals.

Staff screens (store admin)

Approvals, design review, payouts and seller commissions. Design approvals and customer orders were handled in one merged admin dashboard.

A1 Approvals queue. Staff saw every submitted design with its seller, submission date and the review stage where approval was pending: L1 or L2.
A2 Design review. L1 reviewers (graphic designers) and L2 reviewers (store admin) used the same screen. Rejecting a design required one of 13 pre-defined rejection codes, shown here as the open list, plus an optional note to the seller.
A3 Payouts. Staff processed seller withdrawal requests and recorded a result code for each payout.
A4 Seller commissions. For a chosen date range, staff saw each seller's balance, last payout, payment details, commission earned, design count, order count and order value. A separate export sent the data for all sellers to Excel or CSV.

Customer screens

Customers reached a seller's storefront and could use the same design tool as sellers, in customer mode.

C1 Seller storefront (public view). The seller's storefront as customers saw it, at dressify.in followed by the store URL. A customer who chose a product here went to a standard product page.
C5 Design tool, customer mode. Customers used the same design tool to make their own product. Size, quantity and Add to Cart replaced the seller's name, description and markup fields.
C5 Upload quality error. Every uploaded file was checked for print quality. A file with too low a resolution was refused, with a message naming the file and the reason.