Three AI engines.
Three separate homes.
I'd already designed and modernized each engine on its own — Natural Language Query, the automated Insights, the ML workflow — each in its own menu, each barely found. IQ is the culmination: the three I owned, brought into one home. One dataset, one mental model, one place for intelligence that already existed.
Powerful. Paid for. Impossible to find.
The engines weren't the problem. Their addresses were.
Nothing here needed to be invented twice — I'd already designed and modernized each engine myself, one at a time. The ML workflow inside the Reporting Server: the Predict Data landing, the train-model wizard, the confusion matrix. Natural Language Query and automated Insights, each in its own menu. Powerful engineering, sitting at low adoption because it was essentially invisible to the users who needed it most.
The problem was the addresses. NLQ and Insights were buried in the Explore Data popup; ML was reached by right-clicking a dataset. Two paths, two mental models — no wonder nobody found them. Leadership read the low numbers as a model problem, sure the forecasts weren't good enough. The truth was simpler: the AI worked. People just couldn't find it.
So IQ was never about building the intelligence — I'd already built it. It was about giving the three engines I owned one home. My PM and I seized the opportunity during product-consolidation talks; I designed dozens of concept mockups, ran three to four meetings a week — figjam, confluence, whiteboard, or just talking it through — across timezones, and pitched the vision. My PM and I got the VP's approval; my work drove the concept. We owned it end to end.
Each engine has its own story — Natural Language Query and Automated Insights in the Explore Data case, and ML Functions. This case is about the architecture that made the three of them one product.
The PM wrote the tickets
after seeing my mockups.
I architected the unified cross-functional workflows across all three engines before a single Jira ticket existed.
The unified structure — one plugin, every engine under it.
Three scattered menus became one plugin inside the existing Hub — HUB → IQ Plugin → four engines, each opening onto its own workflow. One entry point, one mental model; the restructure was front-end. The engines already existed; the architecture is what made them one product.
One entry point, built inside what already existed.
I pushed for cross-functional alignment in a way the organization hadn't done before — architecting the workflows before anyone asked for them. My PM wrote the Jira tickets after seeing my mockups. We ran three to four meetings a week across timezones to keep engineering feasibility honest.
The integration was smart, not expensive: three scattered menus became one destination inside the existing Hub — the heavy restructure was front-end; backend changes followed as features were added; one consistent mental model. The engines stayed exactly as they were; only their addresses changed.
Before a ticket existed, it was on paper.
The hub started as hand sketches and low-fidelity wireframes — the architecture worked out before engineering was ever asked to build it.
NLQ, Insights, and ML — filed under one Hub.
The structure that turned three scattered menus into one destination, and the layout showing exactly how it slots into the Hub that already existed.
The choice that shaped the hub:
routing by tool vs. by dataset.
The fight that shaped the whole hub. The old model was tool-centric — every tool remembered its own dataset. I argued the dataset is the project.
Pick the data four times, or once.
Tool-centric → project-centric — the structural foundation of the hub. The old model made every engine remember its own dataset, so you picked the data four times and each tool held its own copy. My redesign lifts the dataset into a global header that binds all four tabs at once; open a different dataset and it spins up a new project tab, like a browser — isolated state, and the memory leaks the old model caused simply disappear.
Project-centric workspace routing — one dataset, every tab.
The battle I won: data-centric, not tool-centric. The dataset is the project — it lives in a global header and binds every tab at once, so you never re-select it four times. Open a different dataset and it spins up a new project tab, like a browser — isolated state, and the memory leaks the old model caused simply disappear.
The dataset is the project.
Tool-centric routing meant a user picked their data four times — once per engine — and each tool quietly held its own copy. I argued for the inverse: data-centric routing. The dataset lives in a global header and binds every tab at once, so choosing it once applies it across Discover, Insights, Ask a Question, and Predict Data.
Open a different dataset and it spins up a new project tab, the way a browser opens a new tab — which isolates each project's state and quietly killed the memory leaks the old shared-state model caused. This routing model was the structural foundation of the hub, not a surface change.
The dataset rides in the global header — into every engine.
Chosen once, it binds every tab; here the same dataset carries straight into Predict Data's train-model wizard. Built, locked until release.
Four iterations
to land it.
V1 too dense. V2 too passive. V3 competed with the global Hub navigation. V4 landed: an outcome-described engine nav and a first-run page that teaches instead of intimidates.
The dense first draft, and the version that shipped.
The first Discover page, and the one that shipped. V1 crammed a global search bar, preferred-data-source cards, and auto-generated data stories onto a single screen — too dense to parse. V4 stripped it back to an outcome-described engine nav, three clean tabs, and a first-run page that teaches instead of intimidates.
Every version, and the verdict on it.
Three dead ends, and the one that landed. V1 crammed a search bar, data-source cards, and data-stories onto one page — too dense. V2 was a passive explainer. V3’s heavy “Get Started” drawer competed with the global Hub navigation. V4 landed: an outcome-described engine nav, clean tabs, and a first-run page that teaches instead of intimidates.
V4, walking — the built IQ Plugin.
Three dead ends, and the one that landed.
V1 crammed a global search bar, preferred-data-source cards, and auto-generated data stories onto a single page — too dense to parse. V2 overcorrected into a passive explainer. V3's heavy “Get Started” side drawer competed with the global Hub navigation it was supposed to live inside. V4 landed: a calm engine nav down the left, three clean tabs, and a page whose job is to get you moving.
Three dead ends, in the actual pixels.
The wrong turns at full fidelity — before V4, the Discover page below, finally landed.
Outcome first.
Tool names never.
The engines shown as scannable, outcome-described entries — each one says what it does for you, wrapped in a “What are…?” explainer that takes the fear out of AI. Describe your goal; the hub routes you to the engine.
Uncover hidden gems and fascinating trends in your data with ease. Select your data, hit “generate insights,” and watch meaningful visualizations come to life — helping you spot trends, patterns, and key findings you might have missed. No data expertise needed.
The landed Discover page — outcome-described engines, not a list of technical tool names. Each engine says what it does for you, a “What are…?” explainer removes the fear of AI, and Tutorials + Learn-more turn the empty first screen into a place to start. This is the version that made the invisible findable.
The real Discover page, built — locked until it ships.
The engine nav down the left, the outcome-described “What are…?” explainer, and the Tutorials and Learn-more panels — the same page, one tab per engine.
I defended tiles against
thirty-year architects.
The lead architect and the WebFOCUS architect wanted traditional list views. I proved list views were the exact reason these features were invisible in the first place.
Newest in a room of veterans. Won it with evidence.
Nearly everyone I worked with had 20+ years there — some 30, some 40. The lead architect and the WebFOCUS architect pushed hard for traditional list views. I demonstrated that list views were the exact reason these features were invisible — and shifted their mental model toward large, outcome-described tiles that give immediate context to intimidating AI, using industry precedent and interaction logic. Despite being the newest person in the room, I backed the architecture with user evidence; my director handed me the reins and mentored me, and I drove the integration.
The last fight was the tutorials. The legacy install path was hostile, and the docs wouldn't render — a cross-origin wall stopped the tutorial PDFs from loading into the in-app sidebar. Rather than drop the guided layer, I designed a one-click “Install Tutorials” opt-in, and we stood up a CORS middle-tier proxy to stream the PDFs into the iframe. The Tutorials and Learn-more panels on the Discover page above are what that fight bought.
The engines didn't change.
The architecture did.
We didn't add capabilities or rewrite a single engine. We gave three powerful, invisible tools one home — high-leverage work: no new features, just making powerful tools findable.
Three engines, one place. The real hub — built, awaiting release.
Natural Language Query, automated Insights, and machine learning, unified under a single plugin. Locked until it ships.
The same dataset, every engine — opened right in the Hub.
The depth underneath — model comparison, and every insight tracked.
Powerful engines, re-homed intact: compare every algorithm in one screen, and watch each insight generate from a single panel.
“Anuja is a standout design leader who brings clarity, collaboration, and strategic impact to every project.”
Built, test-complete — and validated.
The unified DSML Hub was 80–90% code-complete when I was laid off; visual polish remained, then QA — the release was pushed to a future date as priority shifted to the App Studio → Designer migration. The engines' own wins landed on their own timelines — the NLQ redesign, automated Insights, and the ML workflow each shipped or matured separately. IQ's contribution isn't a new feature; it's the architecture that turned three invisible tools into one product you can actually find your way through.
“She led UX design initiatives with remarkable creativity, empathy, and precision — consistently translating complex product requirements into intuitive, visually engaging experiences.”
“What sets her apart is her empathy and cross-functional fluency — she listens deeply, challenges with purpose, and quickly earned the trust of stakeholders at all levels.”
The clearest sign of that trust came when I got back from maternity leave: the engineers told me they'd missed how I worked — understanding the system, asking the right questions, deciding from evidence. That kind of context doesn't transfer through a handoff doc. It comes from being genuinely invested in the problem.
What I'd push harder forThe guided layer, earlier
I proposed a dedicated “Get Started” panel up front; through iteration we improved the tutorials, the Discover page, and the Explore-Data header instead — better UX, same goal. I'd fight for the guided layer from week one next time.
What I'd do nextEcosystem integration
Connect ReportCaster and IQ to auto-schedule generated insights, and turn Ask a Question into a chat interface for the entire platform.
Not more features.
One architecture.
High-leverage work: no new features, just making powerful tools findable.