B-Stock Solutions

Simplifying the Seller Experience

Restructuring the product architecture to create a seamless user experience and unlock future business growth

person

role

Product Design Intern

access_time_filled

timeline

10 Weeks (Jun. - Aug. 2024)

work

skills

Design Systems, Product Architecture, Prototyping, Storytelling

group

team

2 Product Managers, 3 Product Designers

brush

tools

Figma, Figjam, Lucidcharts

overview

My internship at B-Stock, a B2B marketplace that digitizes the selling of overstock inventory for major companies (imagine eBay for Costco), began with a seemingly straightforward task: designing the user flow for a new "Contracts" product.

However, this task quickly uncovered a bigger problem. The platform was built on 3 separate products (Auctions, Offerings, and now Contracts), which created a confusing seller experience and technical debt. Adding a separate Contracts product would worsen these issues.

This realization prompted my project to pivot from a single feature to a full-scale strategic redesign. I worked closely with product, engineering, and design teams to redesign the platform's core architecture, merging 3 fragmented products into a single cohesive framework that creates a seamless experience for sellers and supports long-term growth for B-Stock.

the challenge

background

B-Stock provides a B2B marketplace for buying/selling liquidation and overstock goods.

While B-Stock was growing and building new features, the underlying product structure soon presented some major challenges. The platform was divided into 3 separate products: Auctions, Offerings, and Contracts. This fragmentation created inefficiencies for both the sellers using the platform and for B-Stock's internal teams.

Auctions

Buyers place bids on the listing for a one-time inventory. Winners are decided automatically.

Offerings

Buyers submit offers on the listing for a one-time inventory. Winners are chosen by the Seller.

Contracts

Buyers submit bids on the listing for a recurring inventory. Winners are decided automatically.

problem for sellers

When a seller wants to list and sell their inventory, they first have to understand the 3 distinct product types and choose the one that best fits their needs. This caused:

Decision Paralysis

Uncertainty about which product best suited their inventory

Wasted Effort

Time spent learning multiple, slightly different workflows

While each product catered for different needs, their separation as distinct systems meant that sellers had to navigate and keep track of different workflows, leading to confusion and a disjointed user experience.

problem for b-stock

Internally, each product had its own separate codebase. This resulted in inefficient workflows that slowed the pace of innovation.

Exponential Work

Any new feature, minor update, or bug fix had to be designed, developed, and tested 3 times

Slower Dev Cycles

The need to replicate work across 3 systems delayed the launch of new, valuable features for our users

While this structure worked when there were fewer products and features, it was now no longer scalable.

the solution

first attempt

To implement Contracts, the most obvious solution was to treat it as a 3rd, separate product, replicating the old platform's structure.

However, in early planning sessions with product managers, it became clear that this approach would only worsen existing problems with the overall architecture.

This prompted us to take a step back and ask a more fundamental questions: What is a "listing" at its most basic level?

new mental model

The answer to this question was our AHA moment. Instead of thinking in terms of separate products (Auctions, Offerings, Contracts), We could define any listing using 2 simple, independent properties:

Listing Type

Does the inventory ship once (Spot) or on a recurring basis (Contract)

Sales Method

Do buyers compete via open bidding (Auction) or submit private proposals (Offering)

This new mental model reframed the 3 separate products as combinations of these settings. A classic "Auction" was now a "Spot Auction." A "Contract" was a "Contract Auction." This model also revealed the possibility for a new product, "Contract Offerings," with almost no additional architectural complexity.

With this new mental model, sellers could simplify their workflow. The confusing choice between 3 products was replaced with a clear, 2-step decision:

First, they decide on the Listing Type: Is this a one-time sale or a recurring one?

Second, they choose a Sales Method: Do they want an open auction or private offers?

This new perspective was the key to solving some of the biggest challenges of a fragmented system. It provided a clear path towards a unified codebase for B-Stock, along with a simple, cohesive experience for sellers.

bringing the vision to life

setting up the general listing

With this new mental model established, the primary design challenge was to translate this concept into a simple and intuitive interface. The goal was to guide the user down the right path from the very beginning.

The new listing flow begins when a seller makes their 1st key decision: choosing between a Spot (one-time) or Contract (recurring) listing. This selection then prompts a modal where they make their second key choice, an Auction or Offer sales method, and fill in other initial details.

This sequential flow was intentionally designed to reduce cognitive load. By breaking down a single large decision into 2 smaller, more manageable steps, we created a guided experience that builds sellers' confidence.

iterating on a key detail - contract terms

Once these core choices were made, the rest of the user's journey would adapt accordingly. For example, if a seller chose a "Contract" listing type, they'd need to provide specific details about the contract's terms.

On the old platform, contract details were entered into messy, unstructured text fields, providing no usable data. To solve this, I had to create a design that balanced user-friendliness, engineering feasibility, and the needs of our internal listing team.

1st iteration

Design Reasoning

My initial design focused on structure and consistency:

Architectural Simplicity

I used a side model for these contract-specific details. This kept the main creation form identical for both Spot and Contract listings, simplifying the overall engineering and user experience

Structured Data

To enable future data analytics, I replaced the old platform's ambiguous free-form text fields with defined numeral inputs and radio buttons

Stakeholder Consistency

To minimize disruptions for our internal listing team, the design collected the same core info they were already used to (contract duration, frequency, and load)

Feedback

This 1st pass revealed some key gaps:

From Engineering

The team noted that specific start and end date values were required for he backend logic to function

From the Listing Team

They pointed out that for many sellers, the exact frequency and load are unknown or flexible at the time of listing

2nd iteration

Design Reasoning

The 2nd iteration focused on incorporating the feedback to add necessary functionality and flexibility:

Meeting Engineering Needs

To satisfy the backend requirements, I added a "Start Date" field. To simplify data entry, the "End Date" was then automatically calculated based on the start date and duration

Adding Flexibility

To address the listing team's feedback, I introduced checkboxes that allow sellers to mark values like "frequency" or "load" as unknown when necessary. I also added optional notes fields to give them space for important context

Feedback

This version was much closer, but usability testing the the listing team revealed 2 remaining workflow issues:

Rigid End Dates

They noted that contract end dates sometimes needed to be manually edited and don't always align perfectly with the duration

Limited Frequency Options

The predefined frequency options (e.g. weekly, monthly) weren't flexible enough for all seller scenarios

3rd iteration

Design Reasoning

The 3rd iteration incorporated the last pieces of feedback to create a robust and flexible design:

Complete Date Flexibility

To give the listing team the control they needed for non-standard contracts, I made the start date, duration, and end date all independently editable. This ensures the tool can handle any negotiated timeline

Flexible Frequency Definition

To solve the issue of rigid frequency options, the final design allows users to define both the quantity and the time period (e.g. "3 shipments" per "2 months"). This solution is flexible enough to accommodate any possible seller scenario

This final design successfully balanced the business's need for structured data with the flexibility required by our internal users

achievements

impact

While the full implementation was scheduled to begin after my internship, the new framework and designs I delivered still had an immediate and clear impact:

Shaped Company-Wide Strategy

My final presentation, which introduced the new unified model to the company, was so successful that the Head of Marketing adopted my slides for official internal material for explaining the platform's new vision. This demonstrated the clarity and power of the new concept

Accelerated Future Development

By redesigning the architecture to eliminate redundant codebases, this was projected to significantly reduce future development effort. The new model also paved the way to launch new product types (like Contract Offerings) with minimal additional architectural work

Simplified the Seller Experience

The new unified framework and the initial flows I designed laid the essential groundwork for a simplified, cohesive seller experience. This directly addressed the user confusion and fragmentation that had challenged the previous platform, and made it easier for B-Stock to explain and market the product to potential customers

Contributed to Design System

To support the new, unified designs, I contributed several new and updated components to B-Stock's design system. This work helped ensure that future designs would be built consistently and efficiently by the team

reflection

learnings

thrown into the deep end

With other designers occupied with other projects, I became the point person for designs despite being just an intern. During my first week, I was initially overwhelmed by the responsibility of meeting with senior stakeholders. However, with my manager's encouragement, I quickly found my footing. This experience taught me to trust my design instincts, advocate for my decisions, and transform a challenge into a significant opportunity for growth.

designs as a tool for clarity

In early meetings with product managers and engineers, I was hesitant to contribute beyond taking notes. The turning point came when I started creating simple lo-fi wireframes during discussions to visualize ideas in real-time. This simple act transformed my role from a passive observer to an active facilitator, using design to anchor conversations and foster true collaboration

lessons from the finish line

Towards the end of my internship, I was entrusted with the design handoff to engineering while the other designers were away. Answering their specific, technical questions was a crash course in what truly matters for implementation. This taught me the importance of meticulous documentation and how to bridge the gap between a design file and a final product.