The transactional spine of a B2B procurement platform.
I designed the transactional spine of Arrow Electronics' B2B procurement platform — Cart, Quote, Checkout — where electrical engineers and procurement officers buy components by part number. Built to respect their expertise, not hide complexity from it. Live in production.
Arrow's customers don't browse. They validate purchase orders against compliance data, tariff exposure, internal part-number mapping, customer attribution, and lead times, usually simultaneously. The work was designing for that, against the grain of consumer e-commerce convention.
Why consumer e-commerce conventions had to go.
Most B2C best practices are about reducing cognitive load for users who don't yet know what they want. Arrow's users know exactly what they want; they need to verify it. That inverts the design problem.
Progressive disclosure becomes friction, not clarity. Pagination breaks comparison across rows. And the single-shipment checkout consumer e-commerce assumes is a fiction about how the supply chain actually works. The job wasn't to make a complex domain feel simple. It was to make a complex domain feel legible to readers who already understand it.
The Cart/Quote table.
FIG. 01 · Quote request — authenticated premium user.
The most consequential decision was the density itself. My ACD pushed for progressive disclosure: hide the secondary fields behind expansion, surface only the essentials. The push came from serious UX principle, but the user archetypes were explicit on this. Buyers needed current, accurate, comprehensive information in one view to do their jobs. Twelve fields per row, all visible, no pagination, because verifying a purchase order requires reading across them in one pass.
The target price field is the sharpest example. It lets a buyer counter Arrow's listed price inline, in the cart, without leaving for a separate negotiation flow. Consumer e-commerce assumes price is fixed; B2B procurement assumes it's a starting position. Surfacing that in the row, rather than behind a 'request quote' CTA, matches how the negotiation happens between buyers and Arrow reps.
Multi-shipment Checkout.
FIG. 02 · Checkout — multiple shipments.
A single Arrow order can ship from Memphis, Belgium, and Itzehoe in the same purchase. Different origins, different carriers, different cutoff times, different shipping accounts. Consumer checkout collapses all of that into one 'estimated delivery date'. That collapse is a lie about how the supply chain actually works.
The shipped version groups shipments by origin, surfaces the carrier and cutoff for each, and lets the buyer assign a different shipping account per shipment when they need to. It's more interface than a consumer flow would tolerate, and the amount of interface a procurement officer needs to commit a multi-million-dollar PO with confidence.
Forecasting.
FIG. 03 · Forecast details — multiple weeks.
Procurement officers don't just buy; they plan. The design reference shifts accordingly. Forecasting projects buyer demand against Arrow's projected supply across weekly buckets, flagging shortages early enough to renegotiate or resource before they hit the production line.
The reference pattern is Excel and Confluence, not e-commerce: frozen identification columns, horizontal scroll across weeks, and color-coded shortage severity. That's deliberate. The procurement officers using this view already live in spreadsheets, and the goal was to meet them where their muscle memory is, not retrain them into a different paradigm because it looked more designed.
Role & scope.
Sole design IC on one of three tracks, working as a pod with dedicated PM and engineering lead, with design critique from my ACD. I reported to the ACD.
End-to-end design ownership of Cart, Quote, Checkout, Account Management, Order History, Authentication, Forecasting, Premium Account application, and Credit application. Every flow is live in production today.
The evidence is in the running site, not the deck. Deeper walkthrough available upon request.