Private Marketplace
Rebuilding an outdated marketplace governance web experience from the ground up.
Iterative Product Development
Governance & Purchasing
Product Design
Full Redesign
Government
Iterative Product Design
CLIENT:
AWS Marketplace (in-house)
Intelligence Community (ICMP) AWS Team
JWCC / C2E contract for AWS
DURATION:
1 year + 3 months (March 2024 - June 2025)
ROLE:
Senior UX Designer
GITHUB:
Private Marketplace (PMP) is a feature of AWS Marketplace which enables administrators inside organizations to build customized catalogs of pre-approved products for their users to purchase.
AWS's portion of the JWCC/C2E contract enabled Intelligence Community (ICMP) users to purchase Marketplace products strictly through PMP, which required an entire PMP redesign and migration into the AWS Marketplace console.
As the sole in-house designer responsible for all 3 ICMP x Marketplace initiatives , I transformed PMP from an outdated web experience into a Cloudscape-compliant console product. I took on a scope that turned out to be 2-3x what was originally stated, while juggling the other 2 initiatives (ICMP Seller and ICMP Buyer Audit) at the same time. After nearly a year and 5+ design approval sessions, the new console experience launched and is currently live.
AWS Marketplace is a curated digital catalog that customers can use to find, buy/sell, deploy, and manage third-party software, data, and services to build solutions and run their businesses.
Private Marketplace (PMP) is a feature of Marketplace that enables administrators inside organizations to build customized catalogs of pre-approved products for their users to buy.
context.
Private Marketplace (PMP) lets designated administrators inside buyer organizations build customized catalogs of pre-approved products in AWS Marketplace. This governance uses the framework of AWS Organizations, which enables central governance and consistent management of your AWS resources across multiple accounts and AWS services.
This strict enforcement of central governance is the reason that the ICMP (Intelligence Community) chose AWS to purchase products through, and why PMP is so essential to their purchase story.
The JWCC/C2E defense contract specifically requires that Intelligence Community (ICMP) users purchase AWS Marketplace products through the PMP experience — since governmental entities only want their users buying pre-approved products. But there was a critical problem: PMP existed only on the website version of AWS Marketplace, and ICMP users working inside SCIFs (Sensitive Compartmented Information Facilities) cannot access the public internet. PMP would have to move into the AWS console.
This required a major architectural overhaul of all of AWS Marketplace, and a complete migration for PMP: (see below for before & after)
The key requirements for the Private Marketplace project were:
Migrate the existing experience
ICMP users are required to buy through PMP, but this experience only runs on the Marketplace website which ICMP users can't use in their SCIFs.
The solution: move all functionality to the Marketplace (MP) Console to live amongst all other Marketplace functionality.
List in new region catalogs
At the same time, I was giving sellers the ability to list products in different region catalogs (commercial, AWS Secret, AWS Top Secret) — see ICMP Sellers.
PMP admins should be able to pre-approve products in those specific regions too.
Get ICMP users the newest experience
The PMP experience was 7 years out of date and entirely not Cloudscape-compliant with the newest library release.
We want ICMP users (accustomed to military-grade quality) to enjoy the same up-to-date experience as all commercial customers.
Since we had to migrate and rebuild the entire experience anyway, I took this as an opportunity to completely redesign it — the existing experience was stylistically outdated, non-compliant with the AWS Cloudscape design standards, and full of poorly built pages that had been implemented without any design oversight.
This meant new page concepts, new navigation, new patterns, new design standards.
challenges.
Initially, the Private Marketplace redesign was framed as a straightforward 1-to-1 migration. All I would need to do is reskin a bunch of existing pages and move them to a new subsection in the left navigation. I had 2 other branches of ICMP x Marketplace work awaiting me (including ICMP Seller) so getting this migration effort out of the way should be an easy win, right?
I was so wrong. The scope ballooned in size and complexity into 2-3x the original estimation. The more I dug, the more I discovered that most pages had never had any design input and functioned in inconceivable ways. The entire feature was a confusing black hole of nested pages that defied explanation.
The team had difficulty explaining how their own product worked. Product and engineering were disorganized, didn't have accurate information, and had implemented PMP in ways that required significant investigation to understand. I had to push hard to get enough context to make informed design decisions.
Ex. it took multiple meetings for me to understand that there is a way for the admin to decline a product (when an end buyer requests a product approval but the admin rejects it) vs. a blocked product (when the admin pre-rejects a product from approval requests). These states aren't the same, but they're listed in the same tab in the table. Weird.
The current version of PMP was built almost entirely without designer input, unknowingly using the previous Cloudscape's elements the wrong way. For this redesign effort, the engineering team tried to help me by building their own updated wireframes… also by using new Cloudscape the wrong way. This actually created way more work for me — I had to understand why they made both their initial and new design decisions before I could start my designs.
To resolve this, I pushed back persistently over a period of time to uncover multiple layers of knowledge and used my managers and designer teammates as references to guide them toward correct component usage throughout the project.
Ex. Administrators customize a header for end buyers to denote that the buyer was shopping in the context of their organization. There is absolutely no precedence of this functionality in the AWS Cloudscape guidelines, and there are no guidelines to avoid violating WCAG contrast compliance guidelines. It took months of discussion and workshopping to understand why this came about and what needed to stay.
The original scope was framed as a simple 1-to-1 reskin of 10-15 pages. The actual scope was 2-3x that number of pages, including flows that had never had any design input — product and engineering had simply built them on their own. I discovered these gaps progressively and redesigned them from scratch as I found them.
Ex. The original ask was for me to just reskin the PMP settings page. Instead, I completely redesigned the settings page because I could not leave the page in such an lacking state. I took the effort to understand the page completely to templet-ize it so that future teams can reuse it easily (and I also reused it in my Data Grants redesign too).
part 1: end buyer experience, homepage, getting started.
In the current PMP experience, the end buyer (a user who can purchase under the governance of the organization) is the only user who gets an introductory landing page and a custom header denoting that they're actively being governed. The problem is that all users deserve a landing page, and the header is completely non-Cloudscape-compliant and a WCAG risk.
I reskinned the homepage, compiled multiple states of the new landing page 'My Private Marketplace', and rearchitected the end buyer governance marker into a simple, consistent component.
Previously, only end buyers got a 'Welcome to [experience name]' page that told them they were now shopping under the governance of this organization. Administrators got a temporary 'getting started' introduction page before someone in their org activates PMP and no way to relay announcements.
I introduced a new page — "My Private Marketplace" — as a dedicated starting point for all users. It serves as the place where admins can post special announcements for themselves and others, and users can arrive with context before they start browsing. I convinced the team that users needed this starting point, and it became a standard part of the new experience.
The existing experience had a badly implemented custom header that admins would customize with their company logo and colors. It was not Cloudscape compliant, and there was no way to check WCAG contrast compliance guidelines for the header text against whatever color the admin chose.
After many discussions with the team, I determined this entire header was unnecessary and took it out completely. All the end user needed to know was that they were in a reduced purchasing context — no customization necessary. What I replaced it with was…
I designed a custom purple badge that always states 'Approved for purchase' no matter what org the end buyer is shopping under. I then used the new 'My Private Marketplace' page to house a new widget to preview the custom badge so that end buyers would know what to look for.
I used the same standard badge to denote buy-ability for all subsequent steps in the buying process: from 'My Private Marketplace' to 'Discover products' to the Product Details Page (PDP) and Procurement.
part 2: admin experience.
The admin experience is where most of the complexity lived. I redesigned the left navigation, the main dashboard, multiple wizard flows, and an entire new suite of pages. I also wrote all the help panel content and page descriptions for every page, since 95% of existing pages had none.
I redesigned the left navigation for the entire AWS Marketplace experience to fold in the Private Marketplace pages, revising both navigation systems at the same time.
I took this opportunity to merge some pages and move others to sit within existing pages. The original navigation had grown organically and no longer reflected how users actually moved through their tasks.
I redesigned and cleaned up the main admin dashboard, redesigning the tables to follow all Cloudscape compliance rules with a much higher level of detail.
I refactored the tabbing system in the table, reasoning through why the existing tabs didn't actually work well for how admins needed to find information. I argued that since the same product could be both approved and declined/blocked in the same experience, there was no need for 2 separate tables.
Additionally, I moved the governance details from the PMP settings page. I migrated the bulk update (either add or decline/block) wizard fully into the admin dashboard, merging this functionality with the single add/decline/block wizard as they do the same job.
I designed an entirely new set of pages to track a hierarchical system of changes implemented by admins — something that had never existed in PMP before. I designed this from scratch, including the IA and the individual page designs.
This came from the need for long-term visibility: notifications disappear after 5 seconds, and now they have a place to go. Admins needed visibility into what had changed, when, and by whom.
Revamped wizard flows
I revamped multiple wizard flows to follow Cloudscape guidance precisely, use cleaner language. I also merged certain wizard flows that served similar enough purposes to warrant combination. These flows had originally been implemented without design oversight, and it definitely showed.
Ex. I merged the the individual add/decline/block wizard with the bulk update wizard, since they do the same thing but in a different scale. I also utilized the double-table component that a fellow designer created for an earlier project.
part 3: settings page and new standard.
While migrating content on the PMP settings page the general AWS Marketplace console settings page, I noticed that multiple teams expressed confusion about it but never implemented any changes. This was a real opportunity for me to redesign the pattern completely.
My new version worked so well that I applied the same pattern in my AWS Data Exchange Data Grants work, where it also became the standard for the ADX settings page.
Settings home: before & after
Originally, PMP had its own settings page. Moving all of PMP to the Marketplace console meant moving all of this content somewhere else. The governance details went to the Administrator Dashboard, and the delegated administrator and trusted access/SLR became a sub-section in the general AWS Marketplace settings page.
I made major changes to the general AWS settings pattern:
I learned that Trusted Access and SLR integrations serve the same purpose (and should have the same description) for all services. Therefore, I redesigned the status element and united the verbiage to work for all services.
I learned that services usually have either have 0 designated administrators, 1, or up to 5. I designed different treatments for each of these cases, merging the card for designated admins with the card for integrations into 1 card for each service.
Settings home: create integration & register an administrator
I learned that for all services, Trusted Access and SLR integrations are only ever set once and the only way to undo this action is to navigate to 2 specific services. I added verbiage to educate administrators about how to undo this action.
final design.
Because of the sheer scope and time required, this design effort was split into 5 rounds of design approval reviews (UX Sign off —> Fit & Finish). I spent 15 months working on this in addition to the ICMP seller redesign and ICMP buyer audit.
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.
Complete design overview
End user flow (read left --> right)
Regular end users (governed by the organization) are tasked to purchase pre-approved products through the Private Marketplace-filtered experience. Please note that both administrator users and non-administrator users can be governed, and can purchase pre-approved products on behalf of their organization.
The purple 'Approved for purchase' badge clearly denotes which products are purchase-able through discovery —> product details —> procurement. Find demo here.
Admin Dashboard + Wizard (read left --> right)
Administrators can view governance details and view the list of products that are approved or declined. They can add 1 or more products to this list via the bulk update wizard.
Find demo here.
Admin Experiences + Wizard
Administrators can view the master list of experiences — individual private marketplaces, of which administrators can make/manage multiple experiences for 1 org. They can view, create, and edit specific experiences here.
Find demo here.
Admin Changes + Settings (read left --> right)
result.
After almost a year of work and 5+ design approval sessions, the entire new Private Marketplace console experience is live. This may have been the biggest design undertaking I have ever completed. The settings submenu pattern I introduced has since been adopted across other AWS Marketplace products.
For ICMP users working in SCIFs, Private Marketplace now works as a secure place to manage and purchase pre-approved products.
learnings
Scope misrepresentation is a design problem before it's a project problem. When I found out the actual scope was 2-3x what I'd been told, I didn't stop. I mapped everything that existed, figured out what actually needed design, and worked through it. Having a clear view of the total scope, even an uncomfortable one, is the only way to actually plan.
Handing engineering a deliverable isn't enough. They need design guidance too. I made a point of being more than a single checkpoint in the team's process. I acted as a thought leader within the team and a living Cloudscape artifact, able to catch non-compliance early.
Introducing a new page takes more than good design rationale. Getting "My Private Marketplace" accepted took multiple discussions and a clear case for the user problem it solved. The best solution doesn't ship just because it's the best solution.
Patterns that work in one product can solve problems in another. The settings page template I introduced in PMP solved a long-standing information architecture problem. When I ran into a similar problem in Data Grants, I already had the answer. Building reusable patterns is worth the upfront investment.
