Redesigning a 20-year-old B2B procurement platform — from UX debt and feature accretion to UK Ministry of Defence, 90 German research institutes, and measurable conversion uplift.
The problem worth solving
Unite's procurement platform had been compounding complexity since the early 2000s. For a buyer in a German industrial company reordering safety gloves, a batch of cables, or a wireless headset, the experience felt dated: search returned noisy results, checkout routed them through steps designed for someone else's role, and the UI didn't work on anything that wasn't a desktop monitor. Sales conversations reflected this — the platform was increasingly hard to demo against modern alternatives, regardless of how strong the underlying supplier network was.
The temptation was to treat this as a UX facelift. It wasn't. Twenty years of feature accretion meant the real problem was deciding what the new platform should refuse to rebuild — and how to run two systems in parallel for years across 12 countries without breaking the ERPs our biggest customers had already integrated.
Find the right product in one or two queries. See stock and delivery transparently. Export the basket to your ERP without fighting the interface. Reorder recurring items without starting from scratch.
A platform Sales can demo against modern alternatives — that large regulated customers can onboard without custom workarounds.
Category browse — Office & warehouse
Search results with faceted filtering
Product detail — multi-supplier offers
Smart Basket — optimised delivery & cost allocation
What I decided before building
Counter-intuitively, this segment needed a smaller MVP surface — most business logic lived in the customer's ERP, not in our UI. That let us ship a thinner, more focused product and validate the architecture under the highest-integration-complexity conditions. I said no to Sales' preference for a multinational, multi-segment launch.
Germany represented ~90% of revenue. Parallel rollout across all markets would have delayed the MVP by months and multiplied migration risk. I accepted short-term stakeholder dissatisfaction in other markets to protect the integrity of the core launch.
Strategic purchasing features — spend analytics, approval chains, framework agreement management — served a smaller population doing lower-frequency workflows. The end-user order and checkout flow was where conversion and NPS actually moved.
I refused to promise a full migration date. With engineering and selected ERP-integrated customers, we validated that legacy and new platform could run simultaneously against the same ERP integrations. That turned the migration from a risky event into a gradual shift — and removed the pressure to ship prematurely.
Full feature parity with the legacy system. Advanced phrase and boolean search in the MVP — data showed users refined simple queries rather than constructing complex ones. Complete self-service user management for the MoD rollout, replaced with a phased model backed by structured data imports during refactoring. Each cut had an internal advocate. Each was deferred with an explicit reason.
In a 20-year-old B2B product, documented user roles under-represent actual behaviour. I committed to validating every segment decision with usage data and pilot feedback, not org charts — which turned out to matter more than expected when the shadow user group appeared in pilot.
How it worked
Rather than run a company-wide beta, we ran focused pilots with 5+ selected customers from each segment. The pilots were scoped small enough that we could actually act on feedback before the next increment. This is where we found the mistake that became the most useful learning in the project.
We launched the new platform as authenticated-only, aligned with leadership on security and data governance grounds. What discovery missed was a third, informal user group: employees who browsed and compared products, then handed requests to licensed buyers. This was a cost-avoidance pattern driven by ERP licensing, not a documented workflow. Closing access removed them. We corrected with a controlled pre-approval browsing capability, but I own the miss — I hadn't pushed hard enough on shadow workflows during discovery.
Data was unambiguous. Users did simple keyword searches and refined them rather than constructing advanced queries. More importantly, a large segment — especially customers with standardised hardware — didn't start from search at all; they reordered from shopping lists. MVP prioritised synonym handling, zero-result reduction, and surfacing shopping lists as a primary entry point. Advanced filter logic and phrase search were sequenced later, and some of it never justified its cost once relevance improved.
Outcomes
Reflection
Earlier, smaller MVP. I'd push for a visibly-shipped increment sooner, even at the cost of architectural completeness. The long discovery and architecture phase was defensible in isolation, but it cost executive momentum that became hard to rebuild when priorities shifted later. Tangible progress protects prioritisation better than good plans do.
Shadow workflows are a first-class research target, not an edge case. The research-only user group cost us pilot goodwill. Since then, I explicitly map cost-avoidance behaviours and licensing-driven workarounds during discovery. In B2B, licensing structure shapes behaviour in ways that documented roles don't capture.
Product needs to be in enterprise sales conversations earlier. The MoD commitment around self-service user hierarchy was made before Product was meaningfully involved. The technical constraints were real and knowable. Proactive alignment on what the product can and can't promise is cheaper than renegotiating with a sales team and a customer mid-delivery.
What transfers to AI product work. The judgment pattern is the same. Deciding what not to build, validating assumed user behaviour before committing, designing for coexistence with existing systems rather than replacement, staying honest about which outcomes generalise and which don't — these are the exact decisions that matter when the system you're shipping is a model rather than a UI. The technology changes; the scoping discipline doesn't.