Improving Partner Integration UX for Self-Serve Enablement
As our partner ecosystem expanded, we found ourselves building custom integrations for each partner with significant involvement from internal developers. This approach became increasingly unsustainable—onboarding was slow, the integration process was rigid, and the overall experience required heavy support.
To address this, I led the end-to-end redesign of the integration workflow, transforming it into a modular, self-serve platform. This shift empowered partners to configure and launch their own pre-built integrations with minimal handholding. By grounding the solution in user research and iterative design, and closely partnering with engineering, we significantly reduced integration time and support load.
This case study outlines the key challenges, design decisions, and outcomes that helped us scale our partner operations through thoughtful UX.
change.
Working as an IC on a technical project
I joined the project at the very beginning while the opportunity was being discussed. I was the sole designer on this project, working as an individual contributor in a fast-paced, highly time-sensitive environment. With tight deadlines and multiple stakeholders involved, I led the end-to-end design process—from discovery and research to wireframes, prototypes, and final handoff.
​
Other than me, there were 2 PMs, 4 Devs in this project.
Was the re-design really needed?
Based on feedbacks from Product Solution Group (PSG) team and developers, we identified that every integrations that was being built, took a lot of time in getting to its handover state. There were multiple reasons leading to this
Information Silos Causing Delays
Information was scattered and disorganized, leading to delays in finding accurate, complete details.
Manual Testing & Developer Dependency
Publishing integrations required extensive testing and developer support, creating friction due to the technical burden on partners.
Too Many Steps, Too Little Guidance
Unintuitive information and a complex, multi-step workflow led to frequent developer back-and-forth and added friction.
Lack of Visibility into Partner Issues
Limited logging and a rigid RBAC system made it hard to track issues and support partner activity.
How might we accelerate partner integration building process to enable faster go-to-market with minimal friction and support dependency?
Who we designed for?
A mid- to senior-level engineer at a partner organization responsible for building and testing integrations. They value clear documentation, stable test environments, and minimal support dependency, as they often work under tight timelines with limited familiarity with our platform.
Design strategy that we focused on
Our research revealed numerous potential solutions to the problem, but with limited resources and an even tighter timeline, we had to be strategic. To gain a competitive edge and retain our partners while expanding to more use cases, we carefully prioritized ideas. Ultimately, we focused on three key strategies to move forward.
Knowledge assistant to help partners
Allow partners to test integration
Bring more training during onboarding
Have a unified documentation platform
Pre-fill information to cut down cognitive load
Reduce number of steps involved in workflow
Improve visibility towards self troubleshooting​
Build issue tracking system for internal and partners
Allow partners to test integration
As someone new to the domain, I needed to understand the integration process end-to-end to design effectively. I worked closely with a developer and built sample integrations myself to identify friction points. This hands-on approach, combined with partner feedback, revealed key issues like mismatched data formats, inconsistent test environments, and outdated test datasets—insights that directly shaped the design strategy.
Pre-fill information to cut down cognitive load
This issue also ties into our strategy of reducing workflow steps. Since each integration requires slightly different inputs, aligning pre-fillable information was challenging. However, we noticed that much of the metadata—like brand name, website, and support info—overlaps with onboarding data. Identifying these repeated data points revealed several opportunities to pre-fill fields and streamline the process.
Improve visibility towards self troubleshooting
To improve visibility into self-troubleshooting, we focused on empowering partner developers to independently identify and resolve issues during the integration process. Developers often face silent failures or vague error messages, leading to unnecessary reliance on support. From the partner developer’s perspective, having access to clear, actionable insights is what we were aiming to achieve.
Success metrics to look out for
To measure the effectiveness of improving the integration experience for partner developers—especially in reducing friction, increasing self-sufficiency, and accelerating time-to-market, we decided to track the following metrics.
Time to complete integration
Indicate speed and the efficiency of building an integration
Support ticket raised
Indicate support dependency & self serve use case
Error rate for testing
Indicates if there is friction that can't be resolved
Key design screens
To measure the effectiveness of improving the integration experience for partner developers—especially in reducing friction, increasing self-sufficiency, and accelerating time-to-market, we decided to track the following metrics.
_edited.jpg)
Learnings from pilot study
We conducted a quick pilot study with 3 partner developers to evaluate whether the work we've done is genuinely impactful and aligns with the user goals we set out to achieve. We received some valuable insights from this study, some being
​
1. User needed some handholding on changes done on few menu items, we later introduced small tour tips so that they can get to the action quickly.
2. Some of the issues still surfaced during testing the integration, but the developers were able to resolve them by themselves.
3.The navigation and the the blocks of how the information got segregated was quite helpful.
4.Content was much easier to interpret than the previous way of information.
TESTIMONIALS
“It was interesting to see that I could test the integration right on the platform and didn't have to jump into multiple windows to get the test data and other info that I needed"
“From the previous platform, I found this version to be more intuitive, it gives me exactly where to get the details and is better arranged!"
Business impact
In enterprise most of the value of a feature comes in when there is a business revenue associated with it and it was the same case for this too. We saw some wonderful metrics/changes after doing a platform refresh.
46%
Time saved on integration building
More RFPs
More inclinations towards self serve use cases from marketing teams
29%
Reduction in support queries