1. Project Summary

The product

AWS supply chain management (SCM) solution is an enterprise resource planning (ERP) system that helps AWS design, plan, manufacture, procure, transport, and deploy server racks in data centers to power the cloud. As a core part of the solution, the Offers application helps AWS efficiently collect rack prices (quotes) from manufacturers. I worked as the solo researcher and designer, shipped a design that significantly reduced manufacturers' workload (87% reduction) to keep the quotes up to date.

Terminologies

The ultimate goods we procure in AWS supply chain are server racks.
The price for a rack vendors provide is called a quote or offer.
One critical rule: We can not procure a rack unless we have a valid quote for it.

My biggest contribution

This was not a well-scoped or defined project. Customer needs were not identified, well-understood or aligned upon. I was the only researcher and designer, plus played the role of the PM to drive the project forward.

• Research: Dived deep to understand the root customer problems and reframe the challenge we should tackle;
• Product thinking: Define and drive a design strategy and vision for the Offers application;
• Influence: Get leadership buy-in, drive customer and cross-functional alignment on the strategy;
• Design execution: Deliver a design solution that takes the strategy from idea to a full realized customer experience.

2. Research about Current Customer Experience

To get a sense of what the current customer experience was like, I talked to users of the Offers application 1) rack vendors and 2) AWS Global Supply Managers to understand their goals, workflows, tools used, pain points, etc.

User needs

Customer pain points

The complexity of the rack quote comes from:

3. Dive Deep into the Root Causes of the Problem

My first round of research gave me a sense of how bad the rack quoting experience was, but didn't shed enough light on why things were the way they were. Therefore, I conducted a Deep Dive to truly understand the end-to-end rack quoting process and how it fits into AWS' rack supply chain fulfillment model, and identified several bottlenecks in our business process.

Bottleneck 1 - Unnecessary price exchange

It turns out AWS has known the prices for 90% of the components. AWS sends those prices to vendors, and vendors need to use these pre-negotiated to quote for the final rack level price. Once the final rack quote is submitted, AWS needs to review and validate manually whether vendors used the negotiated prices. This created an unnecessary back-and-forth between AWS and vendors.

Bottleneck 2 - Scattered information stored in multiple systems

The information vendors need to do the monthly quote exercise is stored in multiple systems (see detailed list below), which means there are lots of manual copying and pasting, which are unproductive and error-prone.

• A list of racks to quote for - a spreadsheet shared via email
• A list of all components inside a rack (the assembly) - Product Lifecycle Management software
• The negotiated prices for AWS controlled components - another spreadsheet shared via email
• Prices for vendor controlled components - Vendor's internal system

Bottleneck 3 - Huge waste due to low hit rate

The quote process runs on a monthly cycle. Therefore, vendors are required to quote for every rack model they manufacture every month, but it turns out we only order again 2% (hit rate) of all the quoted rack models within the next month. This means 98% of all the efforts people put into creating and reviewing the quotes are wasted.

4. User personas and customer journey

I created personas and journey maps to visualize these identified challenges in context. Then I socialized them with my cross-functional team to build alignment.

5. Reframe the problem statement

With a deeper understanding of the fundamental problems with our quote process, I reframed the customer problem to be solved to:

I chose the words in the problem statement carefully, because those were design goals I'm trying to achieve with this app design.

6. Co-Define "Dynamic Quoting" Strategy

I collaborated with customers and cross-functional partners to come up with a bottom-up quote approach - Dynamic Quoting. How it works is that we only ask users to input component-level prices, and the system will automatically generate a top-link rack-level quote when a manufacturer assembles the rack using different components. The Dynamic Quoting strategy reuses component level quotes thus significantly reduces the workload for rack quotes.

7. Extract Design Tenets

Next, I extracted design tenets from the Dynamic Quoting strategy by thinking about what absolutely need to be true for the strategy to .

8. Design Solution

One core scenario Offers app covers is AWS can request offer updates from specific vendors for specific racks, and vendors can use the same Offers system to make those changes and submit it for approval. The diagram below illustrates the high-level user flow.

Offers app home page

Design goal: Direct users attention to important items, and enable them to quickly find what they are looking for.

Design principles:

1. Quick overview of relevant metrics for users, such as number of orders that are blocked by missing quotes, number of rejected offers, etc.
2. Search and filter capability to help users find offers they are looking for.


3. Select particular offers to request an update for instead of asking vendors to update every single offer for every rack type.

Offer details page - Edit mode

Design goal: Help people update quotes accurately and efficiently.

Design principles:

4. Vendors and AWS can use the same system to make changes to quotes. Each of them can only edit the prices for components they control. The prices the other party controls are shown as read-only.
5. Placeholder texts inside the input boxes shows the orignal prices, so that users can have a clear sense of what the price was before making a change.

Offer details page

Design goal: Help people easily consume offer information. I use cards to organize offer details according to users' mental model. This meaningful arrangement helps reduce users' cognitive load to make sense of all the detailed information.

Design principles:

6. The full-width item card clearly calls out which item the quote is for, and provides users a link to the item details page.


7. The "Offer summary" card shows primary information about the current offer, giving users a clear overview of its status, how long will it be valid for, who made the last change, etc. The "Price history" card illustrates how the price has changed over time, which helps users identify opportunities to drive down cost.


8. The "Line items" section shows detailed breakdown of the rack quote. For any price change, it is highlighted in orange to show the before and after.


9. Some design iteration on the Offer details page:

9. Results & Impact

10. Additional work - Solis Common Component Library

One challenge we face was that, in order to speed up development from the initiation of the project, we used AWS' Polaris design system, which is intended for different use cases and lots of UI patterns we need don't exist at all. Besides, we have 20+ teams building products simultaneously on AWS SCM platform, we often end up with a UI pattern built in a few slightly different ways. Therefore, I took the intitative to establish Solis common component library project, as a way to drive consistency across products and invent and simplify on behalf of our customers. Read more about the project here.