ONE BISON

Bringing structure to a product in transition

Bringing structure to a product in transition

Designing a two-sided marketplace while improving workflows, consistency, and implementation across an evolving product.

Designing a two-sided marketplace while improving workflows, consistency, and implementation across an evolving product.

One Bison — B2B Marketplace

UX Designer

Team:

Product manager
Engineering
QA

Focus:

End-to-end workflows
Responsive UX
Design system
Engineering collaboration

Directory to marketplace

Before:

Before:

Discover company

Company profile

External vendor site

Now:

Now:

Seller onboarding

Products

Payments

Orders

Buyer discovery

Products

Cart

Checkout

Delivery

The UX challenge grew faster than the original product foundation.

The UX challenge grew faster than the original product foundation.

The existing reality — I wasn’t starting with a blank canvas

01

Live production UI

02

Older Figma designs

03

Previous developer-built pages

04

New e-commerce designs

Multiple sources → one live customer experience

Multiple sources → one live customer experience

Before changing the product, I needed to understand what already existed.

Before changing the product, I needed to understand what already existed.

My role — Feature-level and system-level ownership

My role — Feature-level and system-level ownership

I wasn’t only producing screens. I was connecting requirements, workflows, reusable patterns, and implementation.

I wasn’t only producing screens. I was connecting requirements, workflows, reusable patterns, and implementation.

PRODUCT

PRODUCT

Map buyer and seller workflows
Design new experiences
Handle states and edge cases

SYSTEM

SYSTEM

Audit existing patterns
Create reusable components
Improve visual and behavioral consistency

DELIVERY

DELIVERY

Work with Engineering and QA
Clarify requirements
Review implementation

Prioritization — I couldn’t fix everything at once

Prioritization — I couldn’t fix everything at once

User impact × Business urgency × Technical dependency

User impact × Business urgency × Technical dependency

Solve now

Solve now

Launch-critical workflows and blockers

Standardize while building

Standardize while building

Forms, statuses, validation, reusable UI patterns

Improve later

Improve later

Lower-impact legacy inconsistencies

Designing forward without waiting for every answer

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

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

Vendors were already managing product information elsewhere. Asking them to recreate and maintain the same information again created unnecessary work.

WHAT WE KNEW


  • Sellers needed multiple ways to add products

  • Manual entry still mattered

  • Shopify should remain optional

  • CSV was useful

  • Sellers should choose which products to import

  • Existing product-management patterns should be reused

WHAT WAS STILL UNKNOWN


  • Some inventory behavior

  • Variants

  • Multiple inventory locations

  • Sync ownership

  • Some technical integration details

  • Product-feed feasibility

We separated stable user needs from unresolved implementation decisions.

From ambiguity to prioritized work

The marketplace isn't one screen — it's a chain, and trust has to survive every link. I designed each step to answer the question a first-time buyer is actually asking at that moment.

The marketplace isn't one screen — it's a chain, and trust has to survive every link. I designed each step to answer the question a first-time buyer is actually asking at that moment.

NOW / HIGHEST

Product-entry methods
Shopify selection + connection states

Product-entry methods
Shopify selection + connection states

NEXT / HIGH

Inventory review
CSV-assisted import

Inventory review
CSV-assisted import

LATER / MEDIUM

Buyer explainer
Tutorials

Buyer explainer
Tutorials

BLOCKED / FUTURE

Product feed

Product feed

Design what is known. Document dependencies. Don’t invent answers to unresolved technical questions.

Design what is known. Document dependencies. Don’t invent answers to unresolved technical questions.

Catalog solution — Start with what we could confidently solve

Catalog solution — Start with what we could confidently solve

Catalog solution — Start with what we could confidently solve

Foundation → Building → Mastery

Screen 1 — Add Products

Manual / Shopify / CSV / Future product feed

Give sellers multiple paths without forcing one workflow.

Give sellers multiple paths without forcing one workflow.

Screen 2 — Connect Shopify

Explain the value and preserve user control before asking for a connection.

Explain the value and preserve user control before asking for a connection.

Screen 3 — Select products

Connection does not mean automatic publication. Sellers choose what they submit.

Also open-ended, but each entry is a pattern rather than a noun — sentence endings, connectors, particles. Needed the same browsing model with room for explanation.

THE TRANSACTION LIFECYCLE

The marketplace isn't one screen — it's a chain, and trust has to survive every link. I designed each step to answer the question a first-time buyer is actually asking at that moment.

The marketplace isn't one screen — it's a chain, and trust has to survive every link. I designed each step to answer the question a first-time buyer is actually asking at that moment.

  1. CART: Who am I buying from?

  1. CART: Who am I buying from?

Seller named above the line items, with a plain statement that the order ships directly from them.

  1. CHECKOUT: Is this safe, and what's the real total?

  1. CHECKOUT: Is this safe, and what's the real total?

Guest checkout with an account-found prompt, itemized costs, Stripe and buyer protection under the button.

  1. CONFIRM: Did it work, and what now?

  1. CONFIRM: Did it work, and what now?

Order number, ship-from seller, and a route into order history so the purchase creates an account relationship.

  1. POST-PURCHASE: Where is it, and who helps if it's wrong?

  1. POST-PURCHASE: Where is it, and who helps if it's wrong?

Delivery stepper, tracking, confirm-delivery, and an explicit “Report a problem” path — the backbone of buyer protection.

PRE-LAUNCH MOMENTUM

Business growth is building ahead of the marketplace launch.

Business growth is building ahead of the marketplace launch.

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

The commerce experience is currently in development.

The growth above reflects One Bison's existing business and pre-launch marketplace momentum—not post-launch commerce performance. My work focuses on designing the seller, discovery, checkout, payment, and post-purchase experiences that will support this growing ecosystem when transactions go live.

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