From Product to Platform: How to Build a Platform UX for Partners & Customers

Over at the SaaS Ecosystem Alliance, we hosted a discussion with product and platform design leaders about best practices for building a platform UX that partners, partner developers, and customers will love. 

Our CEO Cristina Flaschen talked with Richard Fortune (Product Manager for Platform Experience at Xero), Courtney George (Head of Design for Data at Amplitude), Kirby Montgomery (Vice President of Product Leadership at C2FO), and Ashwini Sriram (Group Product Manager at Twilio).

‍

‍

Partner Developers can vary from small agencies building an extension to developer teams from large SaaS companies building complex integrations. When you’re thinking about the design of developer user experience, what are some of the ways you’ve ensured that the experience is consistent and works for the different kinds of personas that may be using your platform? 

Courtney suggested developing a deep understanding of all the personas involved in the experience, keeping in mind that developers will not always be the only personas involved in your platform. 

“Keep in mind all the consumers of your platform. It’s not just developers that are involved in this ecosystem, there are also decision-makers and marketers for example. You have to think about how everyone is going to work together and interact with your platform.”  - Courtney Maya George, Head of Design for Data at Amplitude

After identifying the different personas that will be involved on a platform, and the different functions they will likely need to perform, she suggested focusing on designing for scale. 

She recounted her time at Adobe, where there were a wide variety of use cases they had to think through the UX for. They decided on creating a flexible framework where they were more opinionated on the information architecture and navigation of their platform and less opinionated on the specific nuances of each step of the workflows. 

Kirby added that all of the tools of UX designers should be applied when building out the customer journey of a platform. When thinking of platform developer experience, for example, there should be personas and a journey map. 

He recounted bringing in the engineering team at his company and gaining valuable insights from going through this process with them. 

“We would have them imagine that they were integrating with our API, and we asked them to share what would make that experience delightful, and what would frustrate them,” he recollected. “We would have Product Managers and Product Designers there to hear from that persona, and then we’d use this intel to think about how we could create great documentation, how we were going to administer API keys, and what tools we could build to turn our integrators into super users.” 

If companies are thinking about what they should create for their API, he suggested that they look at notable examples in their sector for help with determining a mental model for the industry. He remembered, in particular, looking through Xero’s documentation during his time working in B2B fintech.

Richard urged platform UX designers not to see developers as a special case, but instead as humans working on a team with a job to be done and measures of success. 

“Have a deep understanding of the integration lifecycle and where personas are in the journey. Then after laying down a uniform infrastructure, work on enhancing common touchpoints where experiences and users overlap to make them as delightful and accessible as possible.” - Richard Fortune, Product Manager for Platform Experience at Xero

Building on an earlier point made about personas, Ashwini warned against slotting users into rigid personas. She pointed to the fact that in some cases, for instance, a product manager may wear a hat as a developer when it comes to low-code or no-code tools. In this case, having a strict developer persona may not work. 

Courtney co-signed with Ashwini’s point stating that someone using Amplitude to clean up data might be a data scientist, data governor, or a product manager with some technical knowledge. For this reason, it is a good idea to create personas based on functions as opposed to job titles. 

To this point, Richard shared that Xero is currently re-evaluating what it means to be a partner or a developer using their platform. He pointed out that the domain for their platform users is called developer.xero.com; however, this isn’t just meant to support developers, but everyone who has a platform relationship with Xero. 

As part of this reevaluation, they have a community that does developer experience analysis externally, with the intent to understand the motivations behind decisions other companies are making when creating their APIs. They even look at organizations outside of their business sector, like Miro and Notion, to determine what they can learn from their approach. 

Related Content: The Benefits of Reporting to Sales & Best Practices for Cross-functional Collaboration

How should organizations that engage in GTM activities with tech partners think about the decision to offer one partner portal vs separate partner portals for devs and GTM teams? How do you figure out where people should go to get the information relevant to them? 

Kirby first shared that creating personas based on functions should help inform companies of how and where people do their work. They can then use this to define how access on their platform should work. He pointed to how the developer portal for Xero not only has a space for engineers to build integrations but includes space for customer support functions like resetting passwords.

He added a caveat to be mindful of having a persona where they don’t need to be or where there may be cognitive overload for them that makes it difficult to navigate and complete their function.

Courtney shared that this has been a common discussion in her roles because the variety of use cases they have makes this a complex task. In some circumstances, her teams saw that the same persona was performing functions relevant to both the developer and GTM portal, and it made sense to blend them. In other cases, this was the opposite. 

She stated that there is no one right answer and that the separation depends on the problems a company is trying to solve. 

Whether organizations choose to create separate portals or not, she encouraged all organizations to think about what the end-to-end workflow is across their user’s teams in order to accomplish creating integration and putting it on the market. This is to ensure that even with separate portals, there is a seamless link between the portals and the different experiences. 

Adding to this, Ashwini shared that instead of instinctively thinking about the separation of portals for GTM and developers, to lead with a goal-orientated design. 

“We’ve learned that the separation between developers and GTM teams is starting to break down, and it’s more beneficial to have a goal-orientated platform interface design rather than leading with separation.” - Ashwini Sriram, Group Product Manager at Twilio

She shared that a goal-oriented design that focuses on different jobs such as “I’m trying to create an invoice for a customer” has helped her team at Twilio to think about the design and the success of the design. They always ask whether a design is enabling people to accomplish their tasks with minimal friction. 

Can you share any examples of companies that have done a good job at blending the partner/GTM/Biz Dev experience and the developer experience? 

Kirby shouted out Codat.io, which helps companies offer their small business customers integrations with their accounting, banking, eCommerce, POS, and payment software.    

He stated that they not only do a great job at providing a nice combination of tools but also do great storytelling to demonstrate how users of their platform can implement their tools. 

Kirby explained that they do this by providing use cases involving real users of their product, which helps to show potential platform users why they should be inspired to use and build with their product. He added that he never felt like there were any artificial barriers between him and the next steps of working with their platform, as he was quickly able to access a sandbox and provide access to his developer team. 

He used this example as a way to remind platform builders and designers that developers and product managers want to be inspired too and that they should be mindful of creating artificial barriers for those looking to work with their platform. 

“In B2B, many companies are trying to create large ecosystems, but you will see terrible decisions being made with platform design,” Kirby explained. “Passwords on API docs, or tickets for API keys that take two weeks to process. These are all things that make people less likely to want to work with them, because people want to work with someone who wants to give them their product.”

Related Content: Advice for How to Tackle Technology Partner Operations

Some large SaaS companies like Wix for example allow partner developers to create an account with just an email address, while others require an application to even see the API docs. What factors should organizations consider when thinking about how open they should be to allowing self-serve access to APIs, SDKs, sandboxes, etc. ? 

Courtney looked back at her time at Adobe where this had been an intense discussion across teams. She explained that how open they were with certain components of their API was dependent on a persona and their level of motivation to build with them. Even though there were some cases where there was push back internally, they ended up opening up certain components of their API because companies wanted to build integrations with them. 

They then realized where they needed to be the most open and public was with their documentation. She explained that this allowed her team to show platform users why they should work with their technology and the capabilities, outcomes, and ROI that it could bring before determining whether to allow self-serve access to other components of their API.

Richard, Kirby, and Ashwini then shared their perspective on arguments for and against organizations being more open with their API, considerations to make before providing more self-serve access to them, and advice for companies building a partner experience. They also shared their thoughts on ​​what is commonly overlooked in partner developer UX when companies are transitioning from a product to a platform.

If you're interested in hearing the full discussion, join the SaaS Ecosystem Alliance to gain access to members-only resources and a recording of this event.

You can also register for more upcoming roundtables on interdisciplinary topics relevant to those working in technology partnerships.