ICMP Seller
Designing a multi-catalog marketplace listing system for classified government regions.
Iterative Product Development
Cloud Marketplace
about.
Product Design
Enterprise Product Development
Government & Defense
Iterative Product Design
CLIENT:
AWS Marketplace (in-house)
Intelligence Community (ICMP) AWS Team
JWCC / C2E contract for AWS
DURATION:
1 year + 4 months (April 2024 - August 2025)
ROLE:
Senior UX Designer
Acting Product Manager
AWS Marketplace is a digital catalog where customers find, buy/sell, and deploy third-party software, data, and services. As part of the JWCC/C2E defense contract, AWS Marketplace users needed to be able to buy and sell specifically to the AWS Secret Cloud and AWS Top Secret Cloud communities (a.k.a. ICMP, or US Intelligence Community program) for the first time, requiring a new multi-catalog architecture.
As the in-house designer for all Marketplace x Intelligence Community (ICMP) projects and and acting product manager, I spearheaded the ICMP seller experience across 3 parts:
Updating the seller registration process for ICMP users
Creating a multi-catalog switching system that introduced separate catalog partitions for ICMP and EU (ESC) regions
Redesigning the seller disbursement setup to accommodate ICMP-specific currency and payment method restrictions.
*** Note: this project page is currently under construction. Please mind the dust!
context.
Amazon Dedicated Clouds (ADCs) are private, air-gapped cloud regions for government defense and intelligence services — including AWS Top Secret and AWS Secret regions. These networks have no physical or logical connection to the regular AWS commercial network, and each ADC region is isolated from the others. Accessing them requires appropriate security clearances and takes place inside SCIFs (Sensitive Compartmented Information Facilities).
For the US Intelligence Community Program (ICMP), the existing buying and selling experience was 7 years out of date. For the Department of Defense (DoD) — the largest cloud customer in the world — this wasn't just a feature request. It was a contractual requirement tied to the JWCC/C2E defense contract AWS had signed.
The ICMP need
The Intelligence Community needed AWS Marketplace's most current buying and selling features. Their current experience is 7 years out of date and desperately needs a refresh.
The DoD Contract
SaaS product support in classified Secret and Top Secret regions is an existing contractual requirement tied to JWCC/C2E.
The Architecture Gap
AWS Marketplace has only ever had 1 catalog. ICMP required separate catalogs for classified regions — a multi-catalog system that had never existed.
challenges.
The existing seller experience is a largely analog, behind-the-scenes system with minimal progress monitoring built in. To bring product types (AMI, Containers, SaaS, Machine Learning) to classified regions, sellers needed a way to self-service publish listings for ICMP users only. Nobody had designed for this before.
The ICMP seller experience was split into 3 parts under one initiative, each with its own design approval process and implementation timeline. Part 1 covered seller registration, Part 2 introduced the multi-catalog architecture, and Part 3 redesigned the disbursement setup for ICMP and ESC catalogs. All 3 parts passed design approval and were separately implemented into code.
There was no product manager for this effort. I alone figured out the gaps between the accounts/business teams and the engineering team, broke down the requirements, and implemented the design changes that bridged them. As I learned bits of requirements from each team, I built and iterated on designs until there was nothing more to uncover.
The ICMP business analysts (some with security clearances who directly touched the classified systems) and the seller experience engineering teams (supporting old infrastructure with little progress monitoring) had never coordinated before. I became the bridge between them, running recurring meetings with both groups and using my proposed designs as living research artifacts to extract requirements in real time.
content here
part 1: Seller Registration
The standard AWS Marketplace seller registration process requires a seller to register for AWS, register as an AWS Marketplace seller, and list at least 1 product on the commercial marketplace to become an active seller. For ICMP, a seller also needs to already be an active commercial seller, then fill out a separate ICMP seller registration form while simultaneously (offline) meeting with an AWS ICMP business analyst to begin the Foreign Ownership Control and Influence (FOCI) approval process. They have 30 days from submission to receive FOCI approval — otherwise, they have to restart.
I uncovered these exact requirements through tireless recurring meetings with the ICMP business analyst teams and the seller experience engineering teams. The final result was an updated seller registration form for all users, plus a new version for users who want to sell to the ICMP.
Before designing the ICMP-specific form, I updated the existing commercial seller registration form to be current and consistent. This created a clean baseline to branch from for the ADC version.
part 2: Multi-Catalog Architecture.
Previously, AWS Marketplace had exactly 1 catalog: the commercial marketplace, where all products live. To sell to ICMP, AWS Marketplace needed to have 2+ additional catalogs specifically for ICMP and other governmental regions. The European Union (ESC) was the next catalog to add. This was the first time in AWS Marketplace's history that a multi-catalog system existed.
A seller registered to sell to ICMP now needed to manage products across both their commercial catalog and 1+ ICMP catalogs, with the ability to switch between catalogs inside the seller experience.
I designed a catalog-switching dropdown based on an existing Marketplace pattern — a deliberate choice, so I could use design precedent to get buy-in through the design approval process more easily.
I also spearheaded the naming conventions on this dropdown, making sure the names clearly distinguished each catalog context.
Every time a seller navigates to an ICMP catalog, a persistent warning popup appears to confirm which catalog they are currently working in.
The warning popup that appears on ICMP catalog entry was a deliberate design decision. Since there is no way to copy products between catalogs, it's critical that a seller knows exactly where they're listing. I designed this as a persistent, high-visibility modal rather than a dismissible banner.
I worked alongside another designer whose goal was to add new onboarding content to the overall seller registration experience and migrate the existing registration to a new visual style.
I first created the multi-catalog pages in the previous style, and the other designer absorbed my work into his workflow. I was present in his design sign-off reviews to support implementation of my multi-catalog work.
I worked alongside another designer whose goal was to add new onboarding content to the overall seller registration experience and migrate the existing registration to a new visual style. I first created the multi-catalog pages in the previous style, and the other designer absorbed my work into his workflow. I attended his design sign-off reviews to support implementation of my multi-catalog work.
Part 3: ICMP and ESC Disbursement Setup.
After being approved to sell on the commercial marketplace, a seller sets up their disbursement methods a.k.a how they receive money paid by buyers. In ICMP regions, sellers now needed to set up disbursement methods separately for both the commercial and ICMP catalogs. ICMP has strict restrictions: only certain currencies and payment methods are allowed. A seller can roll over payment information from their commercial setup into an ICMP catalog, but not the other way around.
I worked with the ICMP business team and seller experience engineering teams to document exact use cases, error states, and what was technically possible to implement down to the error message copy level. I designed the updated pages, added the additional elements required, and wrote precise language for each error state.
No designer was available to take on the ESA catalog version of these payment setup pages. I was already familiar with the subject matter, so I absorbed that scope as well and pushed both the ADC and ESA design work through the approval process together.
I reused my ICMP work on registration form, multi-catalog, and payments
final design.
(description here)
The full scope that shipped is shown below. I've used Claude, Figma MCP, and Github to create a clickable demo that I've compiled into GIFs below.
The disbursement setup flow now branches based on which catalog the seller is setting up. ADC catalogs surface specific restriction messaging and limit available currencies and payment method types.
design title image 4
full scope here
design title image 5
content here
design title image 6
content here
design title image 6
content here
design title image 6
content here
result.
All 3 parts of the ICMP seller experience successfully passed the design approval process and were separately implemented into code. The multi-catalog architecture I introduced became the foundation for the European Union (ESC) Marketplace partition, which launched shortly after. The system is now documented in AWS product documentation.
Because these features are deployed into air-gapped classified regions, I was not able to view the final implemented feature on an approved user's screen — the designs were handed off to appropriately cleared staff for implementation and verification.
The multi-catalog system I introduced also unblocked the EU (ESA) partition from launching quickly after ADC. What started as a seller registration and payment setup effort ended up reshaping the fundamental architecture of how AWS Marketplace organizes and separates its product catalogs.
learnings.
Requirements live in people, not documents. Neither the ICMP business analysts nor the seller engineering teams had written anything down. The only way to surface requirements was to keep showing up, keep asking, and use my designs as something concrete for both sides to react to.
Design precedent is a strategic tool. Basing the catalog-switching dropdown on an existing Marketplace pattern wasn't a compromise — it was a deliberate choice that accelerated design approval and reduced pushback from a team that already had their hands full.
Absorbing adjacent scope protects the whole. Taking on the ESA payment pages when no one else was available wasn't in my original scope, but leaving them undesigned would have created a gap in an already complex launch. Knowing when to expand and when to hold is its own skill.
Some work ships without confirmation. Not being able to view the final implementation due to clearance restrictions is a genuinely new experience. The designs had to be right before they left my hands — there was no opportunity for feedback from the live environment.
