Part of eight years’ work at Previse, these portal interfaces served products that processed $305bn of spend over their lifetime. InstantView was a shipped supplier-facing tool for tracking early payments and settlement notices. SmartPay was a portal concept combining supplier self-service with operations management views — built for sales conversations but never shipped. Both required translating complex financial workflows — prepayment decisioning, AML checks, concentration limits — into interfaces non-specialists could navigate.
SmartPay was Previse’s virtual card payment product. I designed a portal concept for sales discussions and the website — combining operations management views (document queues, payment runs) with supplier self-service screens. Bundling both perspectives into one UI made production faster and reflected how ops staff would actually investigate issues: by seeing what suppliers see. Never built, but useful for moving conversations forward.
The document view needed to surface thousands of invoices across multiple buyers with clear status indicators — registered, prepaid, scheduled, on hold, declined. Colour-coded tags and a dense but scannable table layout let staff triage at a glance without drilling into every row.
Selecting a payment opens an inspector panel showing the full composition — invoices, adjustments, fees, rebates. Both ops staff and suppliers would see the same structure, reducing reconciliation queries by giving everyone a single source of truth.
When an invoice was declined for prepayment, ops staff needed to understand why. The decision inspector showed which checks failed — concentration limits, AML thresholds, vendor risk, duration rules — with pass/fail indicators for each. This was an early combination of AI, machine learning, and rules-based decisioning with some machine learning. Either way, the UI had to make the logic legible.
The portal concept extended beyond transactions into analytics — payment timing, seasonal invoicing patterns, days-to-pay by invoice size. The top-level app switcher (Connect, Match, Optimise, Accept, Pay) showed how this could scale into a unified interface across Previse’s product suite, with each “Smart” product sharing navigation and design patterns while serving different business functions.
InstantView was the supplier-facing portal for InstantPay, Previse’s early payment product. InstantPay ran in several modes: Auto (pay as fast as possible), Select (supplier chooses timing and sees exact costs), risk-free trial (fees refunded if they withdrew), and Buyer Direct (showing payments still coming direct from the buyer). One prospective buyer wouldn’t share supplier contact data, so InstantView also served as a general payment portal with InstantPay as an upsell inside it. I led design, built visual roadmaps for planning, and got hands-on in the ClojureScript build.
In this mode, the platform provides prepayment at the earliest opportunity. The documents view shows invoices, credit notes, and settlement notices in a dense, filterable list, while the payments view makes bank reconciliation easier, clearly displaying the total invoices, deductions. and the resulting payment amount whilst providing more details in an inspector.
This version of the dashboard gave suppliers using the “on demand” variant a quick route to cash. A slider lets them select an amount to request — calculated as a multiple of outstanding invoices — without needing to understand the details. For users who wanted more control, the invoice inspector showed a calendar of available dates (for one or more invoices) with pricing for each, making the cost of acceleration completely transparent.
Suppliers needed to understand why what they received differed from what they invoiced. Adjustments (amendments, cancellations, credit notes) and settlement notices (reconciling prepayments against final buyer payments) both affected the total. The inspector broke down each component with its source. On narrower viewports, the layout collapsed to a linearised list — no horizontal scrolling — so users could cross-check against their accounting software side-by-side.
During early phases with some buyers, the portal showed payments still coming direct from the buyer — not via InstantPay. This gave suppliers a complete view of their payment status regardless of source, and positioned InstantPay as an upgrade rather than a separate system.
We wanted suppliers to sign terms, but it wasn’t mandatory — especially for risk-free trial users who could withdraw and have fees refunded. A two-step wizard, built and maintained using Zoho Forms, kept the process lightweight: terms first, then business details, with clear opt-out language throughout.
Alongside a traditional backlog, I also created a visual roadmap showing features and UI states across planned versions. Engineers could see what was coming and design solutions with one eye on the future, while product could track open questions, and everyone had a shared reference for what “done” looked like at each stage. Lightweight, but it kept planning conversations grounded.
InstantView was mothballed when Previse shifted to virtual card products where reconciliation moved to the buyer side. The SmartPay portal concept supported sales conversations, but the product pivot meant it never went into build. Both sharpened my instincts for designing in domains where the user’s mental model rarely matches the system’s logic.
Fixed-scope projects for specific problems such as a UX audit, brand refresh, or product sprint.
Fractional engagement for ongoing senior design thinking without full-time commitment and costs.
We diagnose what's broken, deliver working solutions, and can mentor junior team members.