B2B Partner Portal

The distributor sells professional video-surveillance equipment to system integrators. Its partners are not shoppers: they buy from a list they already have, for a project that has a date, at prices that belong to their contract. The portal they were given behaved like a shop.

I audited its ten screens before touching anything, and the pattern held across all of them. The left rail was icons with no labels. The dashboard opened with a training banner and promotions, so a professional buyer’s workspace led with marketing. The filter panel listed dozens of technical attributes at one level, alphabetically, with no search inside it and no count of what was already selected. A product card never said whether the item was in the cart, and never said how old its stock number was.

None of that is fatal alone. Together it meant every non-trivial step ended the same way — a message to the personal manager. The manager was the only place a partner’s terms actually lived, and the portal was the thing you used before writing to them.

The brief asked for a modern interface. The unit of work behind it — find a product, add it to a cart — was the shop’s unit, not the buyer’s.

A buyer works in specifications: ten to fifty lines for one project, written in a spreadsheet, passed around by email, corrected by hand. By the time it reaches the portal it already exists. The old flow made the partner key it in again line by line, and the moment a line was ambiguous — a code matching two products, a code the catalogue had superseded, a line whose quantity column could not be read — the only resolution available was a person.

So the object the system has to hold is not the product. It is the line: where it came from, what it originally said, and what it was resolved into. Everything downstream — pricing, warehouse planning, the order, an argument about a delivery six weeks later — needs to be able to point back at it.

The only hard evidence I had was the old product, so that is where I started: ten screens, one cognitive walkthrough each, four questions per step — goal, discoverability, mapping, feedback — and a severity scale that keeps “blocks the flow” apart from “looks untidy”. Where a static screen could not prove something, such as keyboard order or what happens after a click, I recorded it as not confirmed rather than counting it as a defect.

From there: a brief that keeps what is known about the old product separate from what is a target assumption, and never lets the second quietly become the first. Scenario work across the real buying shapes — a five-line reorder, a fifty-line project, a two-hundred-line import. A market pass over sixteen comparable screens, each recorded as adopt, adapt or reject with its reason, so a pattern rejected once does not come back merely because it surfaced in search again.

Then the design system, then twenty screens, then the implementation in React with a component catalogue on top of it. The last step was a synthetic run: an agent walking nine scenarios through the built prototype, thirty-five runs across three rounds, recorded as real test runs with their own events. That step is what found the things the screens were still missing.

The market pass has two jobs — structure before the screens exist, finish after they do. I ran only the second. By the time I compared layouts against comparable products, fourteen screens were built and passing their own audit, so a structural finding on them had nowhere cheap to land. It costs a paragraph in a spec before the screen exists, and a rebuild afterwards.

The agent run then found seven defects on screens I considered done, two of them critical. The catalogue’s facet rail rendered and filtered nothing. Quick order had no paste state at all — the state a user lands in first — because in the design file it existed as a hidden layer and no one had built it. A stack of toasts could grow tall enough to swallow the button underneath it.

Two of those I wrote up wrong the first time. The toast was not mispositioned: four stacked confirmations had grown 560 px upward and the card was still catching clicks. The orders list was not unopenable: its order number was inert while the only working entry point was labelled “Pay invoice”. Fixing either first diagnosis would have fixed nothing.

Twenty-four generic families and twenty-one domain components. The generic half is taken selectively from an open library and only where an approved screen needed it. The domain half — procurement tables, resolution rows, price and availability blocks, shipment groups, fulfillment plans, the order timeline — is the product’s own, because that is where its argument lives.

The most reused element is the product row, and it appears in three places doing two different jobs: choosing, in the catalogue, and reviewing, in the cart. Forking it was the obvious move and the wrong one. It carries a context property instead, and its matrix is deliberately incomplete — a browse row has no disabled state, and a commercial change cannot happen to something you have not added yet. An incomplete matrix with a reason beats a full one that invents states to fill itself.

Coverage is not checked by eye. A script walks the catalogue against the variant matrix, and a smoke run loads every story to catch the ones that compile but do not paint.