AWS Marketplace self-service listing (CAR)

Role: Solo designer

Timeline: Launched February, 2025

Team: UX designer, 1 dev team, 1PM

Skills: Systems Design, Enterprise UX, Scope prioritization

Turning a 4–6 week manual product listing process into a guided, self-service experience

The self-service product listing (SSL) experience is designed for sellers on AWS Marketplace who list Clusters and Resources (CAR) products — offerings that combine an AMI (Amazon Machine Image) with a CloudFormation Template (CFT). Before this work, listing a CAR product was a completely manual, spreadsheet-driven process that could take a seller 1–3 months to complete.

I led the SSLv2 (CAR) experience end-to-end from problem framing and concept exploration through user testing and launch designing a guided, wizard-based flow that let sellers self-list CAR products directly in the AWS Marketplace Management Portal (AMMP), without waiting on manual review from the Marketplace Catalog Operations (MCO) team. I also designed the self-service listing experience for container products.

To comply with my non-disclosure agreement, any confidential information is omitted in this case study.


The problem

Sellers listing CAR products had to fill out a Product Load Form (PLF), a spreadsheet with a single row and over 4,000 columns and submit it to the MCO team by email. MCO would then manually process the request, often going back and forth with the seller to resolve errors or mismatched data between the AMI and CFT.

In sellers' own words:

"Whenever we need to publish an update for existing listing, we must describe the change in an excel spreadsheet where there is one single row and thousands of columns. It is completely unreadable and unmaintainable."

"It takes several rounds of email back-and-forth to get a new release up. We are extremely concerned that should we require an urgent security update, we would not be able to execute quickly enough."

Three core issues emerged in the seller side listing expereince:

  1. A scattered experience — sellers had to jump between the seller guide, the management portal, the PLF, and direct conversations with MCO just to complete one listing.

  2. A slow process — listing a CAR product took 1–3 months on average.

  3. An unsustainable dependency on MCO — every listing required manual human intervention, which didn't scale as the number of sellers grew.


The solution

SSL replaced the spreadsheet-and-email workflow with a guided, wizard-based self-service flow, built on three key principles:

  • Guided experience — Instead of a 20-page seller guide and a 4,000-column spreadsheet, sellers move through a structured wizard. Once submitted, they can immediately test their "limited" product with their internal team — no need to wait on MCO's review queue to get early feedback and iterate before requesting full publication.

  • Fewer human touchpoints — Sellers can create and manage limited product listings without manual MCO review, supported by automation (e.g., AMI scanning, with CFT scanning planned) that previously required manual processing by Marketplace Product Solutions Architects (MPSAs).

  • Role-based permissions — Sellers can set IAM-based permission policies to control which roles can perform which types of changes, adding governance without adding friction.


Design challenges & leadership

Self Service Listing papercuts

The self-service listing experience is an existing experience in the AWS Marketplace Management Portal. I'm designing and migrating the CAR PLF experience into the self-service flow. During this process, I identified a number of user experience issues and technical limitations in the pre-existing design, most notably the absence of must-have functionality like draft saving and autosave, along with nice-to-have features such as preview and direct logo upload. I documented all the relevant use cases and escalated them to leadership to surface the importance of these gaps. This led to their inclusion as papercuts on the 2026 roadmap, where the majority of these items are now being addressed in the new product listing experience.

Exploring two structural approaches

The self-service listing experience had already shipped for Single AMI, SaaS, and Container listings. This project extended that self-service model to the more complex CAR (multi-artifact) listing type. Except onboard the CAR product to the self-service listing experience from the PLF, I explored two directions for how to structure the wizard experience early in the design process:

  • Option 1 — Single Wizard: All listing steps live inside one continuous wizard flow — consistent with the existing listing experience for other product types.

  • Option 2 — Modularization: Related steps are grouped into separate, smaller wizards rather than one long flow, such as product information, offer details, deployment instruction and features enablement.

‍User testing

I tested both options with 4 sellers. Both structures were navigable, but 3 of 4 sellers preferred the modularized (multi-wizard) approach, for a few consistent reasons:

  • An 11-step single wizard felt like too much pressure to complete in one sitting.

  • Decoupling steps into separate wizards was more flexible for teams where different members owned different parts of the listing.

  • Modularization helped prevent team members from accidentally editing details outside their responsibility.

  • Smaller, grouped wizards left more room to add steps over time while staying within Cloudscape design guidelines.

Based on this feedback, Product and I decided the modularized, multi-wizard approach as the final direction. However, we weren't able to shift from the single wizard to the modularized design due to technical complexity and bandwidth constraints after talking to the tech team. This represented a significant lift from the existing self-service product experience in 2025. I documented this as a P1 item for continuously improving the seller listing experience and advocating for our customers. This has remained a top priority and is currently working in progress in 2026.


Final design


Impact

  • 98% reduction in listing time, from an average of 151.5 hours to under 4 hours.

  • Reduced MCO's manual workload by removing them from the standard listing path, making the process more scalable as seller volume grows.

  • Gave sellers a faster path to publish urgent updates (e.g., security patches) without waiting on multi-week email cycles.

Previous
Previous

Multi-product solutions

Next
Next

AWS Marketplace Local Currency — Seller Disbursement