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.
WebCommander lets merchants run everything from inventory to multi-channel selling on one platform, and its marketplace is where that platform grows: plugins that add functionality, templates that skin the whole storefront. A merchant browsing that marketplace is a store owner, not a developer, and the gap between "I found a plugin I want" and "it's live on my store" is where most of these systems lose people.
I designed both sides of that gap: the customer-facing purchase flow across the plugin and template marketplace, and the backend UX for installing, configuring, and managing what a merchant has bought, once it lands inside their store admin.
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.
Purchase and install felt disconnected
- Buying a plugin didn't clearly lead into setting it up
- Merchants didn't know if a purchase had actually activated
- Configuration lived in a different part of the admin entirely
Non-technical merchants, technical decisions
- Plugin settings used developer language, not merchant language
- Template previews didn't match what installing one would actually change
- Wrong settings could break a live storefront with no warning
Two flows, one trust
- Browsing plugins and templates needed to feel curated, not a raw list
- Managing what's already installed needed the same clarity
- One inconsistency between the two and merchants stop trusting both
Goals
- Carry a merchant straight from purchase into a working install
- Translate plugin and template settings into merchant language
- Make it obvious what's active on a store versus what's just been bought
- Keep the marketplace and the admin backend feeling like one system
Research
- Most support tickets traced back to a setting merchants didn't understand
- A good default beats an accurate but confusing option every time
- Merchants wanted to preview a template against their own products, not a demo store
- Trust in the marketplace was really trust in the storefront, and vice versa
Strategy into
interface
Marketplace browse & purchase
Plugins and templates organized by category with clear pricing and a detail page that shows exactly what a merchant is buying, ending in a purchase flow that hands straight off to setup.


Install &
configuration UX
The backend flow for activating a plugin on a live store: sensible defaults, settings written in plain language, and a clear confirmation once it's actually running.
Template preview
& activation
A preview flow that shows a template against the merchant's own store before they commit, then a one-step activation once they've decided.

- 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
- Support tickets are a research source hiding in plain sight
- A marketplace and the product it sells into are one trust relationship, not two
Conclusion
Buying a plugin used to be where the easy part ended. Designing the purchase flow and the backend install UX as one continuous path meant a merchant could go from browsing the marketplace to a live, configured feature on their store without a support ticket in between.