Prepare
One core guide, tuned per team: adopters on friction, others on discovery.
AI Native Product Designer
I design intelligent products that make complexity feel simple.
Projects that showcase the range and depth of my craft, from enterprise strategy to platform development.
Led the end-to-end transition from fragmented Excel-based financial planning to a scalable, trusted enterprise platform.
Excel was the primary tool for financial planning at Novartis, but at global scale it became slow, inconsistent, and difficult to govern.
Finance teams relied on fragmented models for cost management, planning, and forecasting, creating operational risk and heavy dependency on manual reconciliation.
I led the transition from Excel-based planning to a scalable platform, structuring fragmented workflows into a system designed to support global teams and build trust at scale.
This wasn't a cosmetic issue; it was a systemic breakdown. Planning, pricing, and forecasting lived in silos owned by different people with zero version control or audit trails.
Every cycle, teams lost days just trying to get global and local numbers to agree. Because there was no way for users to help themselves, our subject-matter experts became human bottlenecks.
Knowledge was trapped in people's heads rather than integrated into the system, making high-stakes scenario planning nearly impossible.
Discovery revealed that teams didn't use Excel because it was efficient—they used it because it was flexible and trusted. To drive adoption, we couldn't just "digitize" spreadsheets; we had to replicate that flexibility while solving for what Excel lacks: Global Governance, Scalability, and Predictive Intelligence.
Next Steps: I architected a three-layered roadmap to transition users responsibly:
Design plan shared with PO for next steps
Instead of designing a single solution, I led the work as a platform initiative, sequencing capabilities to reduce risk and drive adoption incrementally.
We mapped legacy Excel workflows end-to-end to understand where trust broke, where manual effort accumulated, and where decisions actually happened. This led to a layered platform strategy — rather than a monolithic product.
I led this initiative end-to-end — across discovery, strategy, and experience definition. This was leadership through structure, decisions, and alignment — not just execution.
Standardized cost data to build trust and governance. Centralized corporate and central costs with consistent structures and reliable reporting.
Forward-looking planning and forecasting capabilities. Demand and pricing scenarios with revenue impact modeling and strategic planning.
Intelligence and optimization for cost management. Granular cost views with optimization opportunities and predictive signals.
RAG-based chatbot reducing support dependency. Answers repetitive finance and tool-related queries with contextual guidance using documentation, dashboards, and definitions.
After launching Phase 1 of the platform, we conducted a survey to understand how users were adopting the Market Model application. The survey was distributed to 50 users via Microsoft Forms.
The survey responses made it clear we needed to rethink our approach. Then, in Phase 2, Novartis shared new brand guidelines. This gave us the opportunity to revamp the project—addressing what users actually needed while aligning with the updated design system.
The platform eliminated days of manual reconciliation work. Teams shifted from getting numbers to agree to using those numbers for analysis and strategic decision-making. Subject-matter experts are no longer bottlenecks, and knowledge is now embedded in the system rather than trapped in people's heads.
Synthesized capability index for illustration — not literal measured units.
Feedback from key stakeholders who worked closely on the project.
What I appreciated most is he doesn't just take a brief at face value, he'll push back or ask questions if something doesn't line up with what the business actually needs. That saved us more than once. We actually finished ahead of schedule on Market Model and a chunk of that was because he caught requirement gaps early instead of mid-build.
What stands out is how fast he adapts when priorities shift without losing the thread on product consistency. He asks the right questions early and his recommendations are always grounded in what's actually feasible, that's rarer than it sounds.
Solid, consistently. Takes requirements and turns them into actual structured UX work without much back and forth. He'll also catch a technical or QA issue and bring it up before it becomes anyone else's problem.
I'll be honest, Market Model wouldn't be where it is without him this year. Priorities kept shifting on us and he never seemed thrown by it kept bringing ideas, kept pushing for us to standardize things properly across the planning tools instead of patching as we went. What I really valued was how he moved between the business side and engineering: QA, feasibility, all of it, without ever losing sight of what the actual user needed. That's not something you can fake.
One of the most reliable people I've worked with on complex builds. He doesn't just execute, he flags improvements before they become problems and communicates clearly enough that nothing gets lost in translation.
What I appreciated most is he doesn't just take a brief at face value, he'll push back or ask questions if something doesn't line up with what the business actually needs. That saved us more than once. We actually finished ahead of schedule on Market Model and a chunk of that was because he caught requirement gaps early instead of mid-build.
What stands out is how fast he adapts when priorities shift without losing the thread on product consistency. He asks the right questions early and his recommendations are always grounded in what's actually feasible, that's rarer than it sounds.
Solid, consistently. Takes requirements and turns them into actual structured UX work without much back and forth. He'll also catch a technical or QA issue and bring it up before it becomes anyone else's problem.
I'll be honest, Market Model wouldn't be where it is without him this year. Priorities kept shifting on us and he never seemed thrown by it kept bringing ideas, kept pushing for us to standardize things properly across the planning tools instead of patching as we went. What I really valued was how he moved between the business side and engineering: QA, feasibility, all of it, without ever losing sight of what the actual user needed. That's not something you can fake.
One of the most reliable people I've worked with on complex builds. He doesn't just execute, he flags improvements before they become problems and communicates clearly enough that nothing gets lost in translation.
Replacing Excel isn't a UX problem: it's a trust, ownership and system-design problem.
Going in, I assumed the fix was obvious: give people a better interface than Excel and they'd switch. What I didn't get until we were deep into it was that nobody was using Excel because it was good, they were using it because it was theirs. They trusted it, could bend it however they needed and no tool we built was going to win by being stricter than that.
So the real work wasn't removing that flexibility, it was earning the right to replace it building the governance people could actually rely on, the intelligence that made the tool worth the switch and enough self-service that people stopped needing someone else's permission to get an answer. Skip any one of those and you just end up with a nicer-looking spreadsheet that nobody adopts.
That's the thing I carry into every platform or AI project now, the interface is rarely where the real problem lives.
Open to product design and platform strategy roles, or a conversation about your own data platform problem.
© 2026 Shivanshu Mathur. All rights reserved.
Led the research that turned Forge from an internal platform developers avoided into Atlassian's primary app-development standard.
I was given the task to shape a public developer site for Forge. Before designing anything, I asked how it was used inside Atlassian today.
Usage data and talks with the founding team showed the same thing: internal adoption was effectively zero. Even engineers on adjacent teams didn't know Forge existed. So the brief changed. Before building a public site, we needed to know: is this an awareness, education, or product problem, and where does the funnel break?
That question, awareness, education, or product, couldn't be answered by opinion, so I structured the investigation into six deliberate stages: Clarity, Questions, Refinement, Methods, Analysis & Synthesis, Integration. Each stage forced a decision before the next one began, so fieldwork never started on an assumption.
To understand how teams were actually using Forge, we rolled out a company-wide survey as the first step, before any interviews or design work. The responses gave us the real shape of the problem.
The instinct was to fix the docs. The data said otherwise: 54% never heard of Forge, 31% knew it but not why, and 15% tried and got stuck. Those are three different problems. Better docs only help the last group.
Underneath all three: docs lived across six scattered sources, with no single front door.
Underneath every stage: 6 scattered doc sources, no trusted front door.
Never heard of Forge, so they stick with whatever the team used last time.
Knows Forge exists, but can't say what value it actually adds.
Started a project, then hit a wall with no way to get unstuck.
The archetypes told us who was struggling and roughly how many. They didn't tell us why, in their own words, or where exactly things broke down. So before recruiting anyone, I turned that gap into three specific, testable questions, one per archetype, each tied to a decision it would inform.
Unaware Builder. At what point does a developer first learn Forge exists, and through what channel?
Curious-but-Unconvinced. Once aware, can developers correctly describe what Forge does, doesn't do, and where its limits are?
Tried-and-Bounced. Where exactly in the build process do developers who try Forge abandon it, and why?
Recruiting followed the archetypes directly, enough from each group to trust the pattern.
One core guide, tuned per team: adopters on friction, others on discovery.
Teams sat across 5 zones. Ran staggered blocks over several weeks.
17 interviews mapped to the three archetypes, enough to trust the pattern.
Patterns repeated across teams that had never spoken to each other, which is what made them trustworthy rather than anecdotal.
Loom explicitly said there wasn't one clear offering anywhere, no single page listing everything the platform provides. WAC's second group asked for exactly that: one unified place for every doc, "what we offer, why, how it works."
JSM's first group had been using the platform's design-system primitives for months without knowing newer versions or features existed, they'd onboarded once and never heard about anything since.
Every team that succeeded pointed to a specific person who'd helped them directly, Loom found a two-year-old doc and had to track down its author personally to get an accurate picture.
WAC's second group asked directly for a high-level diagram of how everything fit together, "not just request-time, build-time too," because nobody on their team could fully explain what was happening under the hood.
WAC's first group found the documentation was written around one specific internal app; anything outside that shape required guessing.
After the interviews, I ran a working session with the Head of Engineering, Senior Engineering Managers, and Principal Developers, card sorting the raw findings, ranking them, and ideating on what a fix would actually look like.
Emotion curve across nine stages. Friction climbs from curiosity into a sustained anxious peak at Testing through Monitoring.
Raw findings sorted into an impact-effort matrix, then into a single plan.
Getting this structure right wasn't a single card sort, it took repeated sessions with the platform, security, and DevRel teams, each round exposing another layer of the codebase that needed its own place in the tree. What shipped is a five-level-deep IA spanning every part of how Forge actually works.
With a 200+ page, 5-level IA on the table, rebuilding around it was a real cost: design, development, content migration. Before committing any of that, I ran a tree test to check the structure actually worked, on paper, with nothing designed yet.
No baseline IA, only six scattered sources. 34 developers ran the same five tasks on the old sources, then on the proposed tree.
Engineering blocked the build until success hit a target. Round one failed; two tasks scored under 50% from unclear labels. Renamed and retested.
Average success rose from 46% to 84%. Gave-up rate fell from 21% to 4%. That unlocked the build budget.
The session converged on one answer: build a single public-facing page for Forge, the front door that had never existed. Every section on that page traces back to something a team actually said.
Collapsed 6 scattered sources into a single docs site, organized by the validated task-based IA, with an architecture-diagram library (the #4 most-requested item).
Created a dedicated Forge space in Atlassian Developer Community, so anyone could start a topic, join a discussion, or search existing answers in the open.
Built around the specific blockers from interviews (auth scopes, custom routing, styling overrides), not generic "getting started" content.
Added marketplace visibility so teams could see what others were already building with Forge, turning adoption proof into something developers could browse.
I led the research and experience strategy from Jan to Jun 2024, then handed over the validated IA, landing page structure, onboarding direction, and community model for development. Forge went live in mid-October 2024.
By July 2026, the public platform showed clear adoption across creation, tooling, and community activity. For a platform that started with almost no adoption signal, this became the clearest proof that we had solved the right problem.
Low adoption is rarely a communication failure. It's usually a signal that the system hasn't earned trust at the exact moment someone gets stuck.
Going in, the working theory was that Forge had a documentation problem. If I'd taken that at face value, I'd have shipped better docs and moved on, and adoption probably wouldn't have moved, because the docs were a symptom, not the cause.
The finding that redirected the project was the outlier interviews: every team that succeeded had an internal champion. The real gap wasn't information; it was the absence of a reliable path from "stuck" to "unstuck," which is a support and trust problem before it's a content problem. Fixing the docs and the support SLA and the IA together is what moved the number.
The pattern I now carry into every developer-platform project: find the moment someone gets stuck before you redesign anything.
Open to UX research and developer-experience roles, or a conversation about your own platform adoption problem.
© 2026 Shivanshu Mathur. All rights reserved.
A comprehensive guide to understanding and implementing agentic AI in UX design and product strategy.
Days 1–7
Days 8–15
Days 16–22
Days 23–30
Choose how the interface looks. Select Light, Dark, or Auto to match your system.
Auto mode will match your system's appearance preference.
Pick a highlight color that appears on buttons, links, and interactive elements.
Choose a preset or drag the slider to pick any hue across the spectrum.
Choose a typeface that's used across the entire interface.
Make text larger or smaller across the interface to suit your preference.
Drag the slider or click a label below to set the preferred reading size.
Set a desktop wallpaper. The selected image appears behind all content.
Click a wallpaper to apply it instantly. The active one is marked with a checkmark.
Version 1.0
Designed & built by Shivanshu Mathur
A personal dashboard inspired by the elegance of modern OS interfaces, crafted with care for every pixel.
The survey was rolled out to 3,000+ engineers across the org. 2,309 responded, a 77% response rate, giving us confidence the findings weren't a sampling artifact.
94% had never even tried Forge. Active usage rounded to 1%.
| Status | Percentage |
|---|---|
| Never tried | 94% |
| Tried, stopped | 4% |
| Actively using | 1% |
More than half had never heard of it. The funnel was leaking at discovery, long before any product gap.
| Response | Percentage |
|---|---|
| Never heard of it | 54% |
| Heard of it, unclear value | 31% |
| Tried it, hit a blocker | 15% |
No single source crossed 30%. Developers had no reliable default place to look.
| Source | Percentage |
|---|---|
| Bitbucket | 28% |
| Confluence | 24% |
| Internal wiki | 19% |
| GitHub Pages | 14% |
| Internal tools portal | 9% |
| Not sure / other | 6% |