CASE STUDIES · ABBVIE
NGA Platform
Designing the Foundations of a Global Analytics Platform
I was brought in to map information architecture for a new internal platform. What I found was not an architecture problem. It was a system without foundations — no shared structure, no design governance, no process for onboarding the 30+ dashboards that needed to move into it.
I built all three. Then I documented them well enough that other designers could own them.
Project details
CLIENT
AbbVie
THE SCOPE
Information Architecture
Design System
Design Leadership
Dashboard/BI Migration
MY ROLE
Product Designer
THE TEAM
Product Designer
Stakeholders
Project Managers
Developers
Context
01 · THE PROBLEM
AbbVie's business units across America, Europe, and Asia each measured performance in their own way. Their own tools, their own structures, their own logic. Power BI in one region. Qlik in another. No shared language, no comparable data, no unified view.
The Next Generation Analytics (NGA) platform was built to fix that: a single internal system where every business unit could measure the same things, the same way, regardless of geography. The vision was clear. The path to getting there was not.
When I joined, the platform had begun development but lacked the structural foundations to support what it was supposed to become. Three problems were compounding each other.
01.
Fragmented product structure
Features were being designed in isolation. Built to answer immediate stakeholder requests, with no map of how they connected. Nobody had a complete picture of what the platform was, or where it was going.
02.
Inconsistent design practices
The component library (not a formal Design System) was rigid, poorly documented, and frequently detached during design work. Design and development were drifting apart with every sprint.
03.
No migration process
Business units were being asked to move their dashboards into a platform that was still maturing; with capabilities that didn't always match what they were used to. Without a process, every migration generated significant rework and slowed development.
These were not separate problems. They were the same problem at different layers of the system.
What I did
02 · THE PROCESS
I approached this as a system-level initiative. The goal was not to design interfaces. It was to build the structural foundations that would allow the platform (and the teams using it) to scale. That meant working across three parallel tracks, each one making the next possible.
2.1 Making the system visible
Before anything could be fixed, someone had to understand what existed.
2.1.1 INFORMATION ARCHITECTUTRE
I conducted a comprehensive analysis of the platform's current state: mapping features, interaction flows, information architecture, and dependencies between modules. Using Figma and FigJam, I built a visual architecture map. A single artifact that showed how every part of the platform connected, and where it didn't.
What the map surfaced was significant: duplicated feature concepts, unclear navigation structures, interaction dead ends, inconsistencies in naming and labeling across modules. None of it was visible from inside a single workstream. You had to see the whole system at once.
Flow Example: "View Graph Asset" interaction flow
One small section of the platform-wide architecture mapping. Documented using a breadboarding approach: places, affordances, and connection lines without visual styling. The method kept review sessions focused on flow logic and usability decisions, rather than derailing into aesthetic discussions before the structural problems were solved.
2.1.2 FEATURE SPECIFIC FLOW: TRANSLATION PROCESS
One gap the IA work surfaced had direct product implications: the platform was being built for a global user base, but its content was structured in English only. The stakeholders I worked with were all English-fluent; but the end users, the sales reps in each region, were not. A platform designed to unify global analytics needed to be readable in the language of the person using it.
Content translation process flow (fragment)
Mapping how content moves from creation to translation to regional publication, and how users interact with language settings within the platform.
I mapped and designed the translation process end to end: how static content would be authored, reviewed, translated, published, and managed per region. This included the language selection experience for users, the notification and review flows for translators, and the governance model for adding new language profiles to the platform. The feature addressed a structural gap that localization alone couldn't solve.
The architecture map and the translation flow together became reference tools beyond design. Leadership used them to prioritize new capabilities, resolve naming conflicts across teams, and make roadmap decisions with a shared visual language.
2.2 Rebuilding the design system
With the architecture visible, the next layer was the interface itself.
2.2.1 CURRENT STATUS: DESGIGN LIBRARY
The existing design system functioned more like a static component library than a true system. Components were rigid, isolated with minimal documentation, no token structure, and no clear usage guidelines. They were regularly detached because the system couldn't accommodate design needs, which meant every file was diverging from the last. Design and development had no shared source of truth.
2.2.2 AUDIT & REESTRUCTURATION
I ran a full audit: the existing component library, active design files, and implemented components within the platform. Then I restructured the system from the ground up.
Key changes:
Defined design tokens for color, spacing, and typography
Implemented variables to support flexible component behavior
Introduced master components for common UI patterns
Brought color contrast up to WCAG AA standards across the system
Created component documentation covering construction, usage guidelines, and interaction states
Established a branching workflow for design system updates, so changes could be reviewed before integration into the main library
2.2.3 GOVERNANCE & ADOPTION
Before the restructure, fewer than 10% of components remained linked to the design library. After: approximately 80% adoption across the platform.
That number matters beyond adoption metrics. It meant every dashboard built during migration had a consistent structural foundation. The design system became the condition that made the migration work possible — not a parallel initiative.
2.3 Designing the migration framework
Moving 30+ dashboards from external tools into a platform that was still maturing and couldn't always replicate what teams were used to.
There was no process for this. Nobody had migrated into NGA before. So the first two migrations: Italy and Spain business units, running in parallel.
Running both migrations simultaneously made one thing clear: no single rigid process would hold across every business unit. Each team arrived with a different starting point, a different stakeholder structure, a different level of documentation maturity.
2.3.1 THE STAKEHOLDER PROBLEM
The hardest work in this project was not the design files. It was navigating teams that had built their reporting tools to match their mental models, and were being asked to let go of both.
Resistance rarely showed up as explicit pushback. It showed up as scope expansion: requests for features the platform couldn't yet support, requirements that replicated old interaction patterns exactly, an expectation that migration meant replication. My role was to hold that tension. To acknowledge what mattered about the existing system while making a clear argument for what the platform could deliver in a first iteration. Design prototypes became the primary communication tool; not for approval, but for constraint visibility. Stakeholders could see, in a working artifact, what the platform could and couldn't do.
That shifted conversations from "why can't you replicate this exactly" to "what's the best version of this we can build right now."
A PRD documented the outcome of those conversations: what we were building, why certain decisions were made, what constraints shaped them, and what was deferred. It gave stakeholders a place to see their input reflected, even when their exact request wasn't implemented.
Iteration cycles that had previously required 11–12 sessions to reach alignment (with the first business units that went through the migration process) dropped to approximately 3 (for the last business units).
2.3.2 FORMALIZING THE PROCESS INTO GOVERNANCE
Patterns from Italy and Spain became the foundation for a formal Ways of Working document; a structured process guide co-maintained by the Core Design Team and distributed to all Business Unit Designers working within the platform.
The document defined seven steps, from stakeholder identification through final sign-off: how to scope a migration, what questions to ask in a demonstration session, how to document KPIs in the Layout Playground (FigJam), how to build initial drafts using approved components in the Layout Drafter Library (Figma), how to run review cycles, and what constitutes an approved handoff for development.
It introduced a satisfaction rating model — stakeholders rate designs from 0 to 10, excluding 7, and name what would move their score one point higher, which gave the review process a defined endpoint and reduced subjective feedback loops. And it distributed responsibility clearly: Business Unit Designers own the process. The Core Design Team provides guidance and quality review. Development implements only what has received formal written sign-off.
Dashboard layout templates built from Design System components
Used to communicate platform capabilities, grid constraints, and available chart types to Business Units Designers onboarding to the migration process.
To support designers working within the framework, I built a set of layout templates using Design System components. These templates demonstrated what the platform could actually render: available chart types, grid constraints, component flexibility limits, correct data visualization patterns. They were embedded in the Confluence documentation alongside the Ways of Working guide, giving designers a visual reference they could work from directly, not just a written process to follow.
The result: Business Units Designers across could run migrations with significantly more autonomy, and the Core Design Team could focus on quality review rather than repeated clarification of the same constraints.
What I achieve
03 · THE OUTCOMES
3.1 RESULTS
Design System adoption:
10% → 80%
of platform components linked and in active use.
Review iteration cycles:
~11 sessions → ~3
through structured stakeholder alignment and capability mapping.
Migration:
30+ dashboards
completed at design level under 5 months, with no pre-existing process.
A translation process designed end to end
Addressing a structural accessibility gap for non-English-speaking users across all regions.
A visual information architecture map
Adopted by leadership as a reference for feature prioritization, roadmap planning, and cross-team alignment.
Formalized Ways of Working framework
7-step process, defined roles, sign-off model, distributed across all Designers working on the platform.
Layout templates and documentation
Enabling Designers to run migrations with greater autonomy, reducing Core Team clarification overhead.
3.2 MY LEARNINGS
This project reinforced something I hold as a design principle: design at scale is not about creating interfaces. It is about shaping the systems that allow products, and the teams behind them, to grow. By focusing on structure, governance, and communication between teams, design became a tool for aligning technical capabilities, business goals, and user needs into a coherent product ecosystem.
The framework I built is not a checklist. It is an argument about where decisions should be made, who needs to be in the room, and what artifacts need to exist before the next phase can begin. That argument was earned through the specific friction of running two parallel migrations with different starting conditions and watching where each one held, and where it didn't.
2026 CAROLINA TORRES
CONTACT
carolina.tcast@gmail.com
(+52) 442 106 2012
Querétaro, MX
ELSEWHERE
Medium