The engine was never
the problem.
ReportCaster is a scheduler so well-built it ran for decades on fixes alone — the scheduling and distribution engine behind WebFOCUS, itself built on ibi's 50-year reporting legacy. A global payments processor pushed ~80,000 distributions a week through it; a top-tier bank ran 5M+ schedules. What it never got was a modern experience. After years of customer requests, it had reached modernize-or-migrate: a five-year, multi-million-dollar account was threatening to leave. One week into the job, I asked to lead the redesign. It shipped in April 2024 — and that account stayed.
This isn't a feature. It's infrastructure.
Some customers run millions of schedules on it. Others push tens of thousands of distributions through it every week. If ReportCaster stops, their reporting stops. It was powerful, and it was trusted — the experience around it just hadn't moved in decades. With a system this critical, modernizing it meant getting it exactly right.
I arrived the moment
its time came.
I joined WebFOCUS two years into a company-wide effort to modernize a platform built on ibi's 50-year reporting legacy — and ReportCaster, its scheduling engine, was next in line. Its redesign had waited years: daunting, undocumented, mission-critical. The pressure was real — customers were threatening to migrate unless the experience caught up. One week into the job, I asked to lead it, and it was handed to me the same day. Then I reverse-engineered decades of undocumented logic — by hand, from a single sandbox link — until I understood how the whole system actually worked.
It wasn't a feature. It was a product inside a product.
Five independent subsystems, scattered across the platform: scheduling, distribution lists, access lists, Explorer, and admin. Seeing that was the decision that set everything — this needed a structural redesign, not a facelift.
Five independent subsystems, scattered across the platform — never assembled into one product before. Seeing that was the decision that set everything.
Five subsystems, five separate interfaces to learn.
Each ran on its own dated screen, buried in menus and stacked dialogs — the real decades-old experience, before I touched it.
I reverse-engineered decades of logic — by hand.
There was no onboarding, no spec, no design file, no historical rationale. So I treated the product like a black-box investigation: hundreds of screenshots across every corner of the system, grouped and categorized; long sessions with Customer Support — the only real source of truth; one-on-ones with the reps who lived in it all day; and conversations with the one engineer who had built it decades earlier. By the time I finished, I had a complete picture of its UX and workflows — because no one had ever consolidated the pieces before.
I learned the domain the only way I could — by hand.
Burst logic, blackout windows, retention rules, heartbeats, crash recovery, priority queues — the behavior users relied on that the interface never expressed. Pages of it, reconstructed from tribal knowledge before I designed a single screen.
The behavior users relied on that the interface never expressed — pages of it, rebuilt before a single screen.
The by-hand proof.
Pages from the sketchbook where I reverse-engineered decades of undocumented logic — and the map where five scattered subsystems became one model.
Two rejections before
the right architecture.
The hard part was never the screens. It was where a decades-old product should live inside a modern platform. I got the answer wrong twice. Each rejection narrowed it.
A separate product, like the rest of the ecosystem. Sound — but leadership wanted everything centralized in the hub.
A dedicated plugin — the same pattern the platform used for Portals and Home. Aligned with the long-term goal, but too much engineering for one release.
Version 1: a product of its own. Version 2: a plugin. Both sound, both rejected.
Version 1 — standalone. The rest of the ecosystem worked this way: click Create Visualization and you get a full Designer environment; click Data Flow and you get another. ReportCaster fit the pattern — five subsystems, users who spend their whole day inside it, some customers who buy scheduling separately. I built the screens, validated the IA with my director. It was rejected: leadership wanted every workflow centralized in the hub to drive adoption. A fair constraint, not a design flaw — so I moved on.
Version 2 — plugin. If independence was out, the next logical step was a plugin, the exact pattern the platform was already using to bring Portals, the Management Center, and Home into the hub. It aligned with leadership's long-term goal. It was also rejected: too much engineering effort for one release. Two rejections. Instead of fighting the decisions, I reframed the problem from scratch.
So I stopped asking
where it should live.
I asked a different question — how does the platform want workflows to behave? The answer was hiding in the one control every creation flow already started from: the “+” menu.
ReportCaster, initiated the way the platform initiates everything.
Create Schedule, Distribution List, and Access List now live in the platform's universal “+” menu — right beside Create Visualization and Create Data Flow. Not a place you navigate to; a creation workflow you start the way you start every other one.
ReportCaster is initiated the way the platform initiates everything — from the universal “+” menu, “Start something new.” Create Schedule, Distribution List, and Access List sit right beside Create Visualization, Get Data, and Explore Data. Not a place you navigate to; a creation workflow you start like every other one.
The “+” menu wasn't UI. It was architecture.
Every major workflow on the platform starts in the plus menu — create a visualization, fetch data, explore data, build a data flow. That menu wasn't decoration; it was how the whole platform initiates work: predictable entry points, context anchored, no lost tabs. So the question answered itself. If ReportCaster is fundamentally a creation workflow, it should start there too. Create Schedule, Create Distribution List, Create Access List — each a guided modal from the “+” menu.
A modal, not the side panel: the side panel was built for read-only file properties — simple, glanceable — never for multi-step, high-cognitive workflows. A modal matched the platform's own conventions, kept users in context, and eliminated the old basic-vs-advanced split — without requiring a plugin or the engineering risk that killed Version 2.
And it all lives in one place — the Explorer, in Home.
Every schedule, distribution list, and access list, browsable from a single filtered view built into the hub's Home — right beside Recents and Favorites.
Every schedule, list, and access list — one filtered view by Type (Schedule, Distribution List, Access List, Report Library), built into the hub’s Home beside Recents and Favorites.
The filtered view, in the real product.
The same Explorer, narrowed to one asset kind: filter by type — Schedules, Distribution Lists, Access Lists, Report Libraries — and each row carries what that type needs: schedule ID, last run, job status, next run, distribution method.
And one idea that outgrew the project.
Talking with the lead architect, I learned the platform's Home page is really a filtered view of assets — Favorites and Recents are just filters. So ReportCaster Explorer became a filtered view too, native in Home. And the same pattern could unify asset navigation for Designer, Data Flows, DSML, Reporting — the entire platform. My director loved that extension. It was pushed to a future phase on timeline, not on merit.
One pattern — the same filtered view could carry every asset type across the platform: Designer, Data Flows, DSML, Reporting. Deferred on timeline, not on merit.
Five scattered subsystems,
brought into the hub.
Every subsystem used to open as its own separate browser tab — five workflows, five tabs, no shared home. I brought that fragmented product into the platform's existing hub: Explorer became a filtered view in Home; Schedule, Distribution List, and Access List moved into the universal “+” menu; and Admin got its own dedicated space in the Management Center.
Five browser tabs, brought into the platform hub.
The real before wasn't stacked windows — it was five disconnected workflows, each in its own browser tab. Bringing them into the platform's existing hub made the tool easier to reach and to learn — without changing the workflow inside it.
I didn’t build a hub — I took a fragmented product and integrated it into the platform’s existing hub. Five workflows that each opened in their own browser tab now live in one place: Explorer in Home, Create Schedule, Distribution List & Access List in the “+” menu, and Admin in the Management Center. One integrated product — easier to reach, with the workflow inside left intact.
The legacy product, in motion.
One guided modal, restructured into a clear tab rail.
One guided modal, restructured into a clear tab rail — Task, Distribution, Recurrence, Properties, and Log Reports are tabs in a single contextual window from the “+” menu, with the Hub as the parent behind it.
One modal, restructured — down to the controls.
I restructured the whole Create Schedule dialog into one guided modal — a clear tab rail (Task · Distribution · Recurrence · Properties · Log Reports) — and made deliberate calls on the actions: Cancel, Save, and Run each carry their own dropdown of options. The task list itself predates the redesign; the structure and the controls around it are mine.
Then I led the people
who built it.
The direction was approved. Now it had to ship — and everyone who'd build it had to understand a system most of them had never seen end to end. I had authority over none of them.
Alignment started with a shared picture of the user.
To align a team that had never seen ReportCaster, I first gave them its users: the Reporting Guru who lives in it all day, and the BI Developer who touches it occasionally. One redesign — and one shared mental model — had to serve both.
“I spend a lot of my time providing context around reporting.”
The go-to who just gets it — both the business and the data side. Runs and schedules constantly, knows every quirk, and needs speed, density, and nothing in the way.
“I’ve seen any number of people who have no clue what [messaging] means.”
Has worn every hat — Developer, Admin, BA, DBA. Schedules one now and then, carries no memory of the legacy quirks, and needs contextual guidance and an obvious path.
One redesign — and one shared mental model — had to serve both: the Reporting Guru who lives in it all day, and the BI Developer who touches it occasionally.
I onboarded roughly twenty people to a product they owned but had never fully seen.
Lead architect, lead engineer, a full engineering squad, a new PM, QA, documentation, SMEs, support. I ran dozens of demos, walked the legacy flows, and explained the failure states, retry logic, and bursting behavior users had been hacking around for years. I translated decades of tribal knowledge into UX rationale a team could build from, mediated between engineers when interpretations conflicted, and documented every workflow and edge case. Once the architecture was set, I onboarded, mentored, and handed ReportCaster off to two junior designers so I could move to ML — then picked it back up about a year later, after those designers were laid off, becoming the only designer left on the team, alongside my director and a contractor.
The first demo of the redesign was the scheduling workflow, to about 200 people. The credibility didn't come from a title — I had authority over none of them. It came from understanding the system well enough to make it make sense to everyone else. I was the youngest person in a room of engineers who'd been on the product for decades — and by the end, they trusted my read on it. I'd earned an unspoken authority on ReportCaster's experience.
“From the start, she impressed everyone with how quickly she grasped all aspects of a highly intricate system and translated that understanding into a clear, modern, and user-centered design.”
Getting in got
shorter.
Reaching each tool took fewer clicks — Explorer from four to one, the rest from four to two — while the workflow inside each tool stayed the one people already knew. I modernized it without breaking a single legacy schedule type — no loss of legacy functionality. (End-to-end clicks still vary by configuration, so I don't claim one number for the whole workflow.)
Recurrence, in plain English.
Scheduling a recurrence was once a guessing game. Now you set it with simple controls and read it back as a natural-language summary before you save — no more cryptic cadence settings.
Set a recurrence with simple controls, then read it back in plain English before you save — every cadence, and an invalid one that can’t be saved (the end date must fall on or after the start). No more cryptic cadence settings.
The shipped redesign, end to end.
Fewer clicks to reach it. A clearer flow once inside.
These are clicks to reach and open each tool — not the end-to-end workflow, which varies too much by configuration to claim a single number. I say that on purpose: it's the honest figure.
The same modal pattern — every asset type.
Schedules, distribution lists, and access lists are all created the same way, from the same “+” menu, with the same shape. Learn one and you've learned all three.
Distribution lists are created the same way, from the same “+” menu, with the same shape. Learn one and you’ve learned all three.
Access lists are created the same way, from the same “+” menu, with the same shape. Learn one and you’ve learned all three.
And the members inside them, managed the same way.
Each list opens to a populated member table — a burst value beside every recipient. Distribution lists hold email recipients; access lists hold users and groups; the table is the same shape either way.
A decades-old scheduler that finally speaks Slack.
Schedule a report straight to the channels teams live in. Right-click → Schedule offers Email, FTP, Google Chat, Microsoft Teams, Printer, Report Library, Repository, and Slack — and picking a messaging method opens a focused delivery dialog.
The fifth subsystem, surfaced.
Admin — job health and configuration — came out of menus buried three clicks deep and into its own highly-visible tab in the Management Center.
The fifth subsystem, surfaced — configuration and job status came out of menus three clicks deep and into their own ReportCaster Console tab in the Management Center.
.png)
And the job log, embedded in context.
Shipped.
And the customer said so.
ReportCaster shipped in April 2024. Customers stayed. A five-year contract worth millions was signed after. At a Virtual User Group I co-hosted, a long-time customer praised the redesign directly, on the record — on WebFOCUS's own channel.
Recognized by the people who'd know.
“She made a significant impact modernizing UX across our legacy enterprise products. She brings a rare combination of strategic thinking, design intuition, and the ability to work seamlessly across product, engineering, and business teams.”
“She approaches her work with a fearless attitude and is never afraid to explore new ideas or directions. Anuja is willing to take on difficult problems and push for creative solutions, even under tight timelines.”
What I'd push harder forThe platform-wide filtered Explorer
The idea that RC Explorer — and every subsystem's assets — could share one filtered-view pattern was deferred on timeline. It was the idea that could extend the filtered-view pattern across the whole platform — deferred on timeline, not merit. I'd fight for it earlier, with a smaller first slice. And I'd push the roadmap further: scheduling straight from Designer, the Reporting Server, and the IQ Plugin — generate an insight and schedule it in the same breath.
What it left behindA system ready to grow
Beyond the shipped screens: a consistent creation pattern, a unified mental model, and an architecture that new subsystems can extend — instead of a decades-old product that could only be maintained.
A decades-old system,
ready for the next one.
The engine didn't change — it still powers the schedules and distributions those customers depend on. What changed is that it finally works with the people who depend on it, not against them. And it's built now to grow, instead of ossify.