Role
Data Research Assistant
Duration
May 2025 - Dec 2025 (28 Weeks)
Team
Me, Sr. Director of Data Strategy
Context
The Brief
The Nielsen Norman Group is a global authority in user experience (UX) research and usability, they help organizations design products, websites, and software that are intuitive, efficient, and user-centered. They set industry standards for evidence-based design, conducting rigorous research, usability testing, and training that influence UX practices worldwide.
The Problem
Reporting teams were buried in dashboards, not insights.
NN/G's internal reporting and analytics workflows were highly manual and time-intensive. Monthly reports required pulling data from multiple platforms including LinkedIn, Facebook, Instagram, YouTube, Spotify and Mailchimp. Each platform had its own dashboard, making data extraction fragmented and repetitive.
Once collected, this data had to be manually formatted into a fixed reporting template, followed by the calculation of organization-specific metrics defined by the company. Ensuring accuracy and consistency across channels was critical before insights could be shared with senior leadership.
Graphic Depicting the entire Process for Monthly Report
The workflow looked like this: Dashboard → Export CSV → Clean Data → Apply Custom Metrics → Format Template → Re-check Numbers → Share
The Issue with the Process was:
Took days to nearly a week each month
Prone to Human Error and inconsistencies
Difficult for leadership to access on-demand insights
Process
Research & Discovery
To understand why previous automation efforts had failed, I began by conducting stakeholder interviews with the analytics team and auditing the full monthly reporting workflow end-to-end. Rather than assuming the issue was purely technical, I focused on uncovering friction points, behavioral patterns, and trust gaps within the system. What initially appeared to be a tooling problem quickly revealed itself as a workflow design and adoption problem.
Key Findings
Automation scripts already existed but weren’t being used
1️⃣ Analytics being produced Didn’t Eliminate Manual Work
The abandoned scripts saved time on data pulling, but still required a day or two of formatting, validation, and metric calculation. The team felt it was faster to just use dashboards directly.
2️⃣The reports told you what happened this month. They didn't tell you why it mattered.
When reviewing reports, management wanted to see trends over time and comparisons for the same months in previous year which meant digging through old reports or switching back to multiple dashboards. The monthly view didn't tell the full story.
3️⃣ Trust Was Low
Since it still required extra steps, the team reverted to dashboards. The core issue wasn’t technical. It was confidence, flexibility, and integration into existing mental models.
Reframing the Challenge
How Might We:
The Solution
Not Another Dashboard..
Early in the process, it became clear that NN/G did not need yet another static dashboard.
What they actually needed:
The core requirement was a flexible system that could reliably generate visualizations and reports while adapting to existing metrics and reporting standards. Basically a system non-technical stakeholders could trust.
So instead I designed a Reporting Engine.
Strategic Decision
Designing a Reporting Engine
I began by reverse-engineering the monthly reporting template, mapping every field, custom metric, and validation rule that had previously lived in spreadsheets. Everything was translated into logic ensuring calculations were defined once and applied consistently.
Using Jupyter Notebooks, I designed and built data pipelines that pulled structured data directly from platform exports and APIs, computed organization-specific metrics, and generated standardized visualizations. What once required manual formatting and cross-checking now became a repeatable system.
The visual layer was intentionally designed to highlight trends and trajectory not just monthly snapshots helping leadership to quickly interpret performance.
The Tool
Why Jupyter Was the Right Product Decision
Choosing Jupyter was not a technical preference it was a decision rooted in transparency, scalability, and adoption.
1️⃣Enabled transparent data handling. Anyone could trace outputs back to raw inputs, which significantly increased trust in the system.
2️⃣It allowed for modular architecture. Each platform pipeline followed the same structure: fetch → parse → calculate → visualize → export creating consistency across channels. This standardization reduced cognitive load and made the system easier to maintain.
3️⃣That modularity helped with reusability. This pipeline became the structural template for Facebook, LinkedIn, Instagram, YouTube.
4️⃣Above all, the notebook itself functioned as living documentation. It served as a training artifact, governance layer, and technical reference in one place.
