CORETRUST
PUBLIC SECTOR WEB + CUSTOMER EXPERIENCE PORTAL
2024-2025
SUMMARY
CoreTrust is a purchasing network. Member organisations sign an agreement with CoreTrust to access pre-negotiated pricing, then sign a second agreement with the supplier they actually want to buy from. Two contracts, two moments, one relationship.
I was the product designer across both surfaces of that relationship during a year in which the company was doing two hard things at once:
-
Opening a public sector line of business — which needed a public-facing site it had never had.
-
Modernising the Customer Experience Portal (CXP)— the signed-in product where existing members manage their agreements.
The two surfaces were at opposite ends of the same journey — one acquires, one serves — and they were being built to different clocks. The public sector site had to launch. The portal did not yet carry public sector services at all.
PROBLEM + OPPORTUNITY
Problem
A new line of business has no existing users to learn from, no established content, and no obvious place to live. Public sector procurement runs on published solicitations: open bids, then awarded contracts, each with a different shape of information and a different reader. There was no site to put them on, no process for getting them there, and no agreement on what a public sector member should see after they signed. Meanwhile the portal those members would eventually land in was built around a different kind of buyer entirely.
Opportunity
The gap was the work. If the front door was designed as the beginning of a journey rather than a brochure, then the publishing model, the content lifecycle, and the navigation of the portal behind it could be designed as one system — even though only the front half was shipping this year. Designing for the sequence rather than the page meant the second half would have somewhere to attach when it arrived.
HOW THE WORK WAS SET UP
CoreTrust's product decisions were made by full-time subject matter experts — people who owned categories, contracts, member relationships and public sector strategy — and, above them, a company vision held by the president.
What I owned was design direction, the structure of the pages, the shape of the flows, the sequence of what a member sees, and the options put in front of the people making the calls.
-
Requirements arrived unresolved more often than not — "contracts page is a work in progress; requirements are still being gathered."
-
So the useful move was rarely to wait for an answer. It was to build the two or three coherent versions of it, make their consequences visible, and let the SMEs choose between designs rather than between abstractions.
SOLUTION — ACT ONE: THE FRONT DOOR
01
A publishing model before a publishing tool
A solicitation is only useful while it is open. The site needed content to go live the moment it existed, and there was no CMS, no content team, and one person who would end up owning it day to day. Rather than design a page and leave the filling of it to chance, we designed the intake: a single structured document with a column for every variable a listing needs, held where the team already worked, with logos kept in one referenced folder rather than attached ad hoc. Fill the row, the listing publishes. No queue, no turnaround, no design dependency.
The same logic settled the Contact Us control. An enquiry about a solicitation is a real question from a real bidder, so the button had to reach a monitored public sector inbox rather than bounce to a generic corporate contact page. A button that goes somebody's way is a different object from a button that goes somewhere.
02
Solicitation and Awarded as one lifecycle, not two pages
The site had a solicitations page and a recently awarded page, and the same contract could appear on both. The instinct in the room was that these were two content types. Looking at the fields, they were one content type at two stages: an open solicitation carries a closing date and a way to enquire; an awarded one carries a supplier, a renewal date, and links out to the contract and the supplier's page.
Designing them as stages instead of pages did three things: the publishing document got one row per contract that gains fields as it progresses; the redundancy between "recently awarded" and the contracts page resolved into a linking strategy instead of a duplication problem; and the question stakeholders were stuck on — is a card with a PDF link enough, or does each contract need a page? — became answerable, because it was now a question about one object's later life.
Designing the question, not the answer
That decision was not mine to close. The category and public sector SMEs needed to see the trade-off in a form they could react to, so the deliverable was the framing: here is the card-and-PDF version, here is the contract-page version, here is what each costs to maintain and what each gives a bidder. Comparable structures on other procurement networks were useful reference in that conversation — not as an audit I produced, but as a shared point of orientation when someone asked what normal looked like.
SOLUTION — ACT TWO: THE ROOM BEHIND IT
03
Product Offering at the entry point
The portal's catalogue was organised by supplier. That reflects how the business was built and not at all how anyone buys: you do not go shopping for a supplier, you go shopping for bedsheets. Copiers & Multi-Functional appeared once for Ricoh and again for Xerox, so a member scanning for something to buy was really reading a list of who sells it. Category and sub-category each took a column of their own, which meant three of the five columns were classification before you reached the product.
The restructure made the product offering the row. Category moved underneath it as a subtitle; each offering picked up a category icon so the list can be scanned without being read; and every supplier for an offering collapsed onto one line — CDW, Insight Direct, Dell, HP — instead of fanning into four. The reason this is more than tidiness is the two-contract mechanic: a member signs up for a product offering before choosing a supplier, and a row per supplier asked people to make the second decision while still making the first.
D0.2 · CATALOG
CXP · catalogue, shipped structure
Every state gets an action
Each row carries the member's own position against that offering, and the restructure gave each position somewhere to go: View details on one not started, Manage on one already initiated, View on one that's active. Previously only untaken offerings had a button and every other row was a dead end — backwards, since the offerings a member has committed to are the ones they return for. That mattered commercially too: a self-serve path from the catalogue row is what makes small categories viable to sign at all.
04
Two navigations for two jobs
CoreTrust's own staff and CoreTrust's members were moving through the same navigation, and it served neither. Admin functions — the admin panel, creating a new organisation — sat mixed in with the things anyone does inside their own organisation, so neither audience had a clean path to their own work.
Decisions:
-
The proposal separated them by axis rather than by section.
-
The left rail is the product: Home, Insights, Catalog, Opportunity Analysis, Contracts Manager — identical for everyone.
-
The top bar is administration: Participation agreements, terms of use, company profile, the spend categorisation tool — things a CoreTrust employee does to an account rather than in it.
What holds the two together is a Viewing as switcher. An admin chooses the organisation once and both surfaces answer to it, which is what allows the left rail to stay the member's rail rather than become an admin variant of it. A member signs in and simply has no top bar. I carried this to stakeholders as two developed options rather than one recommendation, with the flows and copy resolved far enough that the difference between them was legible.
D0.3 · SPEND CATEGORIZATION
CXP · Admin login view
The Customer Experience Platform
HP
DESKTOP
impact
The public sector site launched
It is live and operating as a working procurement channel, with roughly 13 active solicitations posted at the time of writing — which is the honest measure available: the publishing model designed for it is the one running it.
A content process that survives its designer
Solicitations move to awarded through a defined transition with defined fields, owned by the team rather than by a design queue. The site does not need me in order to stay current.
A portal designed for a member it did not have yet
The CXP work — the offering-led catalogue, the split navigation, the admin dashboard — was delivered as resolved design direction. The portal sits behind member sign-in, so I can't verify its shipped state; what I can account for is the design and the decisions behind it.