Work / Mobile-Native B2B Workspace for High-Volume Merchants

Bringing the power of a full seller workspace to mobile.

Overview
Ezze is a multi-channel B2B platform blending live auctions with traditional retail. We previously built the web-based Seller Dashboard (SDB) to centralize inventory and bulk logistics for our high-volume merchants.

My ResponsibitliyAs Lead Product Designer, I drove the 0-to-1 execution of the Seller Hub, a new mobile-native workspace for sellers. My core focus was translating complex B2B web workflows into a streamlined mobile architecture built for on-the-go use.
Role
Lead Product Designer
Team
Product Manager, Engineering, Sellers

Timeline
2025








Challenge

As merchants expanded into offline events, the web dashboard became a liability. Managing inventory and fulfilling orders on-site required a laptop but most sellers did not have.
Why it mattered?

>60% of high-volume merchants were actively expanding into offline events.
2-3 hours of manual data entry were spent post-event reconciling offline sales without mobile access.
15% increase in inventory discrepancies occurred due to the lack of real-time syncing





The Strategy: Why an Integrated Hub?

Embedding the hub was the only decision that worked across all three dimensions simultaneously.

Should the Seller Hub be a standalone app, or should it live inside the existing consumer app? A standalone app was the obvious path. Separate product, separate experience. I pushed back on it, and aligned Product and Engineering around building inside the existing app instead. Three reasons drove the decision:
UXA second app compounds onboarding friction. Estimated 40 to 60% drop-off before first use.
ProductSellers come from the buyer base. Approval unlocks the workspace inside an app they already use.
EngineeringReusing existing infrastructure saved an estimated 4 months of development time.




The Execution: Where Does the Hub Live?

The center tab was the right call. One tap, highest visibility, zero disruption to the consumer experience.






The Internal Logic: What Goes Inside the Hub?

Not everything on the web belonged on mobile. The data told us exactly what did.

With the entry point settled, the next question was harder: which SDB features actually belong on mobile? Porting everything would recreate the same product that was already failing sellers on small screens. I needed evidence to make the prioritization defensible.

#1 Quantitative Analysis
Partnering with the PM, I analyzed mobile web traffic during weekend hours. The data revealed a clear pattern: sellers were attempting to use the SDB on mobile during events, and abandoning it entirely.


#2 Qualitative Analysis
To understand why, I ran contextual inquiries with high-volume sellers at weekend conventions, observing their workflows on the event floor. Three barriers came up consistently across every seller I spoke with.



ConclusionAcross all three sellers, the research surfaced three distinct operational gaps:
  1. No mobile method to schedule or manage live shows on the event floor.
  2. A fragmented cross-device workflow that made listing new inventory during events nearly impossible. 
  3. No reliable system for local pickup verification, forcing sellers to rely on paper notes. 




The Strategic Pivot: Action over Administration

Merchants needed to execute, not administrate.

The Seller Hub was not a mobile version of the SDB. It was a focused tool for one specific context: the event floor. To map out the full feature scope, I built an information architecture that defined what lives in the Seller Hub and where.

Executive Tier (Purple)High-velocity, hardware-dependent tasks that need to happen on the event floor.
Management Tier (Grey)Available when needed, but not competing for attention during high-pressure moments.Side MenuAdministrative functions accessible on mobile only when necessary.





Redesigning the Critical Path

With the Information Architecture validated, I mapped three user flows for the Executive Tier, ensuring each operational gap had a direct, hardware-native solution.






Wireframes

To validate the Information Architecture before high-fidelity design, I translated each Executive Tier flow into mid-fidelity wireframes, focusing on page structure, field hierarchy, and interaction states.






Design System

The Seller Hub extends the SDB's design system rather than replacing it. Sellers use both products, and visual consistency across typography, color, and components removes the need to relearn the interface.

RetainedColor, typography scale, and component language carried over directly. Brand purple, functional colors, and status colors remain consistent across both products.AdaptedTouch targets were adjusted to meet mobile standards. Forms moved from multi-column grids to single-column linear layouts. Navigation shifted from a web icon sidebar to a bottom tab structure with page-level hierarchy.


*Seller Dashboard, Add Product*




Final Design



*Seller Hub Flow*


#1 Schedule a Live Show Required fields gate the Schedule action. Additional Info and Go Live are only accessible after scheduling, ensuring sellers commit to a time before optimizing their broadcast.


*Schedule, Default*



*Schedule, Filled*

*Schedule, Addtional Info*





*Quick Add, Default*



*Quick Add, Filled*
#2 Quick Add One photo triggers AI recognition and auto-populates all required fields. Memory surfaces recently used inputs. Sales channel and tag are optional, keeping the critical path short.



#3 Fulfillment Pickup Orders surface automatically in the Ready for Pickup feed. Code verification gates the status change. The verified code is logged on each order card, replacing paper notes with a permanent digital record.


*Fulfillment, Ready for Pick-up*



*Fulfillment, Enter Code & Confirm*


*Fulfillment, Picked-up*





Early Validation

The three merchants from the original contextual inquiry were invited back to test the high-fidelity prototype. The goal was to confirm that the Action over Administration framework held up under simulated event conditions.

#1 Schedule a Live Show 
All three sellers completed the required info and confirmed scheduling in under 20 seconds. They noted that separating Required Info from Additional Info removed the pressure of having to prepare everything upfront, letting them lock in a show time first and fill in promotional details when the booth was less busy.

#2 Quick Add 
Sellers responded positively to the AI Recognizing indicator, understanding immediately that the system was processing the image. The ability to publish a product first and assign a sales channel later matched how they actually make decisions at a live event.

#3 Fulfillment Pickup 
All three confirmed the code verification flow was faster and more reliable than their existing paper note system.





Current status

The Seller Hub is in active engineering sprints with a full launch scheduled for Q2. My role has shifted to Design QA, ensuring hardware integrations and high-velocity interactions maintain the precision established in the final design handoff.



Expected Impact

The Seller Hub has not yet launched. Based on the operational gaps identified during research, the following outcomes are projected for the first month of live operations.

~0 hrs
Post-Event Reconciliation

Real-time sync via Quick Add eliminates manual re-entry after every event.
15% 0
Inventory Discrepancy  

Mobile input at the point of sale closes the gap between booth sales and system records.
100%
Fulfillment Verification 

Every local pickup verified by code, creating a permanent digital record for every transaction.




Reflection

#1 Shifting from Web to Mobile Thinking 
The biggest mental shift was learning to design for interruption rather than focus. Web workflows assume a seated user with time and screen space. Mobile assumes the opposite. Every decision had to be re-evaluated through that lens, from information density to the number of taps required to complete a task.

#2 Designing with Justification 
This project pushed me to articulate the reasoning behind every decision, not just what was built but why, and why the alternatives were ruled out. That discipline made the design more defensible in reviews and more coherent as a system.

#3 Collaboration as a Design Input 
Constant alignment with PM and Engineering was not overhead, it was part of the design process. The decision to embed the hub inside the existing app, for example, only held up because it was stress-tested across UX, product, and engineering perspectives simultaneously.






← Previous projects
Back to Top

Next project →