This team was comprised mostly of back end engineers, with one acting PM and then myself as the designer. I took on the following roles to help bring this feature to life.
We faced an interesting problem here where we had no front end resources dedicated to the project, so we had to tackle it creatively to ensure we were able to ship quickly. This led to us relying heavily on the design system that myself and two other engineers had previously put together.
Setting up a CRM integration to our platform is a critical step to customers getting value from our tools, and increases the likelihood of them staying sticky to the product.
We conducted churn research across customers and learned that the setup and onboarding process for the integrating CRMs was difficult or perceived as very technical, and was causing a lot of unhappiness and frustration with our customers.
Our mission was to streamline this set up to make it easier for users to integrate and hit the ground running with their work.
.png)
We began by reviewing all the responses from the churn research to drill down into key issues that were making the integration seem difficult.
We quickly realized that these responses were vague, partly due to there being several areas of discussion in each interview, with integrations only being one of them.
The responses indicated more of a perceived difficulty rather than an experienced one, so we decided we needed to do a deeper dive with our customer base and hone in on integrations specifically.
.png)
Participants were asked a range of questions such as:
We have two Figma files for this project, one for explorations and one for final component deliverables that designers and engineers could actively use. Each component went through the stages of research, exploration, refinement and dev ready, This was reflected in both the Asana board and our Figma exploration file.
When we completed a component, it was moved into our final design system file and turned into a Figma master component and heavily annotated. Every time a component was completed on our end and moved into dev ready in Asana, a message was triggered in Slack to alert the engineering team that a component was ready. Each Asana ticket was set up to have the link to the page in the exploratory file and the frame in the final design system file.
The set up was not hard, in fact it was “deceptively simple.”
Customers were running into issues where they thought they were set up, but then the syncs would never work.
The error emails were confusing and only indicated what had failed, not what had caused it - which was more often than not, a lack of correct permissions.
Troubleshooting the errors seemed like a daunting task - so they would ignore them for months until they reached out to support to resolve.
With these insights, our goal as a team became to resolve the permission issues before they actually impacted any of the integration data. The feature that we decided to design to do this was a permission validation tool.
I went through a few rounds of iterations and user testing, below are some examples of that:
Pros:
Cons:
Pros:
Cons:
Pros:
Cons:
We found the most success in testing with Exploration 2, and were able to find a good solution to alert users to verify their permissions neatly to bring them back to this page.
Overall we found that the screens with the dark blue top navigation performed better than the rest, showing faster wayfinding times in two out of three categories. In reviewing all three concepts with the participants, the idea of a clear information hierarchy came through a lot with the blue top navigation, showing that it was easier to separate the working area from the navigation area because of the stark color contrast.
We need to incorporate the results of the above testing and update our navigation items across the products. We’ve also begun to map out what shapes a product identity and how it ties into elements such as branding, voice, personality, etc., and understand which of the adjectives from our study might be more relevant to which of our personas. Our next step is to finalize what voice we are working towards and identify which of our components could be affected by this.
System transparency was key - our existing layout was burying useful information, and with the new designs we both surfaced that more prominently and gave users immediate views into their current system status.
Design requirements
Features
Features
Features
Features
We need to incorporate the results of the above testing and update our navigation items across the products. We’ve also begun to map out what shapes a product identity and how it ties into elements such as branding, voice, personality, etc., and understand which of the adjectives from our study might be more relevant to which of our personas. Our next step is to finalize what voice we are working towards and identify which of our components could be affected by this.
“Overall, it’s been super useful for troubleshooting, both where a specific permission is missing that’s causing an issue in the sync, as well as being able to rule out a permissions issue for behavior we’re seeing if all of their permissions are in place.” - Customer quote
