Two
months
to
build
a
marketplace
model
nobody
had
designed
before.
165× transaction-value growth in the nine months that followed
A new kind of platform, with no existing template.
In 2016, print-on-demand platforms all worked the same way. Printify was the exception. Where competitors owned their printing facilities, Printify owned none — it was a pure marketplace connecting eCommerce merchants with third-party print providers. No design precedent existed for a marketplace where fulfillment was the variable. Rather than attempt a full upfront redesign, I proposed to build the product through iterations on the live app.
The original platform had been designed to get merchants from sign-up to selling as fast as possible — and used that flow to explain how Printify worked. Marketing and the founders were convinced that merchant understanding of the marketplace was critical to activation. That hypothesis wasn't yet supported by data.
My task was to redesign the full merchant experience under a two-month investment deadline, against live traffic and active merchants. I worked daily with founder James Berdigans and two co-founders as business objectives shifted week-to-week, and directly with engineering, CS, sales, and merchandising throughout. This case study covers the entry point of that work: how merchants discover, select, and create products.
Before design started, I aligned with stakeholders on what outcomes would define success — not on what was visually broken. That grounding shaped every prioritization decision that followed.
The Approach
A principles-led sprint, not a detailed plan.
I proposed a principles-led sprint rather than a detailed plan. To scope it, I reviewed ~30 session recordings, ran analytics, and held early workshops with CS, merchandising, sales, and marketing. Five principles shaped the work.
Focus on the user flows that mattered most
From the scoping workshops and session analysis, the key stages became clear: quick onboarding, product selection, and customization first; created-product management, Shopify integration, and sample ordering later.
Internal feedback as research, not anecdote
CS, sales, and merchandising already knew things that would take months to surface otherwise.
Rapid weekly iterations
One ship per week — each release an MVP of an MVP, incomplete by design, observed, then refined.
Extremes before personas
Design for the professional who knows exactly what they want and the complete beginner with no prior experience. If the flow works for both, it works for everyone in between. Internally aligned with the founders on an 80:20 weighting — beginners over professionals.
Lean thinking
Ship the smallest viable version of each feature, not the complete one.
The tradeoffs I accepted
The design system stayed scrappy — atoms and typography over polished components. Process and decision logs lived in heads, not shared documents. Conscious bets that sprint speed mattered more than craftsmanship hygiene. The design hires who joined later inherited the gaps; the company inherited the speed that made it investable.
The Problem
Merchants were being asked to commit before the platform gave them a reason to.
The original product was built on a single structural assumption: merchants would commit before they could evaluate. Research — early merchant interviews, session recordings, analytics — made clear almost immediately that this assumption was wrong, not at the edges, but at its core.
These four problems pointed to one pattern: the product was asking merchants to commit (register, filter, generate, accept) before giving them a reason to. "Remove commitment before value" became the sprint's working hypothesis.
Research & Insights
The drop-off wasn't where anyone thought it was.
The work required a research practice, so the two developed in parallel. I combined qualitative research and session recordings to understand why merchants struggled, with KPI tracking after each release.
Merchants had no way to assess product quality before committing.
This pattern — merchants who recognized garment brands they trusted, but couldn't tell which products mapped to which brand, and had no way to evaluate quality without buying blind — recurred across early interviews. It became the finding behind the provider-ratings model — ratings split across quality, speed, and shipping rather than collapsed into one score.
Yeah, I see the products, but I'm not really sure which hoodies are better quality. I know Bella+Canvas usually has good ones, but I can't tell which ones are Bella+Canvas. Can I order samples, or do I have to order a bunch of them?
Merchant
early user interview via Skype (2016)
The drop-off was at the multi-select mechanic, not the catalog component
I reviewed 50+ session recordings and conducted 7 early user interviews. The drop-off wasn't at the catalog component. It was at the multi-select mechanic itself. Merchants weren't confused by the products — they were confused by how they were asked to choose between them.
No intuitive sequence existed — even among internal experts
I ran 7 structured feedback sessions and tree tests with CS and sales reps who'd worked with merchants across dozens of use cases. When I asked them to sequence the creation steps in "ideal order," no two produced the same sequence. If the people closest to the product couldn't agree on one flow, merchants couldn't intuit one either.
Cross-functional workshops reframed design reviews around outcomes, not deliverables
Across the sprint I ran 5 workshops with CS, merchandising, sales, and engineering — each team held a partial view of the merchant experience. Showing KPI movement tied to specific decisions shifted the framing from "what deliverables are coming" to "what outcomes did we get and why."
Taxonomy workshops fixed the vocabulary gap between teams
Inconsistent terminology was creating silent friction; the workshops also surfaced the need for cross-placement — the same product appearing in multiple category entry points.
The Iterations
Five versions, one consisten signal.
Over the two-month sprint, I iterated five successive versions onto the live Printify Shopify app — each one a real release to merchants already using the product. The pattern of KPI movement across those releases became my primary navigation tool; for several versions I also ran user interviews. The goal wasn't a steady upward climb — it was to read fluctuations as evidence, not noise. V5 shipped as the redesigned MVP.
A framing constraint shaped the early sprint. The marketing team held a clear activation hypothesis: that merchant misunderstanding of the platform drove quality complaints — and that better explanation would stop merchants from misattributing print-provider issues to Printify. The logic had real grounding, partly from the support tickets the team fielded daily. But my read was that the problem sat a level deeper: merchants couldn't find, compare, or customize products, and no explanation would fix that. Rather than argue the architectural case upfront, I proposed UI-level iterations first — letting data widen scope as each release earned it. V1 and V2 tested within the educational frame. V3 is where scope widened; V5 is where it landed.
The iteration cycle was deliberately tight. Design started late Monday, drafts ready Tuesday and handed to engineers the same day. Wednesday evening the changes were live; we gathered data through the weekend. Monday morning we decided whether to keep the direction or change course.
One unexpected finding: a significant share of users were using the product designer as a free mockup tool — producing high-quality visuals without Photoshop. Non-converting funnel traffic was getting real value and coming back. It became one of the platform's most effective acquisition hooks.
Key Design Decisions
Five decisions that shaped the final architecture
02
Provider ratings: from a single score to a competitive engine.
The early proposal was a simple 5-star aggregate. A single number collapses different value propositions into one score — a fast, cheap provider and a slow, premium one rate identically, removing the differentiation that makes a marketplace worth using.
I proposed a multi-dimensional model instead — Quality, Production Speed, Samples & Shipping — drawn from user interviews and CS ticket analysis showing these were the attributes merchants used when making sourcing decisions. Three arguments framed the pitch for the business: healthy provider competition, merchant segmentation, reduced support load from mismatched expectations. It took a few weeks to work through. The model shipped and is still in use today.
The tradeoff: once the multi-dimensional model shipped, future changes had to maintain all three dimensions or break the mental model merchants had built. A simpler system would have given us more flexibility; the multi-dimensional one gave merchants more honest information.
A rating system that collapses quality, speed, and cost into one number doesn't help merchants make decisions — it just tells them someone else already did.
03
Scope discipline: what I made the case to cut.
Aggressive cuts in what the product would carry — blog, notifications, the insights page, multiple settings pages, account-merger and account-switching flows, the full public website beyond how-it-works and the catalog. The bet: a smaller surface held well would outperform a larger one held thinly. Merchants never asked for the cut sections. Scoping under pressure often reads as the weaker form of design work. Here, it produced the durability.
04
A single designer interface that adapted to 200+ product types.
The instinctive solution was multiple interfaces — one for DTG, one for sublimation, one for embroidery, one for large-format. Familiar pattern, easier to ship per-category, lower coordination cost between teams. I argued against it: every new product category would then require its own design, engineering build, and merchant re-learning. Two months in, we'd have shipped three interfaces and three sets of edge cases. The single attribute-driven interface was harder to ship — it forced internal workshops to map attributes for products that didn't yet exist — but it absorbed the next 170+ products without redesign. The cost was the upfront speed: V3 and V4 took longer than they would have if I'd shipped per-category interfaces first.
05
Creation and editing aren't the same mental task — and the same data shouldn't show up the same way in both. A merchant creating their first product is making sequential decisions: designer choices lock before mockups become useful, mockups before pricing, and so on. A merchant editing an existing product already knows what they made and is looking for one specific thing to change. A single shared pattern would either overwhelm the first merchant with 100+ variant decisions on one screen, or slow the second by forcing re-navigation through stages they don't care about.
So I split the patterns by state: tabs on the creation flow, linear scroll on edit. Tabs gave each creation stage its own attention space and matched Shopify's product editor, which most merchants already knew. The scroll on edit let returning merchants reach any field directly. The cost was a deliberate inconsistency — the same product carries two interfaces depending on whether it's being made or changed — and more engineering than a single shared pattern. We took both costs because matching pattern to mental state mattered more than visual uniformity across surfaces.
The Impact
Why the numbers moved.
The deeper insight surfaced months later. Cohort data revealed what the sprint hadn't articulated: merchants who spent time customizing individual products converted at significantly higher rates. The reframe wasn't "help merchants understand the marketplace" — it was "help merchants customize for their audience." V5's architecture turned out to be exactly right for that. Principles-led work had built the right product before we'd understood why.
A second pattern emerged from the cohort data: conversions were higher in flows that ended up looking like tools merchants already used — Shopify's product editor, Canva's creation flow. We hadn't set out to mirror them. But iteration toward what worked had landed on what was familiar — for users, familiar and workable are often the same thing.
Key KPI's
The outcomes landed on two national lists. Printify ranked #24 on the 2019 Inc. 5000 with 7,926% revenue growth over 2015–2018. The Financial Times ranked Printify #15 on its 2020 Americas Fastest-Growing Companies list, alongside Tesla, Netflix, and Uber. This case study covers the entry point of that trajectory.
After V5 shipped, alignment sessions with the founder, CS lead, and Merch lead surfaced a shared bottleneck: onboarding new providers was too slow for merchant demand. The admin tool was the constraint. I took it on as a follow-on.
A dedicated admin-panel taxonomy workshop and structured work with the Merch lead (who interfaced with providers daily) shaped the rebuild. I restructured onboarding around a split between Printify-critical and provider-optional information. The system needed to be far more dynamic than I'd scoped: providers regularly ran out of specific variants, and the admin had to reflect stock in near real time.
The rebuild unlocked 85% more providers and 50% more products joining the catalog, with product setup speed through the admin running ~2.5× faster — all without a proportional rise in operational overhead.
Learnings
What I took from this work.
01
The pattern across releases was the real signal
With live traffic, fluctuating KPIs, and weekly releases, the problem wasn't a lack of data — it was separating signal from noise. Single KPI movements were often noise; the pattern across five independent releases was the signal. Reading the pattern rather than the level is how V5 surfaced.
02
The strategic insight emerged after the architecture did
Cohort data surfaced the deeper reframe six months later — but the principles we'd held had already produced an architecture that was right for it. Principles-led work is how you build when you don't yet know the user insight
03
Cross-functional workshops were a coalition tool, not just a research tool
They built the shared ownership across CS, engineering, sales, and merchandising that each weekly ship cycle depended on. Showing KPI movement tied to specific decisions moved the framing from "what are we shipping?" to "what did we learn?" — a different conversation, and the one I wanted to be in.
02
What this taught me about making commercial cases land outside my remit
Two moments during Printify pointed at opportunities beyond design scope: a standalone mockup product we could have spun out from what we'd built, and alternative plans for scaling the design function as the business grew. Neither landed. Results had made the case for the design work itself — but not for a design organization or a new product line. I'd built coalitions around product decisions, not commercial strategy.
Almost a decade later, merchants are still clicking through the flow V5 landed on. Most of what makes a product durable is deciding early what you won't do.