Guided Buying, Without the Guesswork

Overview

Making the Compliant Path the Easy Path

Enterprise purchasing tools are built to control spending, not to help the people doing the buying.

At a large company, most purchases come from employees outside procurement engineers, managers, ops leads who open the tool and get asked for purchase order codes and a policy they've never read.

So requests get abandoned, approvals vanish into chains nobody can see into, and people quietly buy on their own cards.

That last one has a name in procurement: maverick spend. It throws away discounts the company already negotiated.

When the compliant path is the hardest path, people don't become more compliant; they route around it.

The challenge vs. the solution

I owned this end to end over a three-week self-directed sprint: strategy, research, interaction design, systems work, and a working coded prototype. No client, no budget, no research team.

Projected · not measured

Situation

Built for Experts, Used by Everyone Else

Zip, Coupa, and SAP Ariba are genuinely good software for the people who run procurement. The failure is a fit problem, not a quality problem: these tools assume knowledge most of their users don't have.

I mapped that mismatch to three failure points, each with a direct cost line attached.

1. Requests take longer or get abandoned

Catalogs, purchase order codes, and approval rules assume knowledge most employees don't have. People guess, requests bounce back, and a purchase that should take a day takes weeks.

Cost: abandoned requests and multi-week cycle times.

2. Approvals go dark

Requests disappear into multi-team chains — manager, finance, security, legal — with no status and no view of what's blocking them. So people chase approvers instead.

Cost: slow approvals, plus hours of chasing that produce nothing.

3. People buy around the system

That's maverick spend. It isn't people being difficult — it's what a reasonable employee does when the official path costs more effort than going around it.

Cost: lost volume discounts and purchases that never reach the compliance record.

Maverick spend is a design metric wearing a finance costume. People go off-contract when the official path is harder than the workaround.

Research & Discovery

Teardown First, Then People

No client meant no handed-down brief. I treated that ambiguity as part of the job and built the picture from three angles instead of one: published research on how large companies run purchasing, a teardown of four competing tools, and four informal interviews.

Competitive teardown

I audited Zip, Coupa, SAP Ariba, and Ramp, mapping how each one handles intake, comparison, and approval where they gate, where they guide, and what each assumes the buyer already knows.

The pattern that came out of the teardown set the direction for the whole project:

Every platform in this category has optimized the approval engine. None of them have optimized the moment the request is born.

Four conversations

I talked with four people who regularly request purchases, walking through what actually happens after they hit submit and labeled every assumption I couldn't verify as an assumption. Four conversations is not a research study, and I'm not going to dress it up as one. It was enough to hear where the anxiety lives: not the form, but not knowing what's allowed and what happens next.

Two things came back unprompted from every conversation: nobody could see where their request was, and everybody had a story about buying something outside the system.

Two jobs, one flow

I wrote the jobs to be done as first-person statements so every later tradeoff had a person attached to it.

These two jobs point the same direction. Anything that makes the requester's submission cleaner also makes the approver's decision faster which is why the design work focused on intake rather than the approval queue.

Task

The Strategic Bet: A Guided Front Door

Point people toward choices that are already approved, and show them who signs off and what it costs before they submit. Make the correct way to buy the easiest way, and compliance stops being something you enforce.

That isn't a UI change. It moves where the complexity lives. Today the buyer has to translate a need into procurement's vocabulary before the system will accept it. In a guided model, the system does that translation instead.

The constraints I designed against

I framed the sprint with three How Might We questions. Each one is a constraint, not a wish I could hold any design decision up against them and get a yes or a no.

How might we let any employee buy what they need — quickly and within policy — without making them learn procurement?

How might we make the approval chain readable before submission, so "where is my request?" stops being a job?

How might we make the in-policy option the path of least resistance, so compliance is the default rather than the discipline?

What a procurement leader would need to see

Explicit non-goals

One complete request flow the path people use most. Left out on purpose: sourcing, contracts, and supplier onboarding. It doesn't replace the ERP, the supplier database, the contract library, or invoice matching. One flow done end to end beats five half-built ones.

Action I

Three Principles That Did the Deciding

Before a single screen existed, I set three principles. Every trade-off after that got settled against them, which is the only reason a three-week sprint held together.

Guide, don't gate

Move people through policy instead of blocking them with forms. A hard stop teaches a buyer that the system is an obstacle. A redirect teaches them where the path is. Same policy, opposite behavior.

Compliant by default

Only show options that are already approved and within budget. If the buyer never sees the non-compliant choice, compliance stops being a behavior to enforce and becomes part of the interface.

No surprises

Show the approval path and total cost before submit, never after. Every hour spent asking "where is my request stuck?" is an hour the system spent withholding information it already had.

A policy you have to read is a policy people break. A policy built into the option set is a policy that holds.

Action II

Three Moments That Do the Heavy Lifting

I mapped the whole flow first: intake → clarify intent → in-policy options → compare → approval and budget preview → submit and track. I also designed the paths that break it: no catalog match routes to a specialist through a guided form; over budget or flagged requires a reason and suggests alternatives; changes requested means edit and resubmit, and a rejection logs why. A guided system that only works when everything goes right isn't guided. Then I asked which steps actually change the outcome. Three carry most of the weight.

1. Guided intake

The buyer types what they need in plain words. The assistant reads the intent and asks one to three clarifying questions never a twelve-field form.

I made a deliberate choice here: the product category, cost center, and supplier record get sorted out behind the interface instead of handed to someone with no reason to know them. The complexity doesn't disappear. It stops being the buyer's problem.

2. In-policy options and compare

I designed the options so only approved, pre-negotiated items appear, compared side by side on the two or three things that actually drive the decision.

This is where "compliant by default" earns its keep. The buyer still makes a real choice the interface doesn't feel like a cage but every option in front of them is already in policy.

3. Approval and budget preview

Before submitting, the buyer sees the exact approval path who, in what order, and why each person is in the chain next to a live view of what it does to their team's remaining budget.

This is the design bet of the whole project. It turns a black box into a forecast, and it kills the chase before it starts.

Showing the approval path before submission is the highest-leverage move in the flow. It costs one screen and removes an entire category of follow-up work.

Action III

Building It, Not Just Drawing It

Static screens can't prove that an approval preview reads clearly, or that a series of clarifying questions actually lands somewhere instead of looping. So I built it.

The design system came first

I built design tokens matched to SAP color, type scale, spacing, radius plus a small component kit: the assistant message, the option card, the approval timeline. Then I built the real states: default, hover, disabled, loading, error, and the unglamorous ones. Empty results. Item out of policy. Over budget. Missing information.

Those states are most of the work in an enterprise tool, and most of what gets skipped in a portfolio piece.

Then I prototyped the logic, not just the screens

I vibe coded the full flow using Figma Make, v0, and Claude Code enough of a working layer that the assistant responds, navigation is real, and the approval routing actually executes instead of being implied.

Building it live raised questions the Figma file let me skip: what the buyer sees while an approval is pending, how to turn down an out-of-policy item without it feeling like a punishment, and when the assistant should stop asking and commit to an answer.

A prototype that runs the logic asks harder questions than a prototype that only looks like it does.

Iteration

Refined Through Feedback & Iteration

I concept-tested the clickable prototype with five people who had enterprise purchasing experience. Five people points you in a direction; it doesn't give you statistics. It shows you confusion, not confidence intervals. Two changes came back clearly enough to act on, and both were structural rather than cosmetic.

Iteration 1: Approval path preview placement

Testers wanted to know who had to sign off while they could still change something. A status screen tells you about a blocker after you've already spent the effort. A legal review that adds two weeks is useful before you pick the vendor, not after. Moving it upstream turned a status report into a decision input.

Iteration 2: How the assistant asks its questions

Typing answers into a chat box got tiring fast. An open text field also asks a non-expert buyer to produce vocabulary they don't have — a blank-page problem wearing a chat interface. Tapping kept the request under a minute and gave the assistant cleaner input to work with.

One more finding I acted on

Participants read the same clarifying question as either helpful or nosy depending almost entirely on wording. I rewrote the prompts to say why a question was being asked before asking it. Wording earned more trust than any trust feature did.

Both iterations moved information earlier in the flow. That was not a coincidence — it is the same principle applied twice.

Result

What This Is Built to Move

This was a self-directed concept sprint, not a shipped product. Here's what I proved, and what the design is built to do if a team picked it up.

Saves time

Three separate time sinks disappear at once: intake shrinks from a multi-field form to a plain-language request, misfiled requests stop causing weeks of rework, and the manual chase for approval status goes away because the status was visible before submitting. The target is a real cut to request-to-purchase-order time, and every hour of chase work handed back to the requester.

Prevents disasters

By design, every option the assistant shows is already approved and in budget. Compliance stops being a behavior the company has to police and becomes part of what the tool offers — and off-contract spend becomes something a buyer has to work to do, not the shortcut they fall into.

That's a design guarantee about what the interface shows, not a measured compliance rate. The difference matters, and I'd rather say it than blur it.

Makes money

I modeled the concept as a tiered annual subscription and sized the opportunity to test whether it could carry a real product.

The levers this would be judged on

Cycle time, policy compliance rate, rework rate, and off-contract spend. Those are the four numbers a procurement leader would actually use to judge this, so they're the four the design was aimed at.

The estimates at the top of this page are targets modeled from category benchmarks, not outcomes. The honest next step is a pilot inside one organization, measuring compliance rate and time to submit against a real baseline.

Reflection

Policy Compliance Is a Design Problem

What shipped out of the sprint

The argument underneath all of it

The usual assumption in enterprise procurement is that compliance is an enforcement problem: write clearer policy, add more required fields, escalate more approvals.

Every one of those moves makes the official path harder. Which makes the workaround more attractive. Which produces more of exactly the behavior the policy was written to prevent.

Treating it as a design problem inverts the loop. If the compliant option is the first one a buyer sees, the fastest one to select, and the only one that clears in a predictable window, then compliance stops being something you have to enforce.

The decision I'd defend hardest isn't a screen. It's spending a whole step on showing people what happens next the approval chain, the budget hit, the timeline before asking them to commit. Enterprise software usually holds that information back, as if seeing it were a privilege. It's the cheapest thing in the system to give away and the most expensive thing to withhold.

This project changed how I think about compliance. I used to treat policy as the constraint you design around. Here it was the thing to design with because when following the rules is genuinely the fastest option, you don't have to enforce anything. It also pushed me further into building what I design. Coding the prototype exposed problems in my own flow that no amount of static screens would have shown me.