App Exchange & Integrations Platform

In one line

Seismic connects to Salesforce, Microsoft 365, Slack, Zoom and 150+ other tools. In 2025 I led the design of the five surfaces that make those connections discoverable, buildable and usable — the public Exchange marketplace, the partner Developer Portal, the internal App Registry, the in-CRM seller experience, and Slack. Here is where that landed:

888MAPI calls in 2025, up 35% year over year

3,703Apps created by partners and customers, up 76% YoY

43MActions taken inside CRM by 33K sellers

+141%Growth in Slack actions year over year

Seismic Exchange, live Developer Portal, live

Context and the problem

Revenue teams don't work in one tool. An account executive moves between Salesforce, Outlook, Slack, Zoom and a content library in a single hour. Every context switch to go and find the right asset is a tax on the seller and a leak in the funnel.

Three forces were compounding at once:

Tool fatigue. Sellers were asked to leave their work to fetch content, then carry it back by hand.
A fragmented ecosystem. Integrations had been built opportunistically over years. Each had its own entry point, its own vocabulary, its own idea of what an "app" was.
An AI deadline nobody had scoped. Agentic tooling was arriving, and our own audit put only 13% of public APIs at high agentic compatibility. Agents can't reason about an ecosystem that isn't legible.

Five surfaces, three owners, two external hosts, and no shared definition of the thing they were all describing.

The constraints were as real as the problem. The Developer Portal was hosted externally on ReadMe. Slack imposes its own UI framework and its own scarcity of space. The App Registry was a legacy internal tool. Analytics lived in Snowflake and Sisense, reachable only by asking someone. And the surfaces reported into different teams, so "just make them consistent" was an org problem wearing a design problem's clothes.

My role and what I owned

I was the lead product designer for the Integration Platform, setting the UX direction across all five surfaces and designing several of them directly.

I owned the cross-surface strategy and the surface map that framed the work; the Exchange marketplace modernization; the Developer Portal redesign; the App Registry analytics specification; the CRM Contact Picker and Advanced Search flows; the Connect-with-CRM and delegation states; and the Slack Home Tab.
I shared Slack Notifications with Alex Morrow and Nate Shevlin, and set the Slack design standards the wider group built against.
Teammates owned Programs in Slack (Allison Waldrop) and Aura Search in Slack (Anousha Gawshinde and CJ Xue), working from the shared patterns and Block Kit direction.
Engineering and product owned the API surface itself, the agentic compatibility work, and the Snowflake data pipeline behind the dashboards I specified.

A note on scope

This was not a redesign of one product. It was five parallel tracks that had to arrive at the same place. Most of my job was deciding what had to be identical across them, and what was allowed to differ.

Goals, and how we'd know

We set the bar before designing, because "improve integrations" isn't measurable:

Let customers find and install integrations without a sales conversation. Measured by apps created and by Exchange traffic converting to installs.
Let partners ship an integration without talking to us. Measured by self-serve app registrations and support ticket volume.
Increase action taken inside the tools sellers already use. Measured per surface: CRM, Slack, M365 Copilot, mobile.
Make the platform agent-ready. Measured by the share of public APIs rated high for agentic compatibility.

There was a problem with all four: we could not actually measure any of them. Usage data existed in Snowflake but no one outside the data team could reach it, and no partner could see how their own app was performing. So the first design deliverable wasn't a marketplace. It was instrumentation.

Research, and the three things that changed direction

1. It wasn't five products. It was one journey with five addresses.

I started by mapping every surface a customer, partner or seller could touch, and who owned it. Laying them on one page was the moment the real problem became visible.

Integration platform surface map showing Seismic.com, Seismic Exchange with landing and detail pages, the externally hosted Developer Portal, App Registry with analytics, and the Seismic app — The surface map that framed the programme. Five columns by host: *.com*, Exchange (landing list view → detail/install), the externally hosted Developer Portal, App Registry with analytics, and the app itself. Stars mark the surfaces we committed to in the first phase.

A partner building an integration had to cross four of those columns, two of which we didn't host, and each of which called the same object something different. The fix wasn't five redesigns. It was one vocabulary — app, listing, integration — defined once and enforced everywhere.

2. In Slack, we were designing for the wrong unit of work.

Studying how sellers actually used Slack produced three shifts that reframed the whole surface:

Slide titled Make Slack more efficient and intuitive listing three mindset shifts: individual users to multiplayer teams, deep work to quick work, pull interactions to push interactions — Three mindset shifts: **individual users → multiplayer teams**, **deep work → quick work**, **pull interactions → push interactions**. Each one invalidated a design we had already started.

The third shift was the expensive one. We had been building Slack as a place to go and search — a small version of the web app. But the value of Slack is that it comes to you. That killed the search-first concept and made notifications, not search, the centre of the surface.

3. A third of users were silently disconnected.

In CRM, the prompt telling a seller to connect their account only appeared once they had already started typing a recipient. The data confirmed the cost: about 30% of users had not taken the action to reconnect after an inactivity disconnect. They weren't refusing. They never saw the prompt.

The feature existed, worked, and shipped. It just fired at a moment when nobody was looking at it.

Strategy and the decisions that mattered

Decision 1 — Measure first, redesign second

Rebuilding the marketplace before we could see app-level usage would have meant shipping on opinion. So I specified two analytics surfaces before touching the storefront: a cross-tenant view for Seismic, and a per-app view partners could see themselves.

Specification for a high-level cross-tenant analytics dashboard with usage charts, top tenants by enabled apps, a data grid, and component specs for filters, tooltips and export states — Dashboard 1 — the high-level, cross-tenant view: installs and enables per app and per tenant, apps with the most API and extension activity. Specified down to the filters, date pickers, tooltip KPIs and export toast, all built on Seismic's Mantle data grid rather than new components.

Specification for the per-app usage dashboard inside App Registry, showing a new Analytics tab, drill-down breadcrumbs, and insight cards that act as filters — Dashboard 2 — app usage detail, placed inside App Registry where owners already work. Three moves carry it: a new *Analytics* tab, language simplified to **Apps / Requests / Analytics**, and breadcrumbs that let you drill from all apps into one. The insight cards aren't decoration — installed, enabled, disabled and uninstalled each act as a filter on the table below.

Decision 2 — Use the host's design system, not ours

The instinct inside an enterprise company is to make every surface look like the enterprise. I argued the opposite for Slack: an app that ignores Slack's conventions reads as a foreign object in the one place where familiarity is the entire value proposition.

Slack UX Resources slide linking Confluence best practices, Slack Block Kit and Slack Figma stencils — The resource kit I put in front of the team: *"Slack has its own UI Kit. Let's use it!"* Block Kit, Slack's Figma stencils, and a Confluence page of best practices, so four designers working on different features would land in the same place.

This was the decision with the most friction. It meant accepting constraints we didn't control and giving up some brand expression. The payoff was that our Slack surface stopped looking like a port, and the four designers working on it converged without a weekly review.

Slack best practices card listing ten guidelines including leveraging AI and automations, clear channel guidelines, prompt responses and avoiding notification overload — The written standards that came out of it. *Avoid notification overload* sits on this list because the push-interaction insight cuts both ways: the surface that reaches you is also the surface that can wear you out.

Decision 3 — Design for the agent as a user

With only 13% of public APIs rated highly agent-compatible, "AI-ready" was a platform property, not a feature. In the Registry that meant treating an MCP connector as a first-class app with the same registration, permissioning and activity trail as any other.

End-to-end flow from App Registry list through app creation into a detail page for an MCP Connector for Claude, with permissions, endpoints and an activity log — Registry → create → configure → observe, shown end to end with an MCP connector. The same lifecycle a human integration follows, so agents inherit the permission model and the audit trail instead of routing around them.

The solution, surface by surface

Exchange — a marketplace you can shop without us

The old path to an integration ran through a salesperson. The modernized Exchange lets a customer browse by outcome, evaluate against categories, and install.

Seismic Exchange landing page with a search bar, featured app carousel, and apps and templates grouped under Analytics, Communications and Collaboration categories — The Exchange landing page. Search sits above everything; below it, apps *and* templates are grouped by the job they do — Analytics, Communications, Collaboration — rather than by who built them. Splitting apps from templates on every row was the fix for the biggest source of confusion in the old catalogue.

Exchange detail page for a Financial Services DSR template showing a media carousel, overview, how it works, and a sidebar with categories, version, developer and Seismic Certified badge — The detail page carries the evaluation. *Overview* and *How it works* answer what it does; the sidebar answers whether to trust it — categories, version, developer, and a **Seismic Certified** badge that states plainly who built and verified it.

Developer Portal — a partner's path from curious to shipping

The portal had documentation but no route through it. I restructured it around the sequence a developer actually follows.

Developer Portal home, support page and API documentation shown side by side with navigation, search and an interactive API request panel — Home, Support and API Docs. The home page opens with documentation entry points and a low-code path for people who won't write against the API at all, and closes on a single call to action: *Ready to build your app?* The docs put a live request panel next to every endpoint, so the first successful call happens in the browser.

Developer Portal guides including a numbered Get Started flow, a featured app guide with background image do and don't examples, and an apps and listings explainer — Guides carry the rules we used to deliver by email. *Get Started* is numbered — register, create, authenticate. The featured-app guide shows listing artwork as annotated do/don't pairs, which is the only format that reliably prevents a rejected submission.

CRM — the surface where sellers actually spend the day

Most seller time is inside Salesforce and Dynamics, so this is where a saved click compounds. I worked on two threads: making the right content obvious, and removing the connection failures that quietly blocked everything else.

Predictive content inside CRM shown as tile and list views with public and internal groupings, filters and a predictive score column — Predictive content in the opportunity, in tile and list form. Content splits into *Public* and *Internal*, and the list view exposes status, recommendation, views, shares and predictive score, so a seller can judge an asset without opening it.

Current CRM experience compared with new designs adding an Aura panel, content relevance metrics, reviews and an Ask Expert flow — Current versus proposed. The new right-hand panel turns a static properties list into three live things: **content relevance** (deliveries, comments, average page views and time on page), **reviews**, and **Ask Expert** — a full question-and-answer loop so the knowledge a seller needs comes back into the asset instead of disappearing into a DM.

Two thirteen-step Advanced Search flows for the CRM contact picker, one with no account selected and one with an account selected, each frame annotated — Contact Picker enhancement, specified as two complete flows — no account selected, and account selected — because the second case behaves differently at every step. Thirteen frames each, from empty state through loading, filtering, drill-down into a lead, and the selection drawer, with the expected behaviour written under every frame.

Slack — bringing the work to the seller

Following the push-not-pull insight, the Slack surface is built around arrival: it tells you what it can do, then brings you things.

Slack Home Tab showing a welcome panel, the linked tenant, a disconnect control and a list of things you can do after connecting — The Home Tab I designed. It answers the two questions the old integration left open: *what can this thing do* — a plain list, from finding content to submitting for approval — and *am I actually connected*, stated outright with the tenant named and a disconnect control in view.

Slack notifications settings with granular per-user controls grouped into content, programs and channel notifications, split by seller and enabler needs — Notifications, with Alex Morrow and Nate Shevlin. Push only works if the user controls it, so the settings split by role — sellers get new and updated content, mentions, assigned learning; enablers get program activity, expiring content and approval requests — each at user level, not tenant level.

Programs in Slack showing a channel linked to a program, with introduce app and manage connection controls — Programs in Slack (Allison Waldrop) — the multiplayer shift made concrete. A channel links to a program, tasks are created from messages, and program updates post back, so the team's work and the channel stop being two separate records.

Aura Search in Slack answering a question in-thread with cited sources and a share sources action — Aura Search in Slack (Anousha Gawshinde and CJ Xue). Answers arrive in-thread with citations and a *Share sources* action — the quick-work shift, where the win is an answer in the conversation rather than a link to go and read.

Validation and iteration

We thought the reconnect prompt worked. It didn't. So we moved it.

The clearest loop in the project. We thought the existing Connect-with-CRM notice was adequate — it shipped, it functioned. We learned it only appeared after a seller began typing a recipient, and roughly 30% of disconnected users never reconnected. So we did two things: moved the prompt to the moment the compose window opens, and prototyped both ways of delivering it before choosing.

Connect with CRM explorations comparing an inline option and a pop-up option, with a use case note describing the problem, proposed solution, workaround and value — Option 1, inline: a persistent *Connect your CRM* control in the compose header with a tooltip. Option 2, pop-up: a dismissible card over the message body. Inline is calmer and easier to ignore; the pop-up is harder to miss and costs a dismissal. We went with the pop-up, because the measured failure was people not noticing — but kept *Don't show this again* so it can't become the next annoyance.

The same audit surfaced a harder case underneath it: delegates. When one person sends on behalf of another, whose CRM connection matters? I worked the active and inactive states across three options rather than guessing.

Three design options for CRM delegation status, each showing a CRM active and a CRM inactive use case in the recipient picker — Delegation status, three options × two states. The question each one answers differently: does the delegate see the connection status of the person they're sending for, and can they act on it? The chosen direction surfaces status in the recipient row itself, where the decision is already being made.

Killing a visualization we liked

Predictive score needed a representation. I put fractions, percentage bars and star ratings in front of reviewers together.

Predictive score explorations comparing fraction and percentage bar treatments against a five-star rating, with review comments questioning each — The feedback killed the nicest-looking option: *"These feel too much as user inputs."* Stars read as something you set, not something the system computed. The open questions in the left column — how is the score calculated, do we sort by it, what does colour mean — were the actual finding, and they sent us back to product before any visual decision could stand.

Listing creation, second pass

Redesign V2 board for listing creation covered in reviewer sticky notes about image handling, simplified template listings and AI-assisted content generation — Listing creation, V2, mid-critique. The notes are the work: reorder, crop and clean images; simplify the flow for templates, which need far less than apps; move listing requirements to the front so nobody fills a form they'll fail; and the thread that became the next roadmap item — let AI draft the listing copy and generate candidate thumbnails from the template itself.

Outcome and impact

The instrumentation we built first is what makes this section possible at all. These are the platform's 2025 numbers, end to end:

2025 in review

Seismic Integration Platform

888M API calls ↑ 35% YoY

3,703 Apps created ↑ 76% YoY

13% Of public APIs rated high for agentic compatibility Baseline for FY26

Platform

2,033Hours run through the AI code generator

192Tenants on standardized roles & permissions

118Tenants on org hierarchy

1,159Tenant operations — creation, refresh & upgrade

Surface areas

43MActions in CRM33K users

148KActions in Slack↑ 141% YoY

9KActions in M365 Copilot116 users

25KActions in Agentforce~105 users

13KMobile monthly active users↑ 25% YoY

Source: Seismic Integration Platform annual review, 2025.

Two of those deserve a note. Apps created up 76% is the self-serve goal paying out: partners and customers building without a conversation. Slack up 141% is the push-not-pull decision paying out, and the surface dashboard shows it wasn't a spike — actions climbed from a 2021 baseline to 9,932 in a single 30-day window, against 317,611 all time across 144 tenants.

Slack integration usage dashboard showing 9,932 actions and 2,760 users in the past 30 days against 317,611 actions all time, with activity plotted from 2021 to 2025 — The Slack usage dashboard, November 2025. The shape of the curve is the argument: a flat baseline through 2021–2022, then sustained growth as the surface moved from search-first to notification-first.

The platform numbers are the unglamorous half, and they are the ones that decide whether an ecosystem stays coherent as it grows: standardized permissions, a consistent org hierarchy, and a repeatable path for creating and upgrading a tenant.

Treating integrations as a designed platform rather than a list of connectors did two things at once: it removed friction from the seller's day, and it turned every partner into a distribution channel.

What I'd do differently

Define the vocabulary in week one, not month three. App, listing, integration and template meant different things on different surfaces, and we discovered it through rework. A single glossary agreed across the five teams would have been the cheapest artefact of the project and I produced it late.
Instrument even earlier. Building the dashboards before the storefront was right, but I still spent the first weeks arguing from intuition because the data wasn't reachable. If usage isn't visible, the first design problem is always visibility.
Take the host's design system decision to the group sooner. I made the Block Kit call after two designers had already invested in Seismic-styled Slack concepts. The reasoning held, but the cost was theirs, not mine.
Push harder on agentic compatibility as a design constraint. We treated 13% as an engineering metric. It's also a design one — naming, structure and permission models are what make an API legible to an agent, and I engaged with that later than I should have.

The broader lesson is about where leverage sits in platform work. The marketplace was the visible deliverable, but the things that actually moved the numbers were a shared vocabulary, a measurement surface, and a decision to stop imposing our design system where it didn't belong. None of those photograph well. All three are why the rest worked.

Client

Year

Role

Team