1. Executive Summary
Attentive wanted to enable partner-built applications rather than relying only on internally developed integrations. The challenge was not simply exposing APIs. The larger product question was how to create a cohesive self-service experience around creating, configuring, testing, publishing, distributing, maintaining, and updating partner-built apps.
My role was product design and UI design. I researched comparable SaaS platforms, formed a point of view that developers should be treated as first-class users, proposed a lifecycle and persona-informed IA, and partnered with engineering to validate technical workflows.
2. System Context
Mental Model:
Working version -> Submit -> Review -> Beta -> Public -> Updates -> Performance
Objects and workflows included app identity, app details, marketplace listing, API permissions, webhooks, install URLs, authentication, review status, beta workflow, publishing, updates, and operational awareness.
Stakeholders included product owners, marketers, developers, partners, reviewers, product partners, and engineering partners.
3. The Real Problems
App creation was bigger than a form. A narrow Create App flow would not support the full lifecycle of partner-built applications.
Two personas needed different levels of complexity. Product owners cared about branding, listing quality, descriptions, and user-facing value. Developers needed API permissions, webhooks, install URLs, authentication, and technical configuration.
Developer tooling had to be productized. Documentation alone could not carry the full burden of developer enablement if the platform wanted partners to create, configure, submit, and maintain apps with less manual assistance.
4. Design Principles
- Developers are users.
- Good platform UX reduces friction before documentation is needed.
- Technical power should not require every user to see every technical detail.
- App lifecycle should be visible.
- Information architecture should follow user intent, not backend implementation.
- Publishing should feel like a workflow, not a one-time button.
- Research should support conviction when the team has competing opinions.
5. Major Decisions
Organize Around Mental Models
The proposed IA separated app context, marketplace presentation, and technical configuration:
Overview -> App Details -> Developer Settings
Overview handled status, readiness, and high-level app context. App Details handled branding, marketplace listing, descriptions, and product-owner concerns. Developer Settings handled API permissions, webhooks, install URLs, authentication, and technical configuration.
Use Progressive Technical Disclosure
Basic app information should not require understanding webhooks or API permissions. Developers should encounter technical configuration when they need it, while product owners should have a clear space for public app presentation.
The design separated technical settings without disconnecting them from the broader app lifecycle.
Treat Publishing As A Workflow
Publishing was modeled as a lifecycle:
Working version -> Submit -> Review -> Beta -> Public -> Updates -> Performance
The model clarified what a mature partner-built app platform could support and helped identify which parts of the experience should become reusable platform patterns.
Validate Technical IA With Builders
Initial disagreement about settings organization needed evidence, not preference. Competitive research and developer feedback helped validate the settings taxonomy and convert the discussion into shared product judgment.
6. System Evolution
Earlier state: app creation could have been understood as a narrow setup flow.
Design exploration: the work expanded into a lifecycle model for partner-built apps.
Implementation planning: the work helped separate the broader platform direction from the parts that could be approached first.
7. Collaboration Model
Product partners connected app creation to marketplace publishing, partner-built app strategy, and review workflow requirements.
Engineering partners helped validate API permissions, webhooks, install URLs, authentication, and technical settings organization.
Design work used competitive research across Klaviyo and Stripe to clarify why developers should be treated as product users, not only documentation readers.
8. Results
Product outcomes:
- Created a design-led model for partner-built app creation and configuration.
- Explored a more mature app lifecycle across review, beta, publishing, updates, and performance.
- Proposed IA separating Overview, App Details, and Developer Settings.
Business outcomes:
- Supported the strategic idea that better developer experience could strengthen the integration marketplace and increase user choice.
9. Reflection
The biggest lesson was simple: developers are users.
Designing technical products requires understanding developer workflows, not simply exposing APIs. This work also clarified a practical lesson about strategy: the strongest design exploration should make it easier to choose what to build first without losing sight of the larger platform model.
10. Reusable Patterns
- Developer-first app creation.
- Partner-built app lifecycle.
- Progressive technical disclosure.
- API permissions model.
- Webhook configuration model.
- Install URL model.
- Marketplace listing review workflow.
- Product-owner / developer persona split.
- Technical IA validation with engineering.
11. Lessons That Carried Forward
Create App strengthened my thinking around developer experience, self-service tooling, technical IA, and the difference between strategic exploration and implementation planning. It also connects back to the integration platform foundation: partner ecosystems need stable homes, reusable patterns, and clear paths for both builders and users.
