1. Executive Summary
This project was not simply an app marketplace. It represented a shift from treating integrations as isolated product features toward treating them as a platform ecosystem.
The visible surface was a marketplace, but the deeper design problem was architectural: how should Attentive create a reusable product framework for discovering, installing, configuring, and managing integrations as the ecosystem expanded?
My role was UX ownership for the marketplace and integration template architecture. The work created reusable patterns for integration discovery, onboarding, configuration, and management while giving product and engineering teams a clearer model for future integrations.
2. System Context
The integration experience had grown quickly. Different integrations could have bespoke onboarding, bespoke settings pages, different authentication patterns, different configuration requirements, and different support context.
That model can work when an ecosystem is small. It becomes expensive and inconsistent as the platform grows. Customers have to relearn each integration. Engineers have to rebuild or reinterpret setup patterns. Product teams lose a shared model for what an integration should contain.
Mental model:
Marketplace -> Discovery -> Installation -> Configuration -> Management -> Future capabilities
3. The Real Problems
The problem was not only that users needed to find apps. The real question was how to design one architecture capable of supporting integrations that had not yet been built.
Integrations could vary across OAuth, API keys, sync configuration, marketing segments, journeys, campaigns, product catalog, list growth, offers, webhooks, and future health or observability concepts.
Without reusable architecture, every integration increasingly behaved like its own product. That created more learning cost for customers and more implementation ambiguity for internal teams.
4. Design Principles
- Reusable patterns beat bespoke screens.
- Configuration systems need predictable homes.
- Explanation and operation are different jobs.
- Consistency is a scalability mechanism, not only a visual preference.
- Platform architecture should support capabilities that do not exist yet.
- Developers and product teams need clear defaults plus room for exceptions.
5. Major Decisions
Separate Discovery From Management
Marketplace discovery and installed integration management were different user jobs. Discovery answered, "What can I connect?" Management answered, "What have I connected, how is it configured, and what do I need to do next?"
The marketplace IA used search, categories, Installed by You, and Custom paths so users could browse available integrations, return to installed integrations, and understand where non-standard or customer-specific integration paths belonged.
Standardize Overview And Settings
The most important template decision was separating explanation from operation.
Overview explained what an integration did, what capabilities it supported, and where users could find documentation or support. Settings handled authentication, API keys, segment selection, sync configuration, advanced controls, and future capability modules.
That split gave developers and product teams a clear starting point: does this belong in Overview or Settings? Is this reusable configuration or an integration-specific exception?
Create A Configuration Framework
The configuration framework needed to support common setup patterns without pretending every integration was identical.
6. System Evolution
Bespoke integration pages
-> Marketplace and integration templates
-> Reusable configuration modules
-> Integration Health / Data Health possibilities
The early question was how users find, install, and configure integrations. The later platform question became how users trust that integrations continue working.
7. Collaboration Model
Product partners needed a model that aligned with marketplace maturity, partner ecosystem growth, API adoption, and future platform capabilities.
Engineering partners needed patterns that could be implemented repeatedly instead of requiring a bespoke page structure for every integration.
The useful collaboration outcome was shared language: marketplace, overview, settings, configuration modules, installed state, custom paths, and future health/status.
8. Results
Product outcomes:
- Created a reusable marketplace architecture for discovery, installation, configuration, and management.
- Standardized integration pages into a reusable Overview / Settings model.
- Defined configuration patterns for OAuth, API keys, segments, sync setup, and integration-specific modules.
Organizational outcomes:
- Reduced UX ambiguity for future integration work.
- Gave developers a more familiar framework for building integration settings pages.
- Helped separate reusable platform patterns from integration-specific exceptions.
9. Reflection
The biggest lesson was that platform products scale through abstractions rather than individual screens.
An individual integration page can be well designed and still fail the platform if every future integration requires a new mental model. The compounding value came from designing the system of decisions: marketplace, overview, settings, configuration modules, lifecycle, and exception handling.
10. Reusable Patterns
- Marketplace ecosystem IA.
- Overview / Settings split.
- Configuration modules.
- Lifecycle-based integration management.
- Reusable platform templates.
- Exception handling inside a stable system.
- Future health and observability entry points.
11. Lessons That Carried Forward
This work connected naturally to EDS, Integration Health, and Data Health. Once integrations became more standardized, the next platform question became trust: is data moving, are syncs fresh, and what should users do when something breaks?