Building a scalable integration strategy

Integrations have become a new norm in a world of never-ending technological advancements. Products are spinning up left and right to solve real problems, many of which leverage integrations to connect with the rest of the user experience. This is no different than what we face here at Lucid as we help teams see and build the future. So, how is this possible when the world of visual collaboration encompasses a wide range of different types of products? We started by developing our integration strategy.

Our integration strategy is broken up into four main components. They are:

1. Understand where visual collaboration is needed
2. Identify the products being used
3. Be the first to build
4. Build the infrastructure to scale

Understand where visual collaboration is needed

Before we start building integrations or APIs, we need to ensure that we are building the right thing first. We like to start by talking with the users of our product to understand where visual collaboration is needed. We ask questions about how our products are being used, what types of content are being created, why that content is valuable, who needs access to it, and where it may be distributed. 

From here, we gather incredible information that guides us on our integration journey. This information is the primary reason we started our integration strategy by focusing on enabling users to embed Lucid-built content into third-party tools such as Jira, Confluence, Google Workspace, and Microsoft 365. We heard things such as, “Process documentation is hard to follow whereas a visual diagram is not.” This begged the question: “What if process documentation and the visual lived together on a single page?” 

As we continue to talk to users and strive to deeply understand their workflow, we will identify more areas where an integration can significantly impact the users’ workflow.

Identify the products being used

After we have identified and prioritized our target use cases, it’s time to prioritize at a much more granular level. In theory, bringing process documentation and the visual together is simple. However, we soon realized how many different products are being used to store process documentation. 

Once again, we go back to our users to help us narrow down this list. We use interviews and surveys to gather data, and we look for trends both from our users and within the market itself. Our goal is to identify the products that are being used by the largest percentage of our user population. At this point, we typically have a list of different products being used, prioritized based on usage from our existing users. We take the first product, and we dive in. 

Be the first to build

Now that we understand the use case and have prioritized the products to integrate with, it is time to execute. Understanding the use case is very different from understanding how to solve the problem technically speaking. Integrations are not like normal feature development where we control the entire user experience. With an integration, we are dependent on the third party and their APIs, which inevitably dictate what is possible. 

We build the first integration as a way to become familiar with the third party and deepen our understanding of the use case/solution. We do rigorous testing with users to validate that the solution solves the problem and that the user experience is a delight. Lastly, we get it out to all of our users as quickly as possible and listen for feedback.

While the first integration is launching, we start to think about the next one. We use our prioritized list of products to determine what we should work on next. However, this time we really focus on scalability. Our main focus is how we can leverage the first integration to speed up the development of the third, fourth, and fifth integrations. One of the best ways to solve this is through API development. 

Build the infrastructure to scale

As soon as the first integration is complete, we closely monitor the performance of the integration. Is the integration being used, how often is it used, is it providing the value that we expected, and is it positively impacting our users? Assuming our due diligence paid off and all aspects of performance are trending positively, we transition to scaling. It is impossible to keep up with integration demands and new products constantly being introduced to the market, so our goal is never to build them all. Instead, we focus on how we might enable a third party to build an integration on their own, should it be needed. This is typically done via well-built and documented APIs. 

The reason we start by building an integration is to enable us to really understand what these integrations might look like. In addition, it allows us to test our understanding of data and feature requirements that are necessary to support the use case. We use all of this information to build or update our API to support the use case, and then we open it up to the public. We believe that humans work better visually, so opening it up to the public helps democratize problem-solving through visual reasoning.