Aligning on personas

While designing the early concepts, I realized the two personas we serve are so different that it became confusing to use the term 'users' since we would constantly mix up who we were talking about. I proposed the team center on two terms, 'builders' and 'consumers'.

Ampersand offers an SDK, hosted service, and UI library for developers who want to build new products that need to integrate with existing systems of record. As one example, a company like Clay (which builds AI for personalized outreach) needs to help its customers sync Clay with other systems within the customers' ecosystem like Salesforce or Hubspot. Clay's engineers are who we call the builders, and they are the ones who pay for Ampersand.

Clay's users, who interact with Ampersand's UI library within Clay to set up and manage integrations with their other tools, are who we call the consumers. They are usually non-technical users but know their organization's SaaS tools very well.

There is a third persona, which we are putting off to a later time, who are the customer success and support roles that work at builders' companies.

Reprioritizing toward MVP

Some of the concepts that were excellent for showing the builder interface to investors were not as valuable to builders, so we deprioritized them. One example is deprioritizating builder page in the product, so that we could focus more on setup and observability.

With the UI library, we found that what is most important to get right for consumers is setup and configuration, which allowed us deprioritize consumer-facing observability.

Some of the more creative ideas in observability were also deprioritized for straight-to-the-point UIs.

Information architecture

Here, we are showing a integration source (or provider)-centric view of your instances. Your Hubspot and Salesforce integration instances are facing some issues, in this example.

In this example above, we are showing a customer-centric view of your instances. Your customer OptimizeForce has turned on a ton of integrations, and a few are degraded or broken.

Every instance of an Ampersand-powered integration has two main attributes, the customer and the integration source (or provider, a term we switched to later).

Early on, I designed the builder dashboard with both customer-centric and provider-centric views. Both are equally valid representations of the architecture, but Lauren and I realized it was wise for us to choose one view to start with in order to conserve resources, and we decided to go with the provider-centric view.

Many edge cases

While we started in the concept phase with a UI library that was optimized for an average use case of an integration with Salesforce, a few standard objects and a few typical fields, we found that some early customers had very unique requirements.

• Example 1: Lots of objects

• Example 2: Lots of optional fields

• Example 3: Lots of field mappings

• Example 4: Lots of permissions/actions (read, update, subscribe)

• Example 5: Lots of no-config objects

• Example 6: A single UI for first-run and later-runs

• Example 7: Turning off objects later

• Example 8: Changing auth later

As I discovered each new use case, I adjusted the UI library to support it while also keeping in mind the holistic experience.

Self-serve as differentiator

From the beginning, we had conviction that self-serve would be a differentiator. Most other integration platforms in the space required going through a sales process, and Ampersand is uniquely positioned to appeal to developers who often prefer to try it out without talking to sales.

After designing a few variations of our onboarding, I ran a research study with 8 developers who fit our ICP. The participants started from our marketing page and were given some free time to learn about the platform and set things up.

From the study, I found weaknesses in developers' understanding of certain concepts as well as why certain setup steps we needed. This led to us renaming certain things and putting more emphasis on communicating certain ideas in our marketing and documentation pages.

While I work on the next iteration of in-product guidance, we found that adjusting docs was very helpful in helping developers get up to speed while allowing us to save time compared to building an in-product onboarding experience.

The right amount of scalability

Having worked in IAM at New Relic, my experience guided the team in setting up an IAM architecture that was scalable, with an organization and projects, as well as a roadmap for future objects like teams that would scaffold into the architecture.

Additionally, I set up a design system based on Simple UI and implemented primitive and semantic tokens so that both design and front-end workflows are more efficient and consistent.

Marketing site

Rather than hiring an agency to work on the marketing site, I designed it from scratch in-house, and managed contract developers who implemented it in Astro. All content is tracked via Github and composed with Markdown. The benefit is a site that we can iterate on over time.