1. Executive Summary
EDS is Attentive's data ingestion platform for onboarding, configuring, and monitoring customer datasets used across the marketing platform.
The work helped mature an engineer-led operational utility into a clearer platform experience for onboarding, configuring, monitoring, and debugging customer data workflows.
My role was UX ownership for EDS. I shaped job visibility, configuration UX, mapping recovery, diagnostic dashboard direction, and product-quality consistency with broader Attentive patterns.
2. System Context
Mental model:
External customer data sources
-> EDS ingestion / configuration
-> Data processing / mapping
-> Attentive customer data
-> Product catalog / segments / campaigns
-> Customer-facing workflows
The design challenge was not simply to display data. It was to make system behavior understandable enough for internal users to configure, monitor, and troubleshoot real customer workflows.
3. The Real Problems
Raw job history did not support diagnosis. A table could show success or failure, but it did not explain what happened, when it started, whether it was recurring, how severe it was, or where to investigate next.
Configuration complexity increased as datasets became more diverse. Data mapping, predefined inputs, manual inputs, and advanced setup scenarios needed structure and recovery paths.
Internal tooling needed product-level consistency. EDS was strategically important, but parts of the experience still carried the feel of an engineer-led utility.
Support burden needed to scale down. Internal teams needed enough visibility and control to investigate routine issues before escalating to engineering.
4. Design Principles
- Internal tools deserve first-class UX.
- Operational tooling should explain system behavior over time.
- Configuration should reveal complexity progressively.
- Support surfaces should help users diagnose before escalating.
- Recovery paths should preserve user work whenever possible.
- Important internal systems should align with broader product and design-system expectations.
5. Major Decisions
Transform Job History Into Operational Visibility
The earlier surface primarily answered whether a job succeeded or failed. The diagnostic direction needed to answer human operational questions:
What happened?
When did it start?
Is this recurring?
How severe is it?
What should I investigate next?
The design direction pushed the index page toward a dashboard-like diagnostic surface using familiar reporting patterns.
Use Progressive Disclosure For Advanced Configuration
Common workflows needed clarity, while advanced ingestion cases still needed power and flexibility. The design defaulted to structured predefined options and revealed manual/custom inputs only when needed.
Design For Recovery, Not Just Completion
Mapping mistakes should not force destructive rework. The model differentiated clearing a mapping from deleting a row, allowing users to correct mistakes while preserving the structure they had already built.
Treat EDS As A Product-Quality Platform Surface
As adoption and business importance grew, EDS needed to support customer-facing teams and internal operations with greater clarity and trust. The design aligned EDS with broader reporting UI and design-system patterns.
6. System Evolution
Engineer-led utility
-> Structured onboarding and configuration UX
-> Diagnostic job history / operational visibility
-> Self-service observability and troubleshooting
7. Collaboration Model
I worked with product on scope and requirements, engineering on feasibility and data behavior, customer-facing teams on investigation needs, and design partners on product-quality consistency.
One collaboration pattern was translating vague direction into concrete UX decisions around configuration, job visibility, dashboard structure, and consistency with broader product patterns.
8. Results
Product outcomes:
- Reframed job history from binary run status into a diagnostic surface.
- Designed configuration patterns for mapping, predefined/custom inputs, progressive disclosure, and recovery from mistakes.
- Supported a more mature product-quality direction for a strategic internal platform.
Business outcomes:
- Source notes include adoption growth, catalog coverage, and support-hour goals, but exact public-use metrics need approval before publication.
9. Reflection
The biggest lesson from EDS was that operational tooling should not simply expose data; it should help users understand system behavior over time.
The job-run table was not wrong. It was incomplete. It answered the system's question: did the job run? Customer-facing teams needed the operational question: what changed, when did it start, how serious is it, and what should I do next?
10. Reusable Patterns
- Progressive disclosure.
- Configuration recovery.
- Operational visibility.
- Dashboard thinking.
- Job history as diagnostic surface.
- Design-system parity for internal tools.
- Lightweight observability.
- Self-service enablement.
- Failure timing and recurrence models.0
11. Lessons That Carried Forward
EDS clarified my point of view around operational visibility, configuration UX, and treating internal tools as first-class product experiences. It also connects directly to Integration Data Health, where the same trust question appears at the integration layer: is data moving correctly?