Amazon

 
 

5 years designing from ambiguity to reality

Over five years at Amazon, I’ve worked across multiple domains and small cross-functional teams, often entering projects before the problem — or even the product — was clearly defined. I turn ambiguous opportunities into tangible concepts and prototypes, use those artifacts to create alignment and test direction, and continue with the ideas that gain traction.

How I work at Amazon

I enter projects before the product, problem, or solution is fully defined. My role is to create enough clarity and momentum to determine whether an idea is worth pursuing.

 
 

Not every idea makes it through the funnel. The ones that do become ongoing, scalable projects. 

Case Study #1

Turning post-launch feedback into Product Improvements

Problem: 

After launching a new bill-request experience to 156 new business customers, there was an unexpected increase in manual rejections.

As lead UX designer, I designed and conducted rapid research to uncover why, while taking the opportunity to reveal broader workflow enhancements.

Summary

  • 1.5 weeks; research strategy to roadmap enhancement

  • Interviewed different roles across the billing workflow, including FinOps reviewers/approvers, business-side approval, Billing Ops, an advertising program manager, and a billing specialist/trainer

  • Identified root causes

  • roadmap opportunities uncovered

project Background:

Billing is an internal Accounts Receivable product enabling Businesses to bypass a legacy system requesting FinOps to generate bill requests, enabling autonomy and flexibility for users to directly create request. 

Current and new Business user workflow for Billing application

 

Research strategy: One research study, identifying two questions

Instead of running separate research initiatives, I designed the study to investigate:

1 — Why are bill requests being rejected?

2 — How are users actually navigating and completing this task?

Execution

Day 1:

  • Frame research questions + test plan

  • Schedule meeting with users spanning regions including Mexico, India, Seattle

Day 3–7:

  • Conduct sessions requesting users screen share and walkthrough task-based question

Day 8–10

  • Transcribing video recording and entering script into KIRO (AI engine) to help synthesize findings for every user session

  • Created a final summarized document synthesizing patterns, ranking ‘low-hanging’ to ‘requires deep dive’ items 

Day 10

  • Circulated and presented findings to stakeholders for alignment and prioritization

Findings - summary

230
Rejected requests

58%
FinOps rejections

~45%
No specific reason captured

~30%
Preventable documentation / formatting issues

top Findings

1 - Tax fields —The system was asking users to make accounting decisions traditionally completed by internal Finance specialists. Examples from research:

  • GL strings had to be manually selected even though they were determined by marketplace and bill-to geography.

  • Tax rules varied significantly by geography.

  • Users were confused on filling out Bill Request details (eg, marketplace vs. bill-to country.)

    Resolution: System to determine: GL string, tax code, tax rate (extrapolated from Business onboarding)

2 - Lack of rework/edit - When a request was rejected, users had to recreate it from scratch, which introduced additional opportunities for error. It was identified by four of the five participants and is described in your research as the "single most universal pain point."

Resolution: Directly influenced implementation change with team currently working on solution

3 - Users navigating between multiple application to complete workflow

Reviewers were leaving Billing application to find information elsewhere to make decision. Example:

  • check approver comments on Salesforce

  • determine approver eligibility on internal system

  • verify approval level against SOP threshold on another internal application

research study uncovered further Opportunities

  1. reducing copy/paste between OMS and Billing

  2. surfacing approver information in Billing (via integration with internal tools)

  3. validating approver eligibility automatically (via integration with internal tools)

  4. Displaying system validation to surface mismatches

  5. improving geography-specific validation/document workflows.

  1. Enhance research and investigation 

  • It was revealed users navigate to third party application seeking approver comment prior to making decision on Billing. My recommendation was integration to highlight desired information directly on Billing.

  • It was observed users scanned through a bill request seeking obvious errors prior to making a decision. I saw an opportunity to surface AI-generated insights outlining system validation mismatches

2. Simplify communication

  • consolidating appropriate supporting documents (PDF-generated Invoice and government-stamped documentation) to customers directly via email template directly from application

06 — Where we are now

Immediate, low-hanging rejection causes have been addressed through system changes. Other items with greater development effort pending discussion and solution forward but have been included on product roadmap for estimation. I continue to collaborate with the team to advance these opportunities as the product evolves with competing priorities.