Virtuaize AI
The challenge
My role
UX · UI · Information Architecture · Interaction Design · Design System · Product Storytelling
Over two months with the founder, I turned that workflow into a live marketing site and product demo — one mental model, one visual language, and a walkthrough that answers a buyer’s questions in the order they’d ask them.
AI products are easy to promise. Trust is harder to design.
Before anyone books a demo, they need answers to five plain questions:
What does Virtuaize actually do?
How does data move through the workflow?
Where does each extracted value come from?
What happens when something goes wrong?
How does the result reach SAP?
Rather than answering with claims, I built the experience around showing the product’s behaviour. Every section on the site is one of those questions, answered visually.
From a complex workflow to one simple mental model.
I reduced the whole product story to five words:
Receive → Extract → Validate → Review → SAP
That sequence became the information architecture of the site, the order of the product walkthrough, and the tab strip inside the product itself. If a visitor learns nothing else, they leave with this.
Show the product without overwhelming the user.
Instead of exposing the entire interface, the site follows a single document through the workflow. The visitor watches one shipping bill get extracted, then hits a value mismatch, then gets resolved and pushed. They understand the journey without having to learn the product.
Turn documents into structured data.
The core value is easiest to grasp when the transformation is visible: Document → Fields → Structured data.
The interface shows the transformation directly instead of explaining the technology first. A PDF arrives; ninety-five fields come out the other side, already named and typed.
Know exactly where every number came from.
In an enterprise workflow, extraction on its own isn’t enough. Finance and audit teams need to be sure a value can be traced back to the exact spot on the bill it was read from.
The interface draws that line explicitly: Source field → Extracted value, which makes the AI’s work both understandable and auditable.
When something doesn't look right, Virtuaize tells you.
Most AI marketing shows the win. I wanted the site to also answer the question a cautious buyer is really asking: what happens when the system isn’t sure?
The interaction walks through it: Expected → Extracted → Mismatch → Review → Correction.
Nothing reaches SAP unless a person stood behind it, and the site says so in the interface rather than the copy.
From document to SAP, without anyone re-entering data.
Extraction only pays off when the result lands in the systems teams already use. So the story closes the loop: ICEGATE → Virtuaize → Validated data → SAP.
The site shows the same four fields on both sides and a push log that includes a failed push with a retry, because a demo where nothing fails isn’t believable.
Make the downstream value visible.
Once the core workflow is understood, the site introduces the supporting capabilities: incentive tracking (RODTEP and drawback), the reasons it behaves differently from generic automation, and the enterprise controls IT and audit teams ask about.
These sit lower in the hierarchy on purpose. They matter, but they’re not the argument.
Building one visual language across the experience.
I built a reusable system covering typography, colour, spacing, components, product UI and states.
A few of the decisions that hold it together: one accent colour that only ever means “verified” or “proceed”; monospace for anything that is data so product UI and marketing copy are never confused; a cream paper tone reserved for the source document so it always reads as the thing we started from. The result is a marketing site and a product demo that feel like one product.
From feature catalogue to guided product story.
The final site takes a visitor through one clear journey:
Manual work → Automation → Extraction → Traceability → Validation → SAP → Business value → Trust → See it run on your own documents
Every section answers one of the five questions from the start, in the order a buyer would ask them.
What I learned from doing this twice.
This was a two-person project: the founder and me. There were no customers yet, so there was nobody to test with. I designed for the founder, and the founder already believed in the product.
The first version showed too much. It had a live dashboard on the site with a label that said “this is the actual product”. It looked impressive, but some buttons did nothing and some numbers showed as zero. Anyone who clicked around found less than the label promised. I thought showing more would build trust. It did the opposite.
What worked
Following one document through the whole workflow. Once the site stopped listing features and started answering the five questions a buyer has, in order, everything got simpler and easier to believe. Showing the error screen was the other good call. It does more for trust than any accuracy claim.
What I’d do differently
Show the site to a real buyer, an exports ops lead or a finance auditor, before launching, not after. Most of the problems only showed up when I reviewed the site the way a sceptical buyer would. I’d also start with the sample-data walkthrough instead of the live dashboard. It shows how the product behaves without giving away how it’s built.
On the tools
Designing in Figma with Claude MCP and handing a vibecoded build to the developer was fast. That speed is what let us ship a first version and rebuild it within weeks. But the tools don’t decide what to show and what to hold back. That still has to come from the designer.
Designing AI products means designing trust.
For complex AI workflows, trust doesn’t come from polish or from accuracy claims. It comes from making the system’s behaviour legible.
What does it know? Where did the information come from? What happens when it isn’t sure?
