ONE BISON

Turning a business directory into a transaction-ready marketplace

Turning a business directory into a transaction-ready marketplace

Role UX Designer
Stage Pre-launch commerce
Focus Seller activation · Marketplace UX · Transaction design
Partners Founder · Engineering · QA

One Bison had a growing network of vetted businesses, but no infrastructure for sellers to manage products or for buyers to complete a purchase. I designed the commerce experience across seller setup, product management, discovery, checkout, and post-purchase.

FROM DIRECTORY → MARKETPLACE

Growing seller interest created a new problem: readiness.

Growing seller interest created a new problem: readiness.

One Bison was already attracting businesses that wanted to participate in the future marketplace.
But joining the directory and being ready to sell were two different things.

One Bison was already attracting businesses that wanted to participate in the future marketplace.
But joining the directory and being ready to sell were two different things.

Business joins

Business joins

→

Gets approved

Gets approved

→

Sets up storefront

Sets up storefront

→

Adds products

Adds products

→

Receives orders

Receives orders

→

Manages fulfillment

Manages fulfillment

The design challenge

How could we move businesses through this journey without creating unnecessary setup work, while giving shoppers enough trust to transact with unfamiliar sellers?

THE SYSTEM I WAS DESIGNING

THE SYSTEM I WAS DESIGNING

SELLER

SELLER

Join → Setup → Products → Orders

MARKETPLACE

MARKETPLACE

Approval → Listing → Transaction → Protection

BUYER

BUYER

Discover → Evaluate → Checkout → Track

Problem 1

Sellers shouldn’t have to manage the same catalog twice.

Sellers shouldn’t have to manage the same catalog twice.

Many sellers already manage their products in platforms like Shopify. Recreating and maintaining the same catalog in One Bison adds unnecessary work.

Many sellers already manage their products in platforms like Shopify. Recreating and maintaining the same catalog in One Bison adds unnecessary work.

The user need was clear. The technical solution was still evolving.

The user need was clear. The technical solution was still evolving.

What made it difficult?

WHAT WE KNEW


  • Sellers needed easier product entry

  • Manual entry still needed to exist

  • Shopify should be optional

  • CSV would support additional sellers

  • Sellers should choose which products to submit

  • We should reuse existing One Bison product patterns

WHAT WAS STILL UNCERTAIN


  • Final integration architecture

  • Some inventory-sync behavior

  • Variants

  • Multiple inventory locations

  • Future product-feed feasibility

  • Some technical connection states

I separated stable user needs from unresolved technical decisions.

Decision

Don't wait for the perfect answer.
Design what we know and expose what we don't.

Don't wait for the perfect answer.
Design what we know and expose what we don't.

NOW

1. Product entry methods
2. Shopify connection + product selection

1. Product entry methods
2. Shopify connection + product selection

→

NEXT

3. Inventory review
4. CSV import

3. Inventory review
4. CSV import

→

LATER

5. Buyer education
6. Tutorials

5. Buyer education
6. Tutorials

→

BLOCKED

7. Product feed

7. Product feed

Solution

Step 1 — Choose a method

Multiple paths instead of forcing every seller into one workflow.

Multiple paths instead of forcing every seller into one workflow.

Step 2 — Connect Shopify

Explain the connection and keep the seller in control.

Explain the connection and keep the seller in control.

Step 3 — Select products

Connection ≠ automatic publication

Connection ≠ automatic publication

Step 4 — Upload CSV

A lightweight option for sellers with an existing catalog.

A lightweight option for sellers with an existing catalog.

We could move the seller experience forward without committing to technical assumptions that were still changing.

Problem 2

The product had multiple generations of UI.

The product had multiple generations of UI.

Older Figma files, developer-built pages, and newer e-commerce work had created inconsistent patterns across the product.

Older Figma files, developer-built pages, and newer e-commerce work had created inconsistent patterns across the product.

01

Live production UI

02

Older Figma designs

03

Previous developer-built pages

04

New e-commerce designs

Standardizing the experience without creating unnecessary rework

Not every inconsistency needs the same solution.

Not every inconsistency needs the same solution.

  1. KEEP — Internal functional patterns

  1. KEEP — Internal functional patterns

Broader status colors can help internal teams scan information quickly—as long as each color has a consistent meaning.

  1. FIX — Customer-facing drift

  1. FIX — Customer-facing drift

When the intended pattern already exists in the design system, align the implementation.

  1. DECIDE — Undocumented legacy pattern

  1. DECIDE — Undocumented legacy pattern

Determine whether the pattern should become part of the system or be phased out.

Consistency doesn’t mean making everything identical. It means making patterns intentional, predictable, and reusable.

Problem 3

Requirements describe the transaction.
Users experience everything that can go wrong.

Requirements describe the transaction.
Users experience everything that can go wrong.

The main transaction was straightforward. The complexity appeared in the states around it.

The main transaction was straightforward. The complexity appeared in the states around it.

Define exception and recovery states while mapping the workflow—not after development.

Define exception and recovery states while mapping the workflow—not after development.

Solution

01

Cart changed

02

Seller application / incomplete status

03

Order tracking / delivery confirmation

04

Report a problem/dispute

The successful path is only one product state.

Recovery is part of the experience too.

PRE-LAUNCH MOMENTUM

Business growth is building ahead of the marketplace launch.

Business growth is building ahead of the marketplace launch.

6×

6×

Growth in business signups

Growth in business signups

+32%

+32%

Growth in engaged sessions

Growth in engaged sessions

+45%

+45%

Growth in search usage

Growth in search usage

What commerce success means
Seller activation → published inventory → checkout conversion → completed orders

These are pre-launch business signals, not results caused by the commerce UX. They showed that One Bison was entering launch with growing seller and buyer interest—and made activation, discovery, and transaction readiness increasingly important.

Designing the marketplace to be AI-ready

Designing the marketplace to be AI-ready

I wouldn't add AI simply to make the product feel more advanced. I looked for moments where it could reduce effort while keeping users in control. Each concept follows the same principle: AI can draft, recommend, or explain—but users verify consequential decisions.

I wouldn't add AI simply to make the product feel more advanced. I looked for moments where it could reduce effort while keeping users in control. Each concept follows the same principle: AI can draft, recommend, or explain—but users verify consequential decisions.

AI-assisted product listing

Store URL → AI drafts product data → seller reviews/edit → seller publishes.

Store URL → AI drafts product data → seller reviews/edit → seller publishes.

Augmentation, not automation

Augmentation, not automation

Intent-aware discovery

Natural-language request → matching products → visible reasons → editable filters.

Natural-language request → matching products → visible reasons → editable filters.

Explain recommendations

Explain recommendations

Post-purchase assistance

AI handles status questions → confidence/fallback → human handoff for refunds, money, or disputes.

AI handles status questions → confidence/fallback → human handoff for refunds, money, or disputes.

Escalate high-risk actions

Escalate high-risk actions

WHAT I'D DO DIFFERENTLY

Instrument before redesigning

I designed the signup funnel before reliable event tracking existed. Next time, I would establish baseline events before making major flow decisions so that prioritization is grounded in behavior rather than persuasion.

Design for the commerce model, not today's edge case

My first checkout assumed one seller per order. Supporting multi-seller transactions later introduces split shipping, payouts, and order-status complexity that would have been easier to model earlier.

Talk to sellers sooner

The onboarding flow relied heavily on existing team knowledge and competitive patterns. Earlier seller interviews would have helped me validate which setup fields actually created the most friction.

Next case study

Designing game-based learning for kids with short attention spans

Designing game-based learning for kids with short attention spans

Designing game-based learning for kids with short attention spans

View Case Study

View Case Study