Redesigning an agentic ERP in 3 days
Restructuring Vyasa AI to increase the discoverability of its hero features.
- Problem
Vyasa reasons through the decisions an enterprise ERP can't make. The working demo buried that under layers of pages and buttons, so it looked like any other ERP. A VC fund told the team that although the product had potential, its UX wasn't landing.
- Approach
In three days, I identified why a redesign was necessary, rebuilt the structure, and then designed for uniformity and micro interactions across all pages to spark delight.
- Impact
The path from landing on the product to acting on a held order went from 4 clicks to 1, a 75% reduction. On my fourth day the team presented to the same fund and was accepted into its incubation program, the strongest of the ones in play. Customer traction followed.
The one thing Vyasa can do that an ERP cannot is decide what to do next.
But the product failed to bring that out, and anyone seeing it for the first time read it as another ERP.
It looked like every other ERP.
An ERP records what happened. It was never built to decide what happens next, so every exception falls to a person to work by hand. Vyasa sits above the ERP a company already runs and makes those calls instead.
- What the ERP already does
Records what happened. It holds the orders, invoices, inventory and customers, and it can block an order or let it through, but it was never built to decide what happens next.
- What Vyasa adds
Runs the credit, policy, inventory and pricing checks on the same records. The routine clears itself. Only the calls that need judgment reach a person, with the full context, a recommended action, the alternatives, and a way to question it.
None of that was easy to find. The demo showed everything the system could do at once, with nothing marked as more important.
If people can't see the value in a demo, they can't buy it, and investors can't back it.
Questioning what the redesign had to fix.
The brief was to redesign the demo, which usually means tidier pages and better spacing. I wanted to know what it had to fix, so I kept digging until the answer was specific enough to design against.
- 01 “Make the product look better.” The original ask
- 02 “What is a person supposed to do here?” Identifying the need for actionability · what I discovered
- 03 “Which of those moves can only Vyasa offer?” Making the hero feature discoverable · what I discovered
Actionability is whether a person can tell, from what is in front of them, what they are meant to do with it. The demo failed that, and the reason was structural.
I had 3 days. My inputs were the fund's feedback, conversations with the founders, and the engineering team, who knew what the system checked at each step. I skipped formal user research on purpose: there was no time, and the audience that week was investors rather than daily users. I wrote down what I was assuming so we could check it once real users were on the product.
That turned into 3 jobs for the redesign.
- Actionability. Group the work by the decision it asks for, so the next move is obvious.
- Discoverability. Show the moment Vyasa explains a decision inside the first minute.
- Consistency. Make the same component behave the same way on every page, so nothing has to be learned twice.
The redesign had to make the hero features discoverable and every page easy to act on.
Which part of the product was the hero?
Nothing in the brief or the product answered that, so it was the first thing I had to settle.
The exception is the only part anyone sees.
Discoverability needed a target, so I followed an order through the system end to end to see where Vyasa does something an ERP cannot.
- 01
An order arrives.
- 02
Credit, policy, inventory and pricing checks all run at once.
- 03
Most orders pass and clear on their own. Nobody sees them.
- 04The hero
One needs judgment. Vyasa routes it to a person with the full context and its reasoning attached.
At step 4 Vyasa knows what it checked, what passed, which rule caused the hold, and what it would have done either way. A normal ERP can only block the order or let it through, with no account of why.
The old demo showed only the outcome: this order is on hold. The person approving was agreeing to something without being told why, and anyone watching never saw the one thing that made the product worth buying.
The redesign was built around that one handover.
Rebuilding the structure.
I broke the product's structure down and rebuilt it from scratch, as someone seeing it for the first time.
What's not working: pages named after ERP objects, and an overview that forwarded straight to orders.
What I proposed: one page grouped by the decision it asks for, with a highlight control that reorders it by what the person is trying to get done.
Northwind Outfitters
$794Northwind Outfitters has cleared 14 of their last 15 invoices on time, and this $794 order sits well within their normal range. The account is in good standing with no holds or open disputes.
Ships now · $0 added exposure
Delays a reliable payer for no gain
The new overview groups work by the decision it asks for: needs decision, needs attention, overdue risk. Each card carries a count and the money behind it. The highlight control at the top reorders the same queue by most critical, highest value or quick wins, so a person can work to whichever goal they have that day.
The structure now names what the person has to do.
Making it consistent.
Next came fine tuning the product by fixing consistency. I did that by establishing a component library, a few pieces of which are discussed below.
What's not working: Vyasa's recommendation was one more block on a crowded page. The reasoning, the actions it offered and the follow-up questions were all built separately, so nothing told you they belonged to the same call.
What I proposed: the recommendation, the alternatives and the ability to question the call, all inside one block.
Notify Northwind now and offer an SLA credit. The carrier ETA is 2 days past their contracted SLA and Northwind has triggered breach credits twice in the last 12 months. Proactive outreach lowers the odds of a formal claim.
What’s not working: an icon rail with no labels, so what a page was for stayed hidden until you opened it. I caused that myself, by compressing 12 labeled items down to the rail to win back page space.
What I proposed: keep the icons, show the explanation on demand. Hover for the page name, keep hovering for a sentence of context. Labeling every icon would only have widened the rail again.
See what customers owe and who is overdue, with a recommended collection move for each account.
Some other inconsistencies I fixed were elements like the filter tags, lists, spacing, and UX copy.
A visual representation of the 2 and 3 panel layouts used most across the product, along with a diagram of font use on every page, let the engineering team implement everything I designed quickly.
The 2 layouts every page is built from, annotated for engineering.
Where each typeface is used, marked on the page itself.
I measured the redesign in clicks from landing on the product to acting on a held order. It is a blunt measure, and I chose it for 2 reasons: it was the only thing I could count in 3 days with no users to watch, and it was the exact distance the fund had complained about. In a demo, every click before the hero is time the viewer spends not seeing it.
What it does not measure is whether anyone understood the decision once they got there. That came later, with users.
Landing to acting on an exception went from 4 clicks to 1, a 75% reduction.
The same fund said yes.
On my fourth day the team presented the redesigned product to the fund that had given us the feedback. Vyasa was accepted into its incubation program, the strongest of the ones in play, and customer traction followed.
The pitch and the product were the team’s. My part was making the product show what the pitch claimed.
Then it had to hold up every day, for people who were not watching a demo.
- Audited it. 35+ prioritized fixes against usability heuristics, sequenced with engineering across 2 release cycles.
- Tested it. Usability rounds against the assumptions I had written down in those first 3 days. Each round fed an iteration.
- Built behind it. Research, information architecture and interaction patterns for order-to-cash and procure-to-pay.
Version 3 of that redesign is what ships today, and the decision review is in daily use.
3 things I took from the first week.
-
I asked what the redesign had to produce before deciding what it looked like.
The brief sounded cosmetic. Pushing it to a second and a third question turned it into something I could design against.
-
I designed for the moment that proves the product, not the whole product.
Once I knew which moment only Vyasa could deliver, deciding what to cut got much easier.
-
I fixed the problem my own fix created.
Shrinking the nav to icons freed up the page and hid what each page was for. Putting the labels back would have undone the gain, so I kept the icons and fixed the discoverability a different way.
A product that reasons has to show its reasoning.
Now it is the first thing I look for when I open an unfamiliar product.
Decision fatigue in AI agents
An assistant made a marketer’s job faster and their decisions harder. 7 interaction patterns for the moments the agent hands something back.