< Back to portfolio

Salesforce Plugin for a Data platform

Beauhurst, the company I work for, makes a SaaS platform which is also called Beauhurst, confusingly. Our subscribers use the platform to find high-growth and ambitious companies in the UK. They might want to find these companies to sell something to them, or to work with them, or they might be doing research into a certain industry.

A lot of our subscribers export the data they find on these companies out of the platform, and some of them load it into Salesforce. Because they're exporting to CSV, and then importing to Salesforce - or even worse, copying each field by hand - this is a slow process. It's not surprising that integration between Beauhurst and Salesforce was one of our most requested features.

As the only designer at Beauhurst, I needed to figure out how we could build a Salesforce integration that would help our subscribers get their work done.

Research

Beauhurst - the company, not the platform - does not use Salesforce, so we weren't familiar with it. To avoid making a lot of risky assumptions, I needed to become familiar with it.

I got in touch with every subscriber who had asked us if we had a Salesforce integration, to set up phone calls or face-to-face visits.

Each of the subscribers who wanted Salesforce integration might have wanted it for different reasons. To help with this, I started each interview by asking the subscriber what their business does, what they do within the business, and if they could run me through how they use Salesforce.

This helped in two ways: I better understood how Beauhurst might fight into their Salesforce workflow, and I understood more about Salesforce in general, which was very useful for the design process. What they wanted the plugin to do was less important - I wanted to find out what problems they were having that Salesforce integration could help with.

Using the notes I wrote at each interview, I could look for patterns in what our subscribers were saying. Here's a sample:

Research into user needs

Salesforce's "AppExchange" is a public marketplace of available Salesforce integration, showing screenshots for every plugin available. To understand how Beauhurst's plugin might work, and what our subscribers might expect, I looked at the Salesforce integration that our competitors offer. This was helpful - often with enterprise software it's not easy to see how your competitor's products work, unless you want to pay a lot of money in annual subscriptions.

The Salesforce AppExchange marketplace

Constraints

Regardless of what our subscribers told us, I was working with some limits:

Through my research I saw a way that we could take care of the second problem above: Some information could be copied directly into Salesforce. Any information that we didn't want to lose contorl of could be offered as a "view" into our platform. The data could be seen when they looked at a company in Salesforce, but it wouldn't be copied into any Salesforce fields.

Unfortunately this didn't help with subscribers who wanted to make that data more reportable, as I found during my research, since that requires that the data be copied into Salesforce's fields. This was a case of business reasons disagreeing with usability reasons.

Wireframes and specifications

I had an idea of how the plugin could work, but to make sure that we were all on the same page during discussions, I put together some simple wireframes that demonstrated how a subscriber might use our integration:

Wireframes for a Salesforce plugin

Once we had shared understanding, and had agreed on the approach, I wrote an early specifications document outlining what data should be offered, how the plugin should work, and what assumptions we were making, as well as risks we were taking.

First Specifications for the Salesforce plugin

Commercial options

I planned to finalise both the mockups and the specifications once we had finished our research into how Salesforce's platform and marketplace worked, which was difficult. Salesforce - the company - is almost impossible to contact, which meant we couldn't get quick answers to the questions we had. They offer a lot of documentation for developers and project managers, which is good, but it was hard to find what we were looking for.

This didn't just affect me, but also the developer assigned to the project, who was looking at its technical feasibility. He realised that we would need to invest a large amount of time into learning how the Salesforce platform worked before we could have a working prototype.

Conclusions

These unknowns and investments were enough of a financial risk that we decided to find help. I re-wrote the internal specification I had written earlier, so that it would explain more about how Beauhurst works, and could act as a starting point for explaining what we wanted to third parties. We reached out to a number of agencies which make Salesforce plugins for other companies, and reached an agreement with one of them. As of this writing, the third party is developing the first version of the plugin.

< Back to portfolio