From quotes to an award, in one flow

Picking a vendor used to mean digging through email threads and spreadsheets. Leveling views put the quotes side by side, covering price, financial terms, compliance and certifications, and call out risks.

Buyers note why they chose a vendor, get approval if they need it, and send a PO that's already filled in with the quoted items.

Every PO item, tracked in one place

Buyers used to track deliveries one PO at a time. Now they see every item across every PO in one table, with its status, the supplier's last update and the original date.

Late items stand out, and buyers can email every affected supplier in one step.

Seeing where the money goes

Spend analysis shows where the money goes by category, and each category opens into its line items.

For every part, buyers can see lead time, savings and the lowest price quoted, with a link back to the RFQ.

Deciding what to build, together

With AI filtering, users can pick a filter or just type what they're looking for, and the AI builds the filter. I defined how it should behave and worked through the open questions with engineering, like what gets saved and how results are ranked.

We also had the whole team write the searches they'd actually type. Those sticky notes became our first set of supported queries.

Suggest, show your work, then wait

Vendor emails are full of small updates, like a new contact or a new address. The agent reads each thread and suggests changes to the vendor record, so nobody has to update it by hand.

We used the same approach for messy files. When a buyer uploads a PO spreadsheet, the AI matches each line to an existing order and suggests delivery updates for the buyer to approve or undo. Leveling works the same way for quotes.

The AI never edits a record on its own.

Quote leveling and chat-based RFQs

Quote leveling compares the quotes on an RFQ and recommends one. We watch user sessions to see which comparisons buyers want next.

Buyers can also create an RFQ by chatting. They upload a PDF or spreadsheet, answer a few questions, and get a draft RFQ.

Advertising without a sales call

Suppliers could only buy ads through a sales rep, and we wanted them to be able to do it themselves.

I ran a 4-day design sprint and tested the prototype with 5 customers before any code was written.

+25% new customers. Checkout takes about 5 minutes.

Three steps: keywords, budget, checkout

Suppliers pick keywords, choose a budget and check out. I worked with our data analysts on the recommended budgets so each one gets the most search traffic for the money.

Before launch, I ran service blueprint workshops with executives, sales, finance and support so everyone knew what was changing.

What we shipped next

Oct 2024: a proposal tool helped sales reps follow up on abandoned checkouts, closing 50 new sales in two months.

Dec 2024: customers could edit live campaigns, which opened up upsells and raised average spend 15%.

Jan 2025: annual payment plans, designed with finance and sales.

ROI reports in 4 minutes, not an hour

When we moved to a new data platform, the sales reporting tools had to be rebuilt anyway. Our UX researcher and I surveyed the sales team first to learn which reports mattered.

I designed configurable tables, a shared report library, exports and ROI charts. Every sales rep now uses it.

Eight tools down to one

The content team was working across 8 separate apps and tracking changes in CSV files. I ran workshops to map their workflow, and those maps shaped the new platform's design and architecture.

It took over two years, but we shipped one platform with a full change log and moved the whole content team onto it.

Mapping the platform, together

I run sticky-note workshops where the team maps what users do, what the system does, and where the old tools fall short.

By the end, everyone is working from the same picture of the product.

Use cases, edge cases, solutions

For each feature I list the use cases, edge cases and possible solutions, then turn them into requirements with rough concepts.

This board covers emails that don't match a known vendor. We settled most of it before designing any screens.

Flows that engineering can build from

Before high-fidelity design, I diagram how a feature works end to end. This one maps PO imports, from matching uploaded items to existing orders to handling errors.

Engineering and I use these diagrams in architecture discussions, which brings edge cases up early.

Flexible components in Figma

I built components with Figma slots and variants, plus notes on how to use them, so one component can flex across many screens.

New features start from patterns we already trust.

One system, built once

I worked with engineering to turn those designs into coded components in the platform. Each pattern gets built once and reused.

That saves engineering time and keeps the whole product feeling consistent, from sign-up onward.