A marketplace
merchants trust
WebCommander is an all-in-one ecommerce platform, and its marketplace is where merchants extend their store with plugins and templates. I designed the backend UX for installing and configuring them, and the front-end purchase flow merchants use to buy and activate them.
Buying is easy.
Installing rarely is.
A merchant can find a plugin in minutes. Getting it actually working on their live store, without breaking anything, is where most marketplaces hand them off to a support ticket. I designed both sides of that gap: the purchase flow across the marketplace, and the backend UX for installing and configuring what a merchant has bought.
Purchase and install felt disconnected. Buying a plugin didn't clearly lead into setting it up, and merchants had no way to tell if a purchase had actually activated.
Non-technical merchants, technical decisions. Plugin settings used developer language, template previews didn't match what installing one would actually change, and wrong settings could break a live storefront with no warning.
Two flows, one trust. Browsing needed to feel curated, managing what's already installed needed the same clarity, and one inconsistency between the two cost trust in both.
My role & process
Product designer on the marketplace, working with product management and engineering across both the storefront and the admin backend.
- 01
Discover
Merchant workflow mapping and a support ticket review. Most tickets traced back to a setting merchants did not understand.
- 02
Define
A competitor marketplace audit and a new information architecture joined browse, purchase, and install into one path.
- 03
Design
The purchase flow, backend install UX, and template preview designed as one continuous journey, from browsing to a live feature.
- 04
Ship
A live marketplace used by merchants, with the marketplace and backend working as one system.
What research showed
Merchant workflow mapping, support ticket review, competitor marketplace audits, and information architecture work all pointed the same way: most tickets traced back to a setting merchants didn't understand, a good default beats an accurate but confusing option, and trust in the marketplace was really trust in the storefront.
Strategy into interface
Key decisions
- 01
Purchase flows straight into install
A purchase is not finished until the thing bought is running. Buying a plugin hands off directly to setup, with a clear confirmation once it is live.
- 02
Settings in merchant language
Good defaults do more for non-technical users than documentation. Settings are written in plain language, with defaults that work out of the box.
- 03
Preview on the merchant's own store
Merchants wanted to see a template against their own products, not a demo store. The preview shows exactly what activating it will change.
Learnings
A purchase isn't finished until the thing bought is actually running. Good defaults do more for non-technical users than good documentation ever will, and support tickets are a research source hiding in plain sight, a marketplace and the product it sells into are one trust relationship, not two.