Overview
Problem
Technical Wall
Design Pivot
System Impact
Outcomes
Data Collections Iteration
Lead Product Designer | Post → GA Launch
Designing a coherent data-collection ecosystem by unifying Tags, Datastreams, and Event Forwarding into workflows that improve onboarding, governance, and downstream clarity
View Quick Start Workflows
Project Snapshot
The Challenge
Bridging the “Integrity Gap” between user intent and system logic.
The Solution
Staged Validation & Progressive Disclosure.
Key Results
-32% Ingestion Failures | +38% Segmentation Confidence
Primary Users
Senior Data Architects (High-density modeling)
Overview
After I completed the GA of Launch Tag Management and improving rule-governance workflows, customer needs quickly expanded beyond client-side tagging. As Adobe Experience Platform (AEP) matured, organizations began ingesting more behavioral data from web, mobile, and server environments, but provisioning paths were spread across multiple tools.
I designed the early Sources and Destinations marketplace patterns, established service provisioning flows for Datastreams and Event Forwarding, and later unified these capabilities within the AEP Data Collection experience.
This work supported
- Behavioral and SDK data onboarding
- Datastream configuration
- Event Forwarding and Destinations provisioning
- Dependency transparency via System View
My Role
Primary designer responsible for workflows, IA alignment, provisioning patterns, and visualization of object relationships.
The Problem
Fragmented provisioning made data collection difficult to understand, govern, and activate
Key Problems
As AEP expanded beyond client-side tagging, new capabilities like Datastreaming and Event Forwarding introduced more flexible routing and transformation options. But customers did not yet understand how these new services fit into the overall data-collection ecosystem. There were no established provisioning patterns, no shared navigation model, and no clear way to visualize how data moved across services.
Teams struggled to:
- Understand when to use Tags vs Datastreaming vs Event Forwarding
- Configure new services without established IA or workflow patterns
- See how routing choices affected downstream destinations
- Diagnose misconfigurations without visibility into dependencies
Critical
No clear mental model for how new services connected
High
Provisioning steps were hard to understand
High
Routing was invisible, causing misconfigurations
Medium
Limited dependency visibility slowed troubleshooting
Cross-Team Workflow Analysis
The Technical Wall
Define a coherent provisioning and mental model for a next-generation data-collection ecosystem
I focused on establishing a unified data-collection workflow that improved clarity, onboarding, and downstream confidence.
Establish a cohesive platform entry point
Create clarity & consistency for users entering Data collection within AEP, positioning it as a fully integrated service rather than an external tool
Strengthen platform cohesion
Reinforce AEP’s role as the central platform by bringing Data Collection into its ecosystem by improving discoverability, governance, and long-term service alignment
Align user journeys across tiers
Ensure both free Launch users & paid AEP subscribers experience a coherent progression, enabling natural upgrade paths & reducing friction during migration
Build for scalability and future services
Lay a flexible architectural & design foundation that can adapt to new data services without major rework
Project Constraints
- Maintain Launch familiarity while easing users into the AEP shell
- design within iFrame limitations that restricted layout and interactions
- Create scalable patterns for mapping, ingestion, and navigation aligned with AEP standards
- Support client-side, server-side, and AEP provisioning without fragmenting navigation
Success Criteria
- Provide a unified left-rail with clear provisions states
- Maintain consistent mapping workflows across Data Collection and AEP
- Improve discoverability of new services through clearer hierarchy
- Increase adoption of Datastreams workflows based on pilot usage
The Design Pivot
A cross-functional effort involving data engineering, machine learning, and product teams that connected identity, enrichment, and downstream outcomes
Research & Discovery
- Mapped existing provisioning flows across Tags, Datastreams, Event Forwarding
- Interviewed customers, systems integrations, and internal teams
- Identified where misconfigurations occurred
Deliverables
Provisioning journey map
Service dependency diagrams
Persona navigation needs and provisioning states
Provisioning Journey Map
NEW Provisioning Workflow
Tracy has AEP Data Collections & Morgan has AEP RTCDP
NEW Provisioning Workflow
Tracy does NOT have AEP RTCDP
Adobe Experience Platform
Create Edge Dataflow
Create Schema
Create Property
Add Environments to Edge
Install AEP Web SDK
Publish AEP SDK
Implement Mappimg
Publish AEP SDK
Data Engineer
Design & Prototyping
I explored multiple navigation and workflow integration models. Focused on how to embed Data Collection within AEP’s shell while retaining Launch familiarity. Defined left-rail navigation patterns, waffle switcher flows, and progressive disclosure states that would scale with future services. These were designed to unify ingestion and mapping workflows with existing AEP data mapping patterns while preparing for upcoming features like serer-side tagging.
Deliverables
Navigation (Left-rail/switcher variants)
AI Workflow diagrams
Updated design system specs
Workflow recommendations and valid entry points
Updated Design System Specifications
Being informed of any larger system patterns will always help cross-teams understand best practices of how these patterns work
Left-rail Navigation Explorations
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Shell Navigation Switcher
3 Capabilities of Provisioning: Left-rail
1
User is provisioned for Tag Management ONLY
Introducing our users to new left rail UI design elements with a shift in category navigation, noun terminology changes, and added features with current landing pg onboarding experience, and “tool tip” design system patterns.
2
User is provisioned for Data Collection
Tag Management a& Datastreams & Event Forwarding
Once a user is provisioned for Event Forwarding Navigation expands to more features, Shell name changes, and onboarding educational content was added.
3
User is provisioned for Data Collection & AEP
This was defined as a long-term approach with more thought in regards to Palm sandbox transitioning for the new RealTime Customer Data Platform users and integration of property publishing experiences overall.
What is valuable:
Simplified Navigation levels with all nouns provisioned in left navigation.
Concerns to watch for:
Quick access navigation for this level of object/noun was ongoing as to what should be allowed/needed and what doesn’t make sense. Removing Launch quick access cards from AEC home page could be disorienting to current customers.
Adobe Experience League was also being revamped with new design systems and customer intent logic. So understanding long-term approach to educational content on AEC homepage and AEP homepage will always be ongoing research.
Development & Testing
- Validated correctness conditions for provisioning
- Partnered with engineering on routing and dependency logic
- User-tested onboarding flows with real datasets
Deliverables
Validation rules
Service consistency checks
AEP wiring for System View
QA Validation Matrix
Design Opportunities
Workflow Stage
Data Ingestion
Status
Pass
Validation Focus
Stream payload automation
Test Type
System
Expected Result
Data Ingests without delay or loss
Actual Result
All passed under Xs latency
Workflow Stage
Schema Mapping
Status
Pass
Validation Focus
Field auto-matching accuracy
Test Type
System
Expected Result
≥90% correct auto-mapping
Actual Result
XX% average
Workflow Stage
Mapping/QA
Status
Minor Fix
Validation Focus
Error surface clarity
Test Type
UX
Expected Result
Error message visible, clear resolution path
Actual Result
Error visible; label improved post-feedback
Workflow Stage
Identity & Dataflow
Status
Fix Applied
Validation Focus
Stream linking validation
Test Type
Integration
Expected Result
All streams link to schema and identity graph
Actual Result
xyz# schema mismatch logged
Workflow Stage
Activation
Status
Pass
Validation Focus
E-to-E ingestion-to-activation
Test Type
System
Expected Result
Data flows to activation w/ correct schema IDS
Actual Result
All succeeded
Workflow Stage
Workflow Navigation
Status
Pass
Validation Focus
Step clarity / task completion
Test Type
Usability
Expected Result
100% completion within 3 mins
Actual Result
4/5 completed <3 mins
Workflow Stage
Automation Mapping
Status
Pass
Validation Focus
AI recommendation reliability
Test Type
AI/Functional
Expected Result
≥80% correct mapping suggestions
Actual Result
84% accuracy
70
2
3
Test Round
70%
85%
90%
95%
Mapping Accuracy
Mapping Method
Auto-Mapped
Manually Corrected
1
2
Test Round
0
2
4
6
FieldSelection
Mapping
Preview
Validation
12
8
45
5
42
22
32
28
18
18
15
38
8
12
35
Text Fields
Date Fields
Number Fields
Select Fields
Custom Fields
Low
High
Manual Corrections by Field Type & Step
System Impact
Demonstrated measurable gains in accuracy, efficiency, and clarity across workflows
- Greater clarity across cross-service dependencies
- Stronger governance conversations with customers
- More predictable downstream activation
- Easier collaboration across internal platform teams
-36%
Reduced Navigation Time
+40%
Feature Discoverability
+25%
Task Efficiency
-20%
Accelerated Onboarding
Adoption Flow Performance: Navigation Redesign
Before:
Limited discoverability and unclear provisioning led to significant drop-off across stages
40%
20%
30%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Clearer navigation and entry points drove higher discoverability, smoother configuration, and a +60% increase in overall adoption.
After:
65%
32%
50%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Outcomes
Stabilizing the Ecosystem
By focusing on the Data Architect’s need for structural precision over feature breadth, the Schema Editor GA release successfully shifted the platform from a manual, high-error modeling environment to an automated, scalable foundation.
Quantifiable Impact
The following results were measured after the first quarter of GA, demonstrating the success of the “Pipeline Raadiness” strategy
-32%
Ingestion Failure
A significant reduction in downstream errors caused by “Confident Mistakes” at the schema level
+38%
Segmentation Confidence
Increased trust from Marketing Analysts in the data being used for high-stakes campaigns
+26%
More Predictable Modeling
Improved consistency in how schemas were extended and reused across different teams.
-20%
Operational Drag
Reduced the need for manual ETL and engineering intervention to “fix” corrupted profile fragments
Qualitative Wins
Beyond the numbers, the editor fundamentally changed how data moved through the Adobe Experience Platform
From Bottleneck to Enabler
Schema creation moved from a slow, code-heavy process to a drag-and-drop experience that accelerated time-to-segment.
Democratic Modeling
The “Mixin” architecture allowed teams to successfully extend schemas without relying on a central engineering team for every change.
Systemic Consistency
The editor enforced a “Global Blueprint” that standardized identity resolution and profile behavior across the entire ecosystem
Related Case Studies
AI-assisted Data Mapping
Data Collection Integration
Let’s Work Together
Interested in collaborating on complex UI/UX challenges involving data, AI, or enterprise systems?
I’d love to explore how thoughtful design can drive clarity and business impact.
Get In Touch
About Kelli
Product Designer | AI x Data Systems
Passionate about turning complex data and AI systems into clear, trustworthy, human-centered experiences
© 2025 Kelli Nordfelt,
Based in: San Francisco, CA
Overview
Problem
Technical Wall
Design Pivot
System Impact
Outcomes
Data Collections Integration
Lead Product Designer | Post → GA Launch
Designing a coherent data-collection ecosystem by unifying Tags, Datastreams, and Event Forwarding into workflows that improve onboarding, governance, and downstream clarity
View Quick Start Workflows
Project Snapshot
The Challenge
Bridging the “Integrity Gap” between user intent and system logic.
The Solution
Staged Validation & Progressive Disclosure.
Key Results
-32% Ingestion Failures | +38% Segmentation Confidence
Primary Users
Senior Data Architects (High-density modeling)
Overview
After I completed the GA of Launch Tag Management and improving rule-governance workflows, customer needs quickly expanded beyond client-side tagging. As Adobe Experience Platform (AEP) matured, organizations began ingesting more behavioral data from web, mobile, and server environments, but provisioning paths were spread across multiple tools.
I designed the early Sources and Destinations marketplace patterns, established service provisioning flows for Datastreams and Event Forwarding, and later unified these capabilities within the AEP Data Collection experience.
This work supported
- Behavioral and SDK data onboarding
- Datastream configuration
- Event Forwarding and Destinations provisioning
- Dependency transparency via System View
My Role
Primary designer responsible for workflows, IA alignment, provisioning patterns, and visualization of object relationships.
The Problem
Fragmented provisioning made data collection difficult to understand, govern, and activate
Key Problems
As AEP expanded beyond client-side tagging, new capabilities like Datastreaming and Event Forwarding introduced more flexible routing and transformation options. But customers did not yet understand how these new services fit into the overall data-collection ecosystem. There were no established provisioning patterns, no shared navigation model, and no clear way to visualize how data moved across services.
Teams struggled to:
- Understand when to use Tags vs Datastreaming vs Event Forwarding
- Configure new services without established IA or workflow patterns
- See how routing choices affected downstream destinations
- Diagnose misconfigurations without visibility into dependencies
Critical
No clear mental model for how new services connected
High
Provisioning steps were hard to understand
High
Routing was invisible, causing misconfigurations
Medium
Limited dependency visibility slowed troubleshooting
Cross-Team Workflow Analysis
No visibility into data quality for Marketing
1
Unified navigation across Launch and AEP for seamless context switching
2
Stepper workflows with clear stage indicators and role-based views
3
Real-time status dashboard showing data quality metrics across teams
Schema Editor
Tag Manager
Activation
Analytics
Segment Builder
Datastreams
Mapping Canvas
QA Pipeline
Error Monitor
Data Architect
Data Engineer
Senior Marketing Analyst
Provision & Collect
Schema setup → Data ingestion
Map & Transform
Data QA → Pipeline validation
Segment & Activate
Analytics → Campaign execution
Feedback Loop
Insights → Architecture updates
Data Platform
Ecosystem Core
QA handoff requires manual coordination
Unclear provisioning states between Architect and Engineer
The Technical Wall
Define a coherent provisioning and mental model for a next-generation data-collection ecosystem
I focused on establishing a unified data-collection workflow that improved clarity, onboarding, and downstream confidence.
Establish a cohesive platform entry point
Create clarity & consistency for users entering Data collection within AEP, positioning it as a fully integrated service rather than an external tool
Strengthen platform cohesion
Reinforce AEP’s role as the central platform by bringing Data Collection into its ecosystem by improving discoverability, governance, and long-term service alignment
Align user journeys across tiers
Ensure both free Launch users & paid AEP subscribers experience a coherent progression, enabling natural upgrade paths & reducing friction during migration
Build for scalability and future services
Lay a flexible architectural & design foundation that can adapt to new data services without major rework
Project Constraints
- Maintain Launch familiarity while easing users into the AEP shell
- design within iFrame limitations that restricted layout and interactions
- Create scalable patterns for mapping, ingestion, and navigation aligned with AEP standards
- Support client-side, server-side, and AEP provisioning without fragmenting navigation
Success Criteria
- Provide a unified left-rail with clear provisions states
- Maintain consistent mapping workflows across Data Collection and AEP
- Improve discoverability of new services through clearer hierarchy
- Increase adoption of Datastreams workflows based on pilot usage
The Design Pivot
A cross-functional effort involving data engineering, machine learning, and product teams that connected identity, enrichment, and downstream outcomes
Research & Discovery
- Mapped existing provisioning flows across Tags, Datastreams, Event Forwarding
- Interviewed customers, systems integrations, and internal teams
- Identified where misconfigurations occurred
Deliverables
Provisioning journey map
Service dependency diagrams
Persona navigation needs and provisioning states
Provisioning Journey Map
Service Provisioning (Free vs Paid / Client vs Server-side)
Server-side
AEP-enabled
Free Launch
Upgrade Path / Expansion
Server-side
AEP-enabled
Free Launch
Workflow Engagement
Server-side
AEP-enabled
Navigation & Discovery
AEP-enabled
Free Launch
Entry Point (Launch vs AEP)
AEP-enabled
Free Launch
Data Architect
Accesses via Adobe Experience Cloud home or AEP shell. Needs quick access to schema and identity tools.
Provisioned for both client and server-side tagging with AEP services enabled. Needs visibility into schema objects and governance tools.
Uses waffle switcher or left-rail to move between Schemas, Identities, and Data Collection. Looks for system-level orchestration.
Configures schemas, governs identity stitching, sets up data flows. Expects ERD-level visibility.
Adopts new AEP features early, helps define governance structure for future services.
Data Engineer
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
Senior Marketing Analyst
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
1
Introduce unified left-rail navigation
2
Provide role-based provisioning states
3
Maintain Launch familiarity while signaling AEP integration
4
Progressive disclosure of features based on provisioning
5
Clear provisioning states in UI
6
Onboarding content tailored to service level
7
Consistent navigation hierarchy across provisioning states
8
Scalable left-rail structure for new services
9
Preserve mental models from Launch
10
Stepper workflow integration for ingestion and mapping
11
Shared mapping canvas patterns across roles
12
Role-appropriate helper text and guidance
13
Clear upgrade pathways from Launch to AEP
14
Scaffolded onboarding for new service tiers
15
Telemetry-informed prompts for feature adoption
Design Opportunities
NEW Provisioning Workflow
Tracy has AEP Data Collections & Morgan has AEP RTCDP
NEW Provisioning Workflow
Tracy does NOT have AEP RTCDP
Adobe Experience Platform
Create Edge Dataflow
Create Schema
Create Property
Add Environments to Edge
Install AEP Web SDK
Publish AEP SDK
Implement Mappimg
Publish AEP SDK
Data Engineer
Design & Prototyping
I explored multiple navigation and workflow integration models. Focused on how to embed Data Collection within AEP’s shell while retaining Launch familiarity. Defined left-rail navigation patterns, waffle switcher flows, and progressive disclosure states that would scale with future services. These were designed to unify ingestion and mapping workflows with existing AEP data mapping patterns while preparing for upcoming features like serer-side tagging.
Deliverables
Navigation (Left-rail/switcher variants)
AI Workflow diagrams
Updated design system specs
Workflow recommendations and valid entry points
Updated Design System Specifications
Being informed of any larger system patterns will always help cross-teams understand best practices of how these patterns work
Left-rail Navigation Explorations
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Shell Navigation Switcher
3 Capabilities of Provisioning: Left-rail
1
User is provisioned for Tag Management ONLY
Introducing our users to new left rail UI design elements with a shift in category navigation, noun terminology changes, and added features with current landing pg onboarding experience, and “tool tip” design system patterns.
2
User is provisioned for Data Collection
Tag Management a& Datastreams & Event Forwarding
Once a user is provisioned for Event Forwarding Navigation expands to more features, Shell name changes, and onboarding educational content was added.
3
User is provisioned for Data Collection & AEP
This was defined as a long-term approach with more thought in regards to Palm sandbox transitioning for the new RealTime Customer Data Platform users and integration of property publishing experiences overall.
What is valuable:
Simplified Navigation levels with all nouns provisioned in left navigation.
Concerns to watch for:
Quick access navigation for this level of object/noun was ongoing as to what should be allowed/needed and what doesn’t make sense. Removing Launch quick access cards from AEC home page could be disorienting to current customers.
Adobe Experience League was also being revamped with new design systems and customer intent logic. So understanding long-term approach to educational content on AEC homepage and AEP homepage will always be ongoing research.
Development & Testing
- Validated correctness conditions for provisioning
- Partnered with engineering on routing and dependency logic
- User-tested onboarding flows with real datasets
Deliverables
Validation rules
Service consistency checks
AEP wiring for System View
Workflow Stage
Validation Focus
Test Type
Exptd Result
Actual Result
Data Ingestion
Stream payload automation
System
Data Ingests without delay or loss
All passed under Xs latency
Schema Mapping
Field auto-matching accuracy
Functional
≥90% correct auto-mapping
XX% average
Mapping/QA
Error surface clarity
UX
Error message visible, clear resolution path
Error visible; label improved post-feedback
Identity & Dataflow
Stream linking validation
Integration
All streams link to schema and identity graph
xyz# schema mismatch logged
Activation
End-to-end ingestion-to-activation
System
Data flows to activation w/ correct schema IDS
All succeeded
Workflow Navigation
Step clarity / task completion
Usability
100% completion within 3 mins
4/5 completed <3 mins
Automation Mapping
AI recommendation reliability
AI/Functional
≥80% correct mapping suggestions
84% accuracy
Status
Pass
Pass
Minor Fix
Fix Applied
Pass
Pass
Pass
QA Validation Matrix
Design Opportunities
70
2
3
Test Round
70%
85%
90%
95%
Mapping Accuracy
Mapping Method
Auto-Mapped
Manually Corrected
1
2
Test Round
0
2
4
6
FieldSelection
Mapping
Preview
Validation
12
8
45
5
42
22
32
28
18
18
15
38
8
12
35
Text Fields
Date Fields
Number Fields
Select Fields
Custom Fields
Low
High
Manual Corrections by Field Type & Step
System Impact
Demonstrated measurable gains in accuracy, efficiency, and clarity across workflows
- Greater clarity across cross-service dependencies
- Stronger governance conversations with customers
- More predictable downstream activation
- Easier collaboration across internal platform teams
-36%
Reduced Navigation Time
+40%
Feature Discoverability
+25%
Task Efficiency
-20%
Accelerated Onboarding
Adoption Flow Performance: Navigation Redesign
Before:
Limited discoverability and unclear provisioning led to significant drop-off across stages
40%
20%
30%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Clearer navigation and entry points drove higher discoverability, smoother configuration, and a +60% increase in overall adoption.
After:
65%
32%
50%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Outcomes
Stabilizing the Ecosystem
By focusing on the Data Architect’s need for structural precision over feature breadth, the Schema Editor GA release successfully shifted the platform from a manual, high-error modeling environment to an automated, scalable foundation.
Quantifiable Impact
The following results were measured after the first quarter of GA, demonstrating the success of the “Pipeline Raadiness” strategy
-32%
Ingestion Failure
A significant reduction in downstream errors caused by “Confident Mistakes” at the schema level
+38%
Segmentation Confidence
Increased trust from Marketing Analysts in the data being used for high-stakes campaigns
+26%
More Predictable Modeling
Improved consistency in how schemas were extended and reused across different teams.
-20%
Operational Drag
Reduced the need for manual ETL and engineering intervention to “fix” corrupted profile fragments
Qualitative Wins
Beyond the numbers, the editor fundamentally changed how data moved through the Adobe Experience Platform
From Bottleneck to Enabler
Schema creation moved from a slow, code-heavy process to a drag-and-drop experience that accelerated time-to-segment.
Democratic Modeling
The “Mixin” architecture allowed teams to successfully extend schemas without relying on a central engineering team for every change.
Systemic Consistency
The editor enforced a “Global Blueprint” that standardized identity resolution and profile behavior across the entire ecosystem
Related Case Studies
AI-assisted Data Mapping
Data Collection Integration
Let’s Work Together
Interested in collaborating on complex UI/UX challenges involving data, AI, or enterprise systems?
I’d love to explore how thoughtful design can drive clarity and business impact.
Get In Touch
About Kelli
Product Designer | AI x Data Systems
Passionate about turning complex data and AI systems into clear, trustworthy, human-centered experiences
© 2025 Kelli Nordfelt,
Based in: San Francisco, CA
Overview
Problem
Technical Wall
Design Pivot
System Impact
Outcomes
Data Collections Integration
Lead Product Designer | Post → GA Launch
Designing a coherent data-collection ecosystem by unifying Tags, Datastreams, and Event Forwarding into workflows that improve onboarding, governance, and downstream clarity
View Quick Start Workflows
Project Snapshot
The Challenge
Bridging the “Integrity Gap” between user intent and system logic.
The Solution
Staged Validation & Progressive Disclosure.
Key Results
-32% Ingestion Failures | +38% Segmentation Confidence
Primary Users
Senior Data Architects (High-density modeling)
Overview
After I completed the GA of Launch Tag Management and improving rule-governance workflows, customer needs quickly expanded beyond client-side tagging. As Adobe Experience Platform (AEP) matured, organizations began ingesting more behavioral data from web, mobile, and server environments, but provisioning paths were spread across multiple tools.
I designed the early Sources and Destinations marketplace patterns, established service provisioning flows for Datastreams and Event Forwarding, and later unified these capabilities within the AEP Data Collection experience.
This work supported
- Behavioral and SDK data onboarding
- Datastream configuration
- Event Forwarding and Destinations provisioning
- Dependency transparency via System View
My Role
Primary designer responsible for workflows, IA alignment, provisioning patterns, and visualization of object relationships.
The Problem
Fragmented provisioning made data collection difficult to understand, govern, and activate
Key Problems
As AEP expanded beyond client-side tagging, new capabilities like Datastreaming and Event Forwarding introduced more flexible routing and transformation options. But customers did not yet understand how these new services fit into the overall data-collection ecosystem. There were no established provisioning patterns, no shared navigation model, and no clear way to visualize how data moved across services.
Teams struggled to:
- Understand when to use Tags vs Datastreaming vs Event Forwarding
- Configure new services without established IA or workflow patterns
- See how routing choices affected downstream destinations
- Diagnose misconfigurations without visibility into dependencies
Critical
No clear mental model for how new services connected
High
Provisioning steps were hard to understand
High
Routing was invisible, causing misconfigurations
Medium
Limited dependency visibility slowed troubleshooting
Cross-Team Workflow Analysis
No visibility into data quality for Marketing
1
Unified navigation across Launch and AEP for seamless context switching
2
Stepper workflows with clear stage indicators and role-based views
3
Real-time status dashboard showing data quality metrics across teams
Schema Editor
Tag Manager
Activation
Analytics
Segment Builder
Datastreams
Mapping Canvas
QA Pipeline
Error Monitor
Data Architect
Data Engineer
Senior Marketing Analyst
Provision & Collect
Schema setup → Data ingestion
Map & Transform
Data QA → Pipeline validation
Segment & Activate
Analytics → Campaign execution
Feedback Loop
Insights → Architecture updates
Data Platform
Ecosystem Core
QA handoff requires manual coordination
Unclear provisioning states between Architect and Engineer
The Technical Wall
Define a coherent provisioning and mental model for a next-generation data-collection ecosystem
I focused on establishing a unified data-collection workflow that improved clarity, onboarding, and downstream confidence.
Establish a cohesive platform entry point
Create clarity & consistency for users entering Data collection within AEP, positioning it as a fully integrated service rather than an external tool
Strengthen platform cohesion
Reinforce AEP’s role as the central platform by bringing Data Collection into its ecosystem by improving discoverability, governance, and long-term service alignment
Align user journeys across tiers
Ensure both free Launch users & paid AEP subscribers experience a coherent progression, enabling natural upgrade paths & reducing friction during migration
Build for scalability and future services
Lay a flexible architectural & design foundation that can adapt to new data services without major rework
Project Constraints
- Maintain Launch familiarity while easing users into the AEP shell
- design within iFrame limitations that restricted layout and interactions
- Create scalable patterns for mapping, ingestion, and navigation aligned with AEP standards
- Support client-side, server-side, and AEP provisioning without fragmenting navigation
Success Criteria
- Provide a unified left-rail with clear provisions states
- Maintain consistent mapping workflows across Data Collection and AEP
- Improve discoverability of new services through clearer hierarchy
- Increase adoption of Datastreams workflows based on pilot usage
The Design Pivot
A cross-functional effort involving data engineering, machine learning, and product teams that connected identity, enrichment, and downstream outcomes
Research & Discovery
- Mapped existing provisioning flows across Tags, Datastreams, Event Forwarding
- Interviewed customers, systems integrations, and internal teams
- Identified where misconfigurations occurred
Deliverables
Provisioning journey map
Service dependency diagrams
Persona navigation needs and provisioning states
Provisioning Journey Map
Service Provisioning (Free vs Paid / Client vs Server-side)
Server-side
AEP-enabled
Free Launch
Upgrade Path / Expansion
Server-side
AEP-enabled
Free Launch
Workflow Engagement
Server-side
AEP-enabled
Navigation & Discovery
AEP-enabled
Free Launch
Entry Point (Launch vs AEP)
AEP-enabled
Free Launch
Data Architect
Accesses via Adobe Experience Cloud home or AEP shell. Needs quick access to schema and identity tools.
Provisioned for both client and server-side tagging with AEP services enabled. Needs visibility into schema objects and governance tools.
Uses waffle switcher or left-rail to move between Schemas, Identities, and Data Collection. Looks for system-level orchestration.
Configures schemas, governs identity stitching, sets up data flows. Expects ERD-level visibility.
Adopts new AEP features early, helps define governance structure for future services.
Data Engineer
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
Senior Marketing Analyst
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
1
Introduce unified left-rail navigation
2
Provide role-based provisioning states
3
Maintain Launch familiarity while signaling AEP integration
4
Progressive disclosure of features based on provisioning
5
Clear provisioning states in UI
6
Onboarding content tailored to service level
7
Consistent navigation hierarchy across provisioning states
8
Scalable left-rail structure for new services
9
Preserve mental models from Launch
10
Stepper workflow integration for ingestion and mapping
11
Shared mapping canvas patterns across roles
12
Role-appropriate helper text and guidance
13
Clear upgrade pathways from Launch to AEP
14
Scaffolded onboarding for new service tiers
15
Telemetry-informed prompts for feature adoption
Design Opportunities
NEW Provisioning Workflow
Tracy has AEP Data Collections & Morgan has AEP RTCDP
NEW Provisioning Workflow
Tracy does NOT have AEP RTCDP
Adobe Experience Platform
Create Edge Dataflow
Create Schema
Create Property
Add Environments to Edge
Install AEP Web SDK
Publish AEP SDK
Implement Mappimg
Publish AEP SDK
Data Engineer
Design & Prototyping
I explored multiple navigation and workflow integration models. Focused on how to embed Data Collection within AEP’s shell while retaining Launch familiarity. Defined left-rail navigation patterns, waffle switcher flows, and progressive disclosure states that would scale with future services. These were designed to unify ingestion and mapping workflows with existing AEP data mapping patterns while preparing for upcoming features like serer-side tagging.
Deliverables
Navigation (Left-rail/switcher variants)
AI Workflow diagrams
Updated design system specs
Workflow recommendations and valid entry points
Updated Design System Specifications
Being informed of any larger system patterns will always help cross-teams understand best practices of how these patterns work
Left-rail Navigation Explorations
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Shell Navigation Switcher
3 Capabilities of Provisioning: Left-rail
1
User is provisioned for Tag Management ONLY
Introducing our users to new left rail UI design elements with a shift in category navigation, noun terminology changes, and added features with current landing pg onboarding experience, and “tool tip” design system patterns.
2
User is provisioned for Data Collection
Tag Management a& Datastreams & Event Forwarding
Once a user is provisioned for Event Forwarding Navigation expands to more features, Shell name changes, and onboarding educational content was added.
3
User is provisioned for Data Collection & AEP
This was defined as a long-term approach with more thought in regards to Palm sandbox transitioning for the new RealTime Customer Data Platform users and integration of property publishing experiences overall.
What is valuable:
Simplified Navigation levels with all nouns provisioned in left navigation.
Concerns to watch for:
Quick access navigation for this level of object/noun was ongoing as to what should be allowed/needed and what doesn’t make sense. Removing Launch quick access cards from AEC home page could be disorienting to current customers.
Adobe Experience League was also being revamped with new design systems and customer intent logic. So understanding long-term approach to educational content on AEC homepage and AEP homepage will always be ongoing research.
Development & Testing
- Validated correctness conditions for provisioning
- Partnered with engineering on routing and dependency logic
- User-tested onboarding flows with real datasets
Deliverables
Validation rules
Service consistency checks
AEP wiring for System View
Workflow Stage
Validation Focus
Test Type
Exptd Result
Actual Result
Data Ingestion
Stream payload automation
System
Data Ingests without delay or loss
All passed under Xs latency
Schema Mapping
Field auto-matching accuracy
Functional
≥90% correct auto-mapping
XX% average
Mapping/QA
Error surface clarity
UX
Error message visible, clear resolution path
Error visible; label improved post-feedback
Identity & Dataflow
Stream linking validation
Integration
All streams link to schema and identity graph
xyz# schema mismatch logged
Activation
End-to-end ingestion-to-activation
System
Data flows to activation w/ correct schema IDS
All succeeded
Workflow Navigation
Step clarity / task completion
Usability
100% completion within 3 mins
4/5 completed <3 mins
Automation Mapping
AI recommendation reliability
AI/Functional
≥80% correct mapping suggestions
84% accuracy
Status
Pass
Pass
Minor Fix
Fix Applied
Pass
Pass
Pass
QA Validation Matrix
Design Opportunities
70
2
3
Test Round
70%
85%
90%
95%
Mapping Accuracy
Mapping Method
Auto-Mapped
Manually Corrected
1
2
Test Round
0
2
4
6
FieldSelection
Mapping
Preview
Validation
12
8
45
5
42
22
32
28
18
18
15
38
8
12
35
Text Fields
Date Fields
Number Fields
Select Fields
Custom Fields
Low
High
Manual Corrections by Field Type & Step
System Impact
Demonstrated measurable gains in accuracy, efficiency, and clarity across workflows
- Greater clarity across cross-service dependencies
- Stronger governance conversations with customers
- More predictable downstream activation
- Easier collaboration across internal platform teams
-36%
Reduced Navigation Time
+40%
Feature Discoverability
+25%
Task Efficiency
-20%
Accelerated Onboarding
Adoption Flow Performance: Navigation Redesign
Before:
Limited discoverability and unclear provisioning led to significant drop-off across stages
40%
20%
30%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Clearer navigation and entry points drove higher discoverability, smoother configuration, and a +60% increase in overall adoption.
After:
65%
32%
50%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Outcomes
Stabilizing the Ecosystem
By focusing on the Data Architect’s need for structural precision over feature breadth, the Schema Editor GA release successfully shifted the platform from a manual, high-error modeling environment to an automated, scalable foundation.
Quantifiable Impact
The following results were measured after the first quarter of GA, demonstrating the success of the “Pipeline Raadiness” strategy
-32%
Ingestion Failure
A significant reduction in downstream errors caused by “Confident Mistakes” at the schema level
+38%
Segmentation Confidence
Increased trust from Marketing Analysts in the data being used for high-stakes campaigns
+26%
More Predictable Modeling
Improved consistency in how schemas were extended and reused across different teams.
-20%
Operational Drag
Reduced the need for manual ETL and engineering intervention to “fix” corrupted profile fragments
Qualitative Wins
Beyond the numbers, the editor fundamentally changed how data moved through the Adobe Experience Platform
From Bottleneck to Enabler
Schema creation moved from a slow, code-heavy process to a drag-and-drop experience that accelerated time-to-segment.
Democratic Modeling
The “Mixin” architecture allowed teams to successfully extend schemas without relying on a central engineering team for every change.
Systemic Consistency
The editor enforced a “Global Blueprint” that standardized identity resolution and profile behavior across the entire ecosystem
Related Case Studies
AI-assisted Data Mapping
Data Collection Integration
Let’s Work Together
Interested in collaborating on complex UI/UX challenges involving data, AI, or enterprise systems?
I’d love to explore how thoughtful design can drive clarity and business impact.
Get In Touch
About Kelli
Product Designer | AI x Data Systems
Passionate about turning complex data and AI systems into clear, trustworthy, human-centered experiences
© 2025 Kelli Nordfelt,
Based in: San Francisco, CA
Overview
Problem
Technical Wall
Design Pivot
System Impact
Outcomes
Data Collections Integration
Lead Product Designer | Post → GA Launch
Designing a coherent data-collection ecosystem by unifying Tags, Datastreams, and Event Forwarding into workflows that improve onboarding, governance, and downstream clarity
View Quick Start Workflows
Project Snapshot
The Challenge
Bridging the “Integrity Gap” between user intent and system logic.
The Solution
Staged Validation & Progressive Disclosure.
Key Results
-32% Ingestion Failures | +38% Segmentation Confidence
Primary Users
Senior Data Architects (High-density modeling)
Overview
After I completed the GA of Launch Tag Management and improving rule-governance workflows, customer needs quickly expanded beyond client-side tagging. As Adobe Experience Platform (AEP) matured, organizations began ingesting more behavioral data from web, mobile, and server environments, but provisioning paths were spread across multiple tools.
I designed the early Sources and Destinations marketplace patterns, established service provisioning flows for Datastreams and Event Forwarding, and later unified these capabilities within the AEP Data Collection experience.
This work supported
- Behavioral and SDK data onboarding
- Datastream configuration
- Event Forwarding and Destinations provisioning
- Dependency transparency via System View
My Role
Primary designer responsible for workflows, IA alignment, provisioning patterns, and visualization of object relationships.
The Problem
Fragmented provisioning made data collection difficult to understand, govern, and activate
Key Problems
As AEP expanded beyond client-side tagging, new capabilities like Datastreaming and Event Forwarding introduced more flexible routing and transformation options. But customers did not yet understand how these new services fit into the overall data-collection ecosystem. There were no established provisioning patterns, no shared navigation model, and no clear way to visualize how data moved across services.
Teams struggled to:
- Understand when to use Tags vs Datastreaming vs Event Forwarding
- Configure new services without established IA or workflow patterns
- See how routing choices affected downstream destinations
- Diagnose misconfigurations without visibility into dependencies
Critical
No clear mental model for how new services connected
High
Provisioning steps were hard to understand
High
Routing was invisible, causing misconfigurations
Medium
Limited dependency visibility slowed troubleshooting
Cross-Team Workflow Analysis
No visibility into data quality for Marketing
1
Unified navigation across Launch and AEP for seamless context switching
2
Stepper workflows with clear stage indicators and role-based views
3
Real-time status dashboard showing data quality metrics across teams
Schema Editor
Tag Manager
Activation
Analytics
Segment Builder
Datastreams
Mapping Canvas
QA Pipeline
Error Monitor
Data Architect
Data Engineer
Senior Marketing Analyst
Provision & Collect
Schema setup → Data ingestion
Map & Transform
Data QA → Pipeline validation
Segment & Activate
Analytics → Campaign execution
Feedback Loop
Insights → Architecture updates
Data Platform
Ecosystem Core
QA handoff requires manual coordination
Unclear provisioning states between Architect and Engineer
The Technical Wall
Define a coherent provisioning and mental model for a next-generation data-collection ecosystem
I focused on establishing a unified data-collection workflow that improved clarity, onboarding, and downstream confidence.
Establish a cohesive platform entry point
Create clarity & consistency for users entering Data collection within AEP, positioning it as a fully integrated service rather than an external tool
Strengthen platform cohesion
Reinforce AEP’s role as the central platform by bringing Data Collection into its ecosystem by improving discoverability, governance, and long-term service alignment
Align user journeys across tiers
Ensure both free Launch users & paid AEP subscribers experience a coherent progression, enabling natural upgrade paths & reducing friction during migration
Build for scalability and future services
Lay a flexible architectural & design foundation that can adapt to new data services without major rework
Project Constraints
- Maintain Launch familiarity while easing users into the AEP shell
- design within iFrame limitations that restricted layout and interactions
- Create scalable patterns for mapping, ingestion, and navigation aligned with AEP standards
- Support client-side, server-side, and AEP provisioning without fragmenting navigation
Success Criteria
- Provide a unified left-rail with clear provisions states
- Maintain consistent mapping workflows across Data Collection and AEP
- Improve discoverability of new services through clearer hierarchy
- Increase adoption of Datastreams workflows based on pilot usage
The Design Pivot
A cross-functional effort involving data engineering, machine learning, and product teams that connected identity, enrichment, and downstream outcomes
Research & Discovery
- Mapped existing provisioning flows across Tags, Datastreams, Event Forwarding
- Interviewed customers, systems integrations, and internal teams
- Identified where misconfigurations occurred
Deliverables
Provisioning journey map
Service dependency diagrams
Persona navigation needs and provisioning states
Provisioning Journey Map
Service Provisioning (Free vs Paid / Client vs Server-side)
Server-side
AEP-enabled
Free Launch
Upgrade Path / Expansion
Server-side
AEP-enabled
Free Launch
Workflow Engagement
Server-side
AEP-enabled
Navigation & Discovery
AEP-enabled
Free Launch
Entry Point (Launch vs AEP)
AEP-enabled
Free Launch
Data Architect
Accesses via Adobe Experience Cloud home or AEP shell. Needs quick access to schema and identity tools.
Provisioned for both client and server-side tagging with AEP services enabled. Needs visibility into schema objects and governance tools.
Uses waffle switcher or left-rail to move between Schemas, Identities, and Data Collection. Looks for system-level orchestration.
Configures schemas, governs identity stitching, sets up data flows. Expects ERD-level visibility.
Adopts new AEP features early, helps define governance structure for future services.
Data Engineer
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
Senior Marketing Analyst
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
1
Introduce unified left-rail navigation
2
Provide role-based provisioning states
3
Maintain Launch familiarity while signaling AEP integration
4
Progressive disclosure of features based on provisioning
5
Clear provisioning states in UI
6
Onboarding content tailored to service level
7
Consistent navigation hierarchy across provisioning states
8
Scalable left-rail structure for new services
9
Preserve mental models from Launch
10
Stepper workflow integration for ingestion and mapping
11
Shared mapping canvas patterns across roles
12
Role-appropriate helper text and guidance
13
Clear upgrade pathways from Launch to AEP
14
Scaffolded onboarding for new service tiers
15
Telemetry-informed prompts for feature adoption
Design Opportunities
NEW Provisioning Workflow
Tracy has AEP Data Collections & Morgan has AEP RTCDP
NEW Provisioning Workflow
Tracy does NOT have AEP RTCDP
Adobe Experience Platform
Create Edge Dataflow
Create Schema
Create Property
Add Environments to Edge
Install AEP Web SDK
Publish AEP SDK
Implement Mappimg
Publish AEP SDK
Data Engineer
Design & Prototyping
I explored multiple navigation and workflow integration models. Focused on how to embed Data Collection within AEP’s shell while retaining Launch familiarity. Defined left-rail navigation patterns, waffle switcher flows, and progressive disclosure states that would scale with future services. These were designed to unify ingestion and mapping workflows with existing AEP data mapping patterns while preparing for upcoming features like serer-side tagging.
Deliverables
Navigation (Left-rail/switcher variants)
AI Workflow diagrams
Updated design system specs
Workflow recommendations and valid entry points
Updated Design System Specifications
Being informed of any larger system patterns will always help cross-teams understand best practices of how these patterns work
Left-rail Navigation Explorations
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Shell Navigation Switcher
3 Capabilities of Provisioning: Left-rail
1
User is provisioned for Tag Management ONLY
Introducing our users to new left rail UI design elements with a shift in category navigation, noun terminology changes, and added features with current landing pg onboarding experience, and “tool tip” design system patterns.
2
User is provisioned for Data Collection
Tag Management a& Datastreams & Event Forwarding
Once a user is provisioned for Event Forwarding Navigation expands to more features, Shell name changes, and onboarding educational content was added.
3
User is provisioned for Data Collection & AEP
This was defined as a long-term approach with more thought in regards to Palm sandbox transitioning for the new RealTime Customer Data Platform users and integration of property publishing experiences overall.
What is valuable:
Simplified Navigation levels with all nouns provisioned in left navigation.
Concerns to watch for:
Quick access navigation for this level of object/noun was ongoing as to what should be allowed/needed and what doesn’t make sense. Removing Launch quick access cards from AEC home page could be disorienting to current customers.
Adobe Experience League was also being revamped with new design systems and customer intent logic. So understanding long-term approach to educational content on AEC homepage and AEP homepage will always be ongoing research.
Development & Testing
- Validated correctness conditions for provisioning
- Partnered with engineering on routing and dependency logic
- User-tested onboarding flows with real datasets
Deliverables
Validation rules
Service consistency checks
AEP wiring for System View
Workflow Stage
Validation Focus
Test Type
Exptd Result
Actual Result
Data Ingestion
Stream payload automation
System
Data Ingests without delay or loss
All passed under Xs latency
Schema Mapping
Field auto-matching accuracy
Functional
≥90% correct auto-mapping
XX% average
Mapping/QA
Error surface clarity
UX
Error message visible, clear resolution path
Error visible; label improved post-feedback
Identity & Dataflow
Stream linking validation
Integration
All streams link to schema and identity graph
xyz# schema mismatch logged
Activation
End-to-end ingestion-to-activation
System
Data flows to activation w/ correct schema IDS
All succeeded
Workflow Navigation
Step clarity / task completion
Usability
100% completion within 3 mins
4/5 completed <3 mins
Automation Mapping
AI recommendation reliability
AI/Functional
≥80% correct mapping suggestions
84% accuracy
Status
Pass
Pass
Minor Fix
Fix Applied
Pass
Pass
Pass
QA Validation Matrix
Design Opportunities
70
2
3
Test Round
70%
85%
90%
95%
Mapping Accuracy
Mapping Method
Auto-Mapped
Manually Corrected
1
2
Test Round
0
2
4
6
FieldSelection
Mapping
Preview
Validation
12
8
45
5
42
22
32
28
18
18
15
38
8
12
35
Text Fields
Date Fields
Number Fields
Select Fields
Custom Fields
Low
High
Manual Corrections by Field Type & Step
System Impact
Demonstrated measurable gains in accuracy, efficiency, and clarity across workflows
- Greater clarity across cross-service dependencies
- Stronger governance conversations with customers
- More predictable downstream activation
- Easier collaboration across internal platform teams
-36%
Reduced Navigation Time
+40%
Feature Discoverability
+25%
Task Efficiency
-20%
Accelerated Onboarding
Adoption Flow Performance: Navigation Redesign
Before:
Limited discoverability and unclear provisioning led to significant drop-off across stages
40%
20%
30%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Clearer navigation and entry points drove higher discoverability, smoother configuration, and a +60% increase in overall adoption.
After:
65%
32%
50%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a dDatastreams
Users who started setting up & activated
Outcomes
Stabilizing the Ecosystem
By focusing on the Data Architect’s need for structural precision over feature breadth, the Schema Editor GA release successfully shifted the platform from a manual, high-error modeling environment to an automated, scalable foundation.
Quantifiable Impact
The following results were measured after the first quarter of GA, demonstrating the success of the “Pipeline Raadiness” strategy
-32%
Ingestion Failure
A significant reduction in downstream errors caused by “Confident Mistakes” at the schema level
+38%
Segmentation Confidence
Increased trust from Marketing Analysts in the data being used for high-stakes campaigns
+26%
More Predictable Modeling
Improved consistency in how schemas were extended and reused across different teams.
-20%
Operational Drag
Reduced the need for manual ETL and engineering intervention to “fix” corrupted profile fragments
Qualitative Wins
Beyond the numbers, the editor fundamentally changed how data moved through the Adobe Experience Platform
From Bottleneck to Enabler
Schema creation moved from a slow, code-heavy process to a drag-and-drop experience that accelerated time-to-segment.
Democratic Modeling
The “Mixin” architecture allowed teams to successfully extend schemas without relying on a central engineering team for every change.
Systemic Consistency
The editor enforced a “Global Blueprint” that standardized identity resolution and profile behavior across the entire ecosystem
Related Case Studies
AI-assisted Data Mapping
Data Collection Integration
Let’s Work Together
Interested in collaborating on complex UI/UX challenges involving data, AI, or enterprise systems?
I’d love to explore how thoughtful design can drive clarity and business impact.
Get In Touch
About Kelli
Product Designer | AI x Data Systems
Passionate about turning complex data and AI systems into clear, trustworthy, human-centered experiences
© 2025 Kelli Nordfelt,
Based in: San Francisco, CA
Overview
Problem
Technical Wall
Design Pivot
System Impact
Outcomes
Data Collections Integration
Lead Product Designer | Post → GA Launch
Designing a coherent data-collection ecosystem by unifying Tags, Datastreams, and Event Forwarding into workflows that improve onboarding, governance, and downstream clarity
View Quick Start Workflows
Project Snapshot
The Challenge
Bridging the “Integrity Gap” between user intent and system logic.
The Solution
Staged Validation & Progressive Disclosure.
Key Results
-32% Ingestion Failures | +38% Segmentation Confidence
Primary Users
Senior Data Architects (High-density modeling)
Overview
After I completed the GA of Launch Tag Management and improving rule-governance workflows, customer needs quickly expanded beyond client-side tagging. As Adobe Experience Platform (AEP) matured, organizations began ingesting more behavioral data from web, mobile, and server environments, but provisioning paths were spread across multiple tools.
I designed the early Sources and Destinations marketplace patterns, established service provisioning flows for Datastreams and Event Forwarding, and later unified these capabilities within the AEP Data Collection experience.
This work supported
- Behavioral and SDK data onboarding
- Datastream configuration
- Event Forwarding and Destinations provisioning
- Dependency transparency via System View
My Role
Primary designer responsible for workflows, IA alignment, provisioning patterns, and visualization of object relationships.
The Problem
Fragmented provisioning made data collection difficult to understand, govern, and activate
Key Problems
As AEP expanded beyond client-side tagging, new capabilities like Datastreaming and Event Forwarding introduced more flexible routing and transformation options. But customers did not yet understand how these new services fit into the overall data-collection ecosystem. There were no established provisioning patterns, no shared navigation model, and no clear way to visualize how data moved across services.
Teams struggled to:
- Understand when to use Tags vs Datastreaming vs Event Forwarding
- Configure new services without established IA or workflow patterns
- See how routing choices affected downstream destinations
- Diagnose misconfigurations without visibility into dependencies
Critical
No clear mental model for how new services connected
High
Provisioning steps were hard to understand
High
Routing was invisible, causing misconfigurations
Medium
Limited dependency visibility slowed troubleshooting
Cross-Team Workflow Analysis
No visibility into data quality for Marketing
1
Unified navigation across Launch and AEP for seamless context switching
2
Stepper workflows with clear stage indicators and role-based views
3
Real-time status dashboard showing data quality metrics across teams
Schema Editor
Tag Manager
Activation
Analytics
Segment Builder
Datastreams
Mapping Canvas
QA Pipeline
Error Monitor
Data Architect
Data Engineer
Senior Marketing Analyst
Provision & Collect
Schema setup → Data ingestion
Map & Transform
Data QA → Pipeline validation
Segment & Activate
Analytics → Campaign execution
Feedback Loop
Insights → Architecture updates
Data Platform
Ecosystem Core
QA handoff requires manual coordination
Unclear provisioning states between Architect and Engineer
The Technical Wall
Define a coherent provisioning and mental model for a next-generation data-collection ecosystem
I focused on establishing a unified data-collection workflow that improved clarity, onboarding, and downstream confidence.
Establish a cohesive platform entry point
Create clarity & consistency for users entering Data collection within AEP, positioning it as a fully integrated service rather than an external tool
Strengthen platform cohesion
Reinforce AEP’s role as the central platform by bringing Data Collection into its ecosystem by improving discoverability, governance, and long-term service alignment
Align user journeys across tiers
Ensure both free Launch users & paid AEP subscribers experience a coherent progression, enabling natural upgrade paths & reducing friction during migration
Build for scalability and future services
Lay a flexible architectural & design foundation that can adapt to new data services without major rework
Project Constraints
- Maintain Launch familiarity while easing users into the AEP shell
- design within iFrame limitations that restricted layout and interactions
- Create scalable patterns for mapping, ingestion, and navigation aligned with AEP standards
- Support client-side, server-side, and AEP provisioning without fragmenting navigation
Success Criteria
- Provide a unified left-rail with clear provisions states
- Maintain consistent mapping workflows across Data Collection and AEP
- Improve discoverability of new services through clearer hierarchy
- Increase adoption of Datastreams workflows based on pilot usage
The Design Pivot
A cross-functional effort involving data engineering, machine learning, and product teams that connected identity, enrichment, and downstream outcomes
Research & Discovery
- Mapped existing provisioning flows across Tags, Datastreams, Event Forwarding
- Interviewed customers, systems integrations, and internal teams
- Identified where misconfigurations occurred
Deliverables
Provisioning journey map
Service dependency diagrams
Persona navigation needs and provisioning states
Provisioning Journey Map
Service Provisioning (Free vs Paid / Client vs Server-side)
Server-side
AEP-enabled
Free Launch
Upgrade Path / Expansion
Server-side
AEP-enabled
Free Launch
Workflow Engagement
Server-side
AEP-enabled
Navigation & Discovery
AEP-enabled
Free Launch
Entry Point (Launch vs AEP)
AEP-enabled
Free Launch
Data Architect
Accesses via Adobe Experience Cloud home or AEP shell. Needs quick access to schema and identity tools.
Provisioned for both client and server-side tagging with AEP services enabled. Needs visibility into schema objects and governance tools.
Uses waffle switcher or left-rail to move between Schemas, Identities, and Data Collection. Looks for system-level orchestration.
Configures schemas, governs identity stitching, sets up data flows. Expects ERD-level visibility.
Adopts new AEP features early, helps define governance structure for future services.
Data Engineer
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
Senior Marketing Analyst
Typically enters through AEP shell, expects system-wide view of data flows.
Provisioned for server-side and advanced mapping workflows. Needs deep visibility into data pipelines.
Navigates via AEP left-rail to Datastreams, Sources, and Datasets. Needs quick access to mapping and QA tools.
Sets up and validates mappings, configures datastreams, monitors data movement through pipelines.
Expands to server-side tagging and new data services. Needs to trust schema mapping automation.
1
Introduce unified left-rail navigation
2
Provide role-based provisioning states
3
Maintain Launch familiarity while signaling AEP integration
4
Progressive disclosure of features based on provisioning
5
Clear provisioning states in UI
6
Onboarding content tailored to service level
7
Consistent navigation hierarchy across provisioning states
8
Scalable left-rail structure for new services
9
Preserve mental models from Launch
10
Stepper workflow integration for ingestion and mapping
11
Shared mapping canvas patterns across roles
12
Role-appropriate helper text and guidance
13
Clear upgrade pathways from Launch to AEP
14
Scaffolded onboarding for new service tiers
15
Telemetry-informed prompts for feature adoption
Design Opportunities
NEW Provisioning Workflow
Tracy has AEP Data Collections & Morgan has AEP RTCDP
NEW Provisioning Workflow
Tracy does NOT have AEP RTCDP
Adobe Experience Platform
Create Edge Dataflow
Create Schema
Create Property
Add Environments to Edge
Install AEP Web SDK
Publish AEP SDK
Implement Mappimg
Publish AEP SDK
Data Engineer
Design & Prototyping
I explored multiple navigation and workflow integration models. Focused on how to embed Data Collection within AEP’s shell while retaining Launch familiarity. Defined left-rail navigation patterns, waffle switcher flows, and progressive disclosure states that would scale with future services. These were designed to unify ingestion and mapping workflows with existing AEP data mapping patterns while preparing for upcoming features like serer-side tagging.
Deliverables
Navigation (Left-rail/switcher variants)
AI Workflow diagrams
Updated design system specs
Workflow recommendations and valid entry points
Updated Design System Specifications
Being informed of any larger system patterns will always help cross-teams understand best practices of how these patterns work
Left-rail Navigation Explorations
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Option 1
Keep Launch terminology and main navigation in AEC, and add 2 levels of left navigation with a dropdown to toggle services. This would allow second level left navigation to remain as is for Tag management objects. This was discussed as a short-term fix, but communicated the dropdown is not ideal for scalability of Data Collection’s future portfolio of services.
Shell Navigation Switcher
3 Capabilities of Provisioning: Left-rail
1
User is provisioned for Tag Management ONLY
Introducing our users to new left rail UI design elements with a shift in category navigation, noun terminology changes, and added features with current landing pg onboarding experience, and “tool tip” design system patterns.
2
User is provisioned for Data Collection
Tag Management a& Datastreams & Event Forwarding
Once a user is provisioned for Event Forwarding Navigation expands to more features, Shell name changes, and onboarding educational content was added.
3
User is provisioned for Data Collection & AEP
This was defined as a long-term approach with more thought in regards to Palm sandbox transitioning for the new RealTime Customer Data Platform users and integration of property publishing experiences overall.
What is valuable:
Simplified Navigation levels with all nouns provisioned in left navigation.
Concerns to watch for:
Quick access navigation for this level of object/noun was ongoing as to what should be allowed/needed and what doesn’t make sense. Removing Launch quick access cards from AEC home page could be disorienting to current customers.
Adobe Experience League was also being revamped with new design systems and customer intent logic. So understanding long-term approach to educational content on AEC homepage and AEP homepage will always be ongoing research.
Development & Testing
- Validated correctness conditions for provisioning
- Partnered with engineering on routing and dependency logic
- User-tested onboarding flows with real datasets
Deliverables
Validation rules
Service consistency checks
AEP wiring for System View
Workflow Stage
Validation Focus
Test Type
Exptd Result
Actual Result
Data Ingestion
Stream payload automation
System
Data Ingests without delay or loss
All passed under Xs latency
Schema Mapping
Field auto-matching accuracy
Functional
≥90% correct auto-mapping
XX% average
Mapping/QA
Error surface clarity
UX
Error message visible, clear resolution path
Error visible; label improved post-feedback
Identity & Dataflow
Stream linking validation
Integration
All streams link to schema and identity graph
xyz# schema mismatch logged
Activation
End-to-end ingestion-to-activation
System
Data flows to activation w/ correct schema IDS
All succeeded
Workflow Navigation
Step clarity / task completion
Usability
100% completion within 3 mins
4/5 completed <3 mins
Automation Mapping
AI recommendation reliability
AI/Functional
≥80% correct mapping suggestions
84% accuracy
Status
Pass
Pass
Minor Fix
Fix Applied
Pass
Pass
Pass
QA Validation Matrix
Design Opportunities
70
2
3
Test Round
70%
85%
90%
95%
Mapping Accuracy
Mapping Method
Auto-Mapped
Manually Corrected
1
2
Test Round
0
2
4
6
FieldSelection
Mapping
Preview
Validation
12
8
45
5
42
22
32
28
18
18
15
38
8
12
35
Text Fields
Date Fields
Number Fields
Select Fields
Custom Fields
Low
High
Manual Corrections by Field Type & Step
System Impact
Demonstrated measurable gains in accuracy, efficiency, and clarity across workflows
- Greater clarity across cross-service dependencies
- Stronger governance conversations with customers
- More predictable downstream activation
- Easier collaboration across internal platform teams
-36%
Reduced Navigation Time
+40%
Feature Discoverability
+25%
Task Efficiency
-20%
Accelerated Onboarding
Adoption Flow Performance: Navigation Redesign
Before:
Limited discoverability and unclear provisioning led to significant drop-off across stages
40%
20%
30%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a Datastreams
Users who started setting up & activated
Clearer navigation and entry points drove higher discoverability, smoother configuration, and a +60% increase in overall adoption.
After:
65%
32%
50%
(of total users)
(of total users)
Discover
Configure
Activate
Users who found Datastreams feature
Users who started setting up a dDatastreams
Users who started setting up & activated
Outcomes
Stabilizing the Ecosystem
By focusing on the Data Architect’s need for structural precision over feature breadth, the Schema Editor GA release successfully shifted the platform from a manual, high-error modeling environment to an automated, scalable foundation.
Quantifiable Impact
The following results were measured after the first quarter of GA, demonstrating the success of the “Pipeline Raadiness” strategy
-32%
Ingestion Failure
A significant reduction in downstream errors caused by “Confident Mistakes” at the schema level
+38%
Segmentation Confidence
Increased trust from Marketing Analysts in the data being used for high-stakes campaigns
+26%
More Predictable Modeling
Improved consistency in how schemas were extended and reused across different teams.
-20%
Operational Drag
Reduced the need for manual ETL and engineering intervention to “fix” corrupted profile fragments
Qualitative Wins
Beyond the numbers, the editor fundamentally changed how data moved through the Adobe Experience Platform
From Bottleneck to Enabler
Schema creation moved from a slow, code-heavy process to a drag-and-drop experience that accelerated time-to-segment.
Democratic Modeling
The “Mixin” architecture allowed teams to successfully extend schemas without relying on a central engineering team for every change.
Systemic Consistency
The editor enforced a “Global Blueprint” that standardized identity resolution and profile behavior across the entire ecosystem
Related Case Studies
AI-assisted Data Mapping
Data Collection Integration
Let’s Work Together
Interested in collaborating on complex UI/UX challenges involving data, AI, or enterprise systems?
I’d love to explore how thoughtful design can drive clarity and business impact.
Get In Touch
About Kelli
Product Designer | AI x Data Systems
Passionate about turning complex data and AI systems into clear, trustworthy, human-centered experiences
© 2025 Kelli Nordfelt,
Based in: San Francisco, CA