Fair Supply: Rebuilding supplier engagement at Fair Supply

Role: Senior Product Designer · Scope: The engagement workflow end to end, and Luz, the platform's design system.

One hard question, billions of rows behind it

Procurement managers, risk leads and sustainability teams come to Fair Supply with one hard question: where in my supply chain is there modern slavery risk, and what do I do about it. Behind that sits billion-row, probabilistic data modelled on Nobel Prize-winning economics, across $750B+ in supply chain spend. Most people reading it are not ESG experts, so the design is the only thing between a number and a decision.

When the company made the strategic call to retire the legacy platform, I led the engagement rebuild inside it, with Luz underneath every screen.

The problem, measured in hours

Engagement is how the platform turns risk into action: customers send suppliers self-assessment questionnaires (SAQs), suppliers respond, and the answers move risk scores. Interviews and CS tickets showed how broken that loop was: procurement and service teams spent six to ten hours a week sending SAQs one by one, with no tracking and no confidence responses would land inside the 60-day window. Engineers confirmed the build side: designs reached production with gaps in functionality and UI.

The cost of leaving it alone: customers stay with consultants, scores go stale as suppliers go quiet, renewals carry the risk. So we set three goals. SAQ completion above 70% within 60 days. Fewer CS tickets. A residual exposure number customers could trust.

When the data is the product, clarity is the product

I design at the near-monochrome end of B2B software and reserve colour to mark data, never to decorate it.

When the subject is forced labour and emissions, a calm interface is not a style choice. It is how you keep people from looking away.

One screen, two readers: a procurement lead knows where to look first, an ESG manager reads the whole program at a glance.

A system, not a coat of paint

I built Luz, the design system behind the platform, and I take it all the way to production code, not just design files.

When I took it on, the platform had a component library but not a system: no governance, no documentation, no single source of truth, and three teams could read the same design three different ways. I rebuilt the design tokens from scratch, colour through to states, and built 150+ components on top of them.

The discipline is parity: a component audit in Linear, every mismatch between Figma and code fixed in Storybook. And I close the loop myself, shipping production components in TypeScript through an AI-assisted design-to-code workflow with Claude Code and Cursor, with keyboard support and ARIA. Parity is not a document I send to engineering. It is something I build into the code.

One source of truth that design and engineering read the same way.

Launching an engagement, not sending a questionnaire

The old flow assumed one questionnaire, one supplier, sent by hand. Real programs run in cohorts. The new flow starts with a campaign: upload the cohort by CSV, pick the framework, launch in one pass. An activity page then tracks every engagement, with action buttons and automated reminders chasing the stragglers, so nobody's week disappears into resending emails.

A whole cohort loaded in one step, ready to launch. Every engagement tracked in one place, with reminders doing the chasing.

The supplier portal: one place to respond

Suppliers are not platform users. They turn up because a customer asked a question, and most only need to respond. So the portal does exactly that: a code arrives by email, no account to set up, and every questionnaire lands in one place, even when several customers are asking at once.

Answers save on the spot and move the supplier to the next question, a progress bar shows what is left, and one uploaded document counts as evidence against every questionnaire that asks for the same proof.

Answer, saved, next. A supplier can finish in one sitting without hunting for a save button.

A response is only useful if it changes something

When a supplier completes an SAQ, their mitigation score is banded: Basic, In Development or Advanced, shown against the previous score so movement is visible. That score adjusts residual exposure: sector exposure corrected for demonstrated mitigation. An engagement does not file an answer away. It moves the number a risk lead acts on.

The new score sits beside the old one, and residual exposure moves with it.

The calls that shaped it

Code login over accounts. The easy build was an accounts-based portal. The right one removed sign-up entirely. Security concerns around the passwordless flow in Auth0 forced three rounds of iteration, and the friction-free version survived them.

One SAQ type per engagement. Mixing frameworks in a single launch muddied the data behind the scores, so I constrained each engagement to one questionnaire type. Comparable numbers beat a bigger launch button.

Prototype in code, pilot with customers. Working prototypes built with Claude Code carried concepts through review, and a pilot with Horizon Power pressure-tested the flow before launch.

What this changed

Shipped April 2026. SAQ completion within the 60-day window reached 80%, carried by the activity page and its automated reminders. With Luz in place, design-to-production time fell from a month to one to two weeks. Latrobe Health Services reports running its modern slavery program at around 50% lower cost than using consultants. Next: customer-built SAQs with custom weighting, and personalised supplier messaging.

What I took away

A library is not a system: what was missing was governance, documentation and one source of truth.

Designing to code closes the handoff gap: parity holds by default when the designer also builds.

When the data is this heavy, restraint is the feature.

Design review: Michelle Lee Summers (Design Lead) and Ben Henderson (Head of Product) · Engineering: David Kwong and Justin Irizarry (Senior Software Engineers)