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 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 experience, listing a CAR product was a completely manual, spreadsheet-driven process that could take a seller 1–3 months to complete.

I led the SSL CAR end-to-end experience 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.

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 CAR listing experience:

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.

Who are the users?

• AWS Marketplace sellers who list CAR products on AMMP

  • CAR sellers will be delighted by this experience considering their focuses on being able to quickly and easily list and deploy CAR products to buyers on Marketplace.

• AWS Marketplace MCO team:

  • MCO will be delighted by this new self-service experience considering their focus on being able to smoothly onboarding sellers onto the AWS Marketplace platform and satisfying their needs.

About the self-service listing experience

The self-service listing experience is an existing single wizard framework within the AWS Marketplace Management Portal, already supporting product types like Saas, Server and AMI. I'm designing and migrating the CAR PLF experience by using the wizard framework.

Self-service listing 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.

Research & discovery

Exploring two structural options

Before leveraging the existing self-service listing framework for the CAR product, I interviewed 4 sellers, along with Business Development (BD) and the Marketplace MCO team, to gather their thoughts and feedback on the current wizard listing experience. A recurring theme from this research was that the single 11-step listing wizard felt too long and overwhelming. However, sellers actually preferred a multi-step wizard format, since it allows different team members to complete their respective tasks independently, without depending on other teams to finish theirs first, such as the marketing team can work on providing the product information section, finance/offer team can provide pricing/offer options and IT can provide deployment guidance to complete the product listing on Marketplace.

To skip the existing self-service listing framework and design a new listing experience for CAR will be a huge lift from the resource perspective. So 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 single 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 5 sellers. Both designs were navigable, but 4 of 5 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, UX, and the dev team aligned on moving to a modularized, multi-wizard approach as the final direction for the CAR product type, with plans to migrate other product types to this modularized (multi-wizard) approach in the next year's planning. However, after the dev team completed their technical investigation, we weren't able to shift from the single wizard to the modularized design due to technical complexity and bandwidth constraints. This new design represented a significant lift from the existing single-wizard self-service experience, and we wouldn't have been able to launch the experience on time if we built out the modularized version — especially since the single wizard already addressed the core listing issues for our sellers. We decided to ship the single wizard for CAR, and I documented the modularized experience 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.

Self Service Listing papercuts

During this process, I also 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.

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

• Eliminated wait times for new version requests, previously at 46.6 hours