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.
The public version should be read as a strategy, research, and technical IA case study. The final implementation reflected a narrower scope than the broader design exploration.
2. System Context
Mental Model:
Draft -> Submit -> Attentive 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, internal reviewers, customers, 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 customer-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 support.
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:
Draft -> Submit -> Review -> Beta -> Public -> Updates -> Performance
The model clarified what a mature partner-built app platform could support, even though only portions were adopted in the final implementation.
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.
Final implementation: the shipped scope was narrower than the broader strategy. This case study is honest about that boundary.
7. Collaboration Model
Product partners connected Create App 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 draft, 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 customer 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 may still ship in a narrower form because of engineering capacity, organizational priorities, and market timing.
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 shipped implementation. It also connects back to the integration platform foundation: partner ecosystems need stable homes, reusable patterns, and clear paths for both builders and customers.