End-to-End UX
Coupa · Source-to-Pay Platform

AI-Powered
Supplier Search

Unified Lookup Component

Designing a single, scalable supplier lookup component across the entire Source-to-Pay platform: embedding AI trust signals, eliminating entity ambiguity, and replacing five fragmented search patterns with one consistent experience.

Role Lead Product Designer
Timeline Nov '25 - Ongoing
Platform Sourcing · CSO · Req · PO · Invoices
Methods Discovery · Usability Testing · Iteration
01 - Overview

The "Same Name, Wrong Entity" Problem

Procurement and Sourcing Managers at Coupa regularly hit a frustrating dead-end: multiple legal entities sharing identical or near-identical display names in the supplier lookup field. A single wrong selection on a Requisition, PO, or Invoice could trigger cascading downstream errors, legal, financial, and operational.

🎯
Problem Space
Ambiguous supplier names across Sourcing, CSO, Requisitions, POs, and Invoices, causing selection errors, user friction, and loss of trust in the lookup field.
💡
My Hypothesis
If users are given richer identifying context: Tax ID, legal name, country, AI confidence, directly within the lookup result, selection accuracy will increase and hesitation will decrease.
👥
Target Users
Procurement Managers, Strategic Buyers, and Sourcing Managers: power users operating across multiple document types and sourcing events daily.
🗺
My Scope
End-to-end ownership: from initial discovery and stakeholder alignment through two rounds of usability testing, cross-platform pattern audits, design iteration, and final handoff.
🤝
Stakeholders
Sayli Walse, Ini Uto-Uko, Ashish Shah, Megan Smith, Nikki Murray, Heather Tompkins, Jackie Tsang, Tim Durkin, across Product, Engineering, and Customer Success.
✦
Design Objectives
Validate Navi AI confidence score transparency. Test supplier type labelling. Evaluate the "Ask Navi" conversational feature. Validate multi-select efficiency for RFP participant selection.
Buyer Searches "Acme Corp" in lookup field 3 Identical Results No Tax ID or country shown to disambiguate Buyer Guesses Picks first result Trial-and-error Wrong Entity On PO / Invoice Legal + financial risk Support Ticket Filed Manual correction Time + trust lost 1 2 3 4 5
Problem Flow: How Name Ambiguity Creates Downstream Errors
🔒
Full Project Details
The research, synthesis, design iterations, testing findings, and final interactive component are protected. Enter the passcode to continue.
Incorrect passcode. Please try again.
Request access from the designer

Four Lenses on the Same Pain Point

Rather than jumping to solutions, I built a comprehensive picture of the problem by combining four distinct research inputs…

Four Lenses on the Same Pain Point

Rather than jumping to solutions, I built a comprehensive picture of the problem by combining four distinct research inputs. Each source validated and deepened what the others revealed, and together they gave me the evidence to drive alignment with stakeholders across every product area.

Unified Insight Community Posts Unfiltered voice-of-customer Name ambiguity patterns Qualitative themes User Interviews In-person sessions Emotional pain + workarounds Behavioural depth Support Tickets Volume + frequency data Wrong-entity error rate Quantitative evidence PM Expert Sessions Cross-area pattern audit Fragmentation mapped System-level view
Research Triangulation: Four inputs converging into unified design insight
Input 01

Mining Community Posts

I systematically combed through the Coupa Community forum, a rich, unfiltered voice-of-customer channel. Users described feeling "stuck" when two entities with identical names appeared in search results, with no way to distinguish them without navigating away to check supplier profiles.

  • Name ambiguity as the primary frustration theme
  • International entities sharing parent-company names
  • Legal documents going out with the wrong entity attached
  • Users developing undocumented personal workarounds

"Every time I search for a supplier with a common name I have to go check the profile just to make sure I have the right one. There should be a faster way."

Community Forum Post
Input 02

In-Person User Interviews

I conducted in-depth sessions with Procurement Managers, Strategic Buyers, and Sourcing Managers. These interviews surfaced the emotional weight of the problem: users felt embarrassed when wrong suppliers appeared on legal documents, and several had developed personal workarounds to compensate for the platform's gap.

  • Tax ID, country, and legal entity name as top disambiguation signals
  • Users maintaining personal spreadsheets of entity Tax IDs
  • Emotional cost: embarrassment, lost trust, rework
  • Strong desire for AI assistance at the point of decision

Users didn't want more data. They wanted the right data surfaced at the moment of decision.

Key Interview Insight
Input 03

Support Ticket Analysis

Cross-referencing customer support tickets with my community findings, I quantified the frequency of supplier disambiguation issues. A significant share of "wrong supplier on document" tickets traced back directly to the lookup field, giving me hard evidence for stakeholder alignment.

  • Wrong entity errors as the leading ticket category
  • PO and Invoice corrections driven by lookup ambiguity
  • International entity mix-ups a recurring pattern
  • Active/Inactive status confusion contributing to errors
75% 50% 68% Wrong entity 48% Onboarding 55% PO corrections 42% Intl entities 29% Status unclear
Support ticket themes - illustrative breakdown
Input 04

PM Expert Sessions Across Source-to-Pay

I ran structured working sessions with Product Managers across every platform area: Sourcing, CSO, Requisitions, POs, and Invoices. Each area had independently developed its own local solution, resulting in inconsistent patterns, conflicting information hierarchies, and duplicated logic.

  • Five different search UIs solving the same core problem
  • No shared component or design system alignment
  • Duplicate ranking and filtering logic across teams
  • Opportunity: one unified component to replace all five
SRCING CSO REQ PO INV Tax ID shown Country shown Status visible AI ranking Type badges ✓ ✓ ✗ ✓ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗
Platform search pattern audit: fields present per product area

"I have a spreadsheet on my desk with all the Tax IDs. Every time I pick a supplier I check it. That's not how it should work."

Sourcing Manager, In-Person User Interview

From Scattered Data to a Single Direction

After gathering research across all four inputs, I ran a synthesis sprint to map themes, cluster pain points, and identify design opportunities. The convergence was clear: the problem wasn't a missing feature, it was a missing foundation.

AMBIGUITY Identical display names No Tax ID in results Country missing Status not visible International entities unclear AI TRUST Score unexplained No logic chain visible Category match not surfaced Past performance hidden Ask Navi trigger unclear CONSISTENCY 5 different search UIs Badge types vary by area Duplicate ranking logic No shared component Growing maintenance debt EFFICIENCY Multi-select cap unclear Remove affordance missing Bulk search not discoverable RFP flow adds friction Profile navigation required
Synthesis affinity clusters: four pillars driving the design solution
01
Context at Point of Decision
Legal name, Tax ID, country, and status visible in the result row itself, not buried in a profile click-through.
02
Explainable AI Confidence
Navi's recommendation score broken down into Category Match and Past Performance, not just a number.
03
Visual Type System
Internal (green), Community (purple), External (amber): consistent colour and text labels across the entire platform.
04
Progressive Disclosure
Fast selection for confident users, with a Navi deep-dive available on hover for those who need more before committing.
05
Multi-Select Efficiency
For Sourcing events requiring up to 5 participants, selection, capping, and removal should feel effortless.
06
Platform Scalability
One component designed to replace all five fragmented search implementations across the Source-to-Pay platform.

Phase 1: Building to Validate

The first phase of design was deliberately built for learning, not production. I designed the Phase 1 component with enough fidelity to test real user behaviour, but held back final polish until the core information architecture and AI integration patterns were validated.

Search suppliers... ⌘K Comma-separated bulk input supported ✦ Acme Corp - Ireland ● Internal Navi: 78% Tax ID: IE1234567T · Country: Ireland · Status: Active AI recommended sparkle = Navi pick Acme Corp - United States ● Community Tax ID: US98765432 · Country: USA · Status: Active Type badge colour + text label Acme Corp - Canada ● External Inactive Tax ID: CA4567890 · Country: Canada Inactive muted overlay treatment ✦ Ask Navi Why is Acme Corp - Ireland recommended for this sourcing event? Ask Navi something about this supplier... Ask Navi panel hover or click trigger
Component Anatomy: Unified Supplier Lookup with annotated design elements
Enriched Result Row
Each result shows legal entity name, Tax ID, country, and Active/Inactive status, all visible without clicking through to the supplier profile. The most impactful change for disambiguation.
Tax ID Country Legal Name Status
Navi AI Recommendations
Sparkle icon surfaces AI-recommended suppliers at the top of results. Hovering reveals the full confidence breakdown: Category Match and Past Performance scores, making AI reasoning transparent.
Category Match Past Performance Confidence Score
Ask Navi Side Panel
A conversational interface accessible on hover or click, letting power users interrogate the AI's reasoning before committing to a selection. Designed for the sceptic who needs to understand before trusting.
Conversational AI Progressive Disclosure
Multi-Select with Cap
RFP participant selection enforces a 5-supplier maximum with a persistent counter ("3 of 5 selected") and one-click removal. Reduces cognitive load in sourcing events without adding visual noise.
5-supplier cap Live counter Quick remove

Two Rounds of Testing. Real Decisions.

The design went through two full rounds of usability testing: the first with internal Coupa users, the second with external client participants. Each round generated distinct learnings that directly shaped the next iteration.

Phase 1 Design Built for learning not production Round 1 Internal Coupa users Sourcing + Procurement Iterate 5 key changes applied Round 2 External clients Enterprise orgs Validated Component confirmed ready to scale
Testing and iteration loop from Phase 1 design through validated component
Round 1

Internal Usability Testing

Conducted with Coupa power users across Sourcing and Procurement. Focus areas: confidence score comprehension, badge legibility, and Navi side panel trigger behaviour.

Users trusted the Navi score but couldn't explain what drove it. The breakdown was present but not scannable enough at a glance.

Round 1 Key Finding
Round 2

External Client Testing

Tested with actual Coupa clients: Procurement Managers and Strategic Buyers at enterprise organisations. Focus: real-world disambiguation scenarios, multi-select for RFPs, and the "Ask Navi" conversational flow.

Users strongly preferred seeing Tax ID upfront over navigating to a profile, confirming the core hypothesis.

Round 2 Key Finding
Entity Disambiguation AI Score Clarity Badge Comprehension Navi Trust Multi-Select Confidence 18% 84% 12% 75% 21% 80% 15% 70% 14% 78% Before After
Before vs. After: key UX quality signals across both test rounds

The Production-Ready Component

After incorporating findings from both testing rounds, the component reached its final form. This is the latest iteration — a fully interactive prototype of the unified supplier lookup. Try searching, selecting suppliers, and exploring Navi's AI reasoning below.

✦

Full Design Documentation

Explore the complete, production-ready component spec — interaction states, edge cases, token-level detail, and engineering handoff notes.

View Design Spec ↗
✦ Interactive Prototype — Supplier Lookup Try It Live
0 of 5 selected
✦
What Changed After Testing
Confidence score breakdown made scannable at a glance. Badge hierarchy clarified. Ask Navi trigger repositioned for discoverability. Multi-select counter given persistent visibility.
🔧
Production Readiness
Every interaction state documented. Edge cases for empty states, error handling, and international character sets mapped. Engineering handoff includes token-level specs.
📐
Design System Integration
Component built on Coupa's existing design tokens and spacing grid. Plug-and-play across all Source-to-Pay product areas with no per-area customisation needed.

From Friction to Confidence

The final component, validated through two rounds of usability testing with real Coupa users, resolved the fundamental ambiguity that had plagued the lookup field across the entire platform and established a scalable foundation for Source-to-Pay.

5+
Platform areas unified
2×
Usability test rounds
4
Research inputs combined
0→1
New AI design pattern
Unified Supplier Lookup Component Sourcing CSO Requisitions Purchase Orders Invoices Onboarding Flows
Platform coverage: one unified component replacing six fragmented implementations
🔍
Disambiguation at a Glance
Users can now distinguish between entities with identical display names using Tax ID, legal name, and country, all visible in the result row without leaving the lookup field.
✦
Explainable AI
Navi's confidence score is no longer a black box. The Category Match / Past Performance breakdown gives Sourcing Managers a logic chain they can stand behind.
🏷
Consistent Type Language
Internal, Community, and External badges create a unified vocabulary across the platform, reducing cognitive load for users moving between document types daily.
🧩
Scalable Foundation
The unified lookup component replaces fragmented, per-product solutions with a single, maintained design pattern across the entire Source-to-Pay platform.
🔬
Research Triangulation
Four research inputs combined to build a complete picture. Each source revealed dimensions the others couldn't, validating the direction before a single pixel was committed.
🔄
Iteration as Design
Two testing rounds with real users surfaced assumptions I couldn't have caught in isolation. The loop between testing and redesigning was the design process, not a step within it.