TIBCO
Bend an e-commerce engine into a trial portal — without breaking it.
TIBCO needed a single place where people could download and manage free trials of its software — the Access Point Portal. The catch, and the whole story: the only platform available was built to sell shopping carts, not lend out demos. I was asked to fit a lending-library experience into a machine built for a checkout line.
Trials don’t work like purchases.
The portal had to be built on TIBCO’s existing e-commerce technology — a system designed around a specific mental model: browse, add to cart, check out, own the thing. But nobody is buying anything in a trial. There’s no price, no transaction — just a download, a license, an expiry date, and a EULA to accept.
What can this platform do — and where does it fight me?
I couldn’t design against a fantasy of a purpose-built portal; I had to design against the real seams of the system I’d inherited. I confirmed the boundary directly with the product owner: a complete platform revamp was already scheduled for the following Q1.
Carve with the grain of the wood.
Lean into the cart
The platform’s nature was a cart — so I used it, treating collecting trials to download like collecting items.
Detail pages do the work
Each product page surfaced the platform-specific downloads and the user’s current licenses — “get it” and “manage it” side by side.
EULA before download
The license agreement gated the download up front — acceptance came before access, not bolted on after.
Get it and manage it, in one place.
From a single product page — for real products like ActiveMatrix BusinessWorks and Enterprise Message Service — a user could pull the correct download for their platform, review the licenses they already held, and see a trial’s status. The EULA lived exactly where the principle said: an acceptance checkbox gating the “Go to download page” button, with a persistent FAQ sidebar for the registration questions a trial audience predictably asks.
The download was easy. Keeping trials legible was the product.
The account page’s “My Downloads” table listed every evaluation by product, expiry date, days remaining, and downloads remaining, with per-row Linux / Windows controls — paired with editable user details, a change-password block, and a history log. That central view was the thing that kept a sprawling set of evaluations from lapsing, and a prospect engaged long enough to buy.
As ideal as it could be, given the technology we had to use.
I won’t dress it up: managing trials isn’t the same job as purchasing, and the e-commerce platform pushed back on every difference — licenses instead of orders, expiry instead of ownership, EULAs instead of receipts. So I made concessions and worked with what I had. The experience isn’t ideal — but it’s as ideal as the required technology allowed, and I could point at each compromise and name the exact platform limitation that forced it.
That distinction — between “this is bad design” and “this is a known, articulated concession with a fix already on the roadmap” — is what let the team move forward with clear eyes instead of frustration.
Constraints don’t excuse you from good design — they change what good design is.
The failure mode isn’t the compromise; it’s the undocumentedcompromise. If you can explain why the trial flow feels a little like a checkout — here’s the specific limitation, here’s the trade-off until the Q1 rebuild — the same compromise reads as clear-eyed engineering judgment. Good design here meant bending an existing tool as far as it would honestly go, and naming every place it wouldn’t go further.
A short engagement with no KPIs handed down — explicitly a bridge design — so there are no download or conversion numbers to report.