Automation Reliability
The Salesforce Authenticator App is unique in that it can automate requests for its users.
For this project we worked to make the language surrounding automation more understandable. We also implemented strategic design choices throughout the app to help our users understand why an automation succeeded or failed.
My Role
Product Designer
Teammates
1PM + 1CX + 1 Eng Manager + 6 Engineers
Value Add
A better explanation of automation throughout the tour to allow for a better understanding of how we automate, and therefore, more success in automating their trusted requests.
Impact
More successful automations for our 1M Android and 1.9M iOS users.
The Kickoff
To Kickoff this project, I met with my Product Manager and CX partner. For this project to be successful, we needed very good CX. This is because we needed to communicate how automations work and why they fail throughout the app to improve the automation rate.
​
For our initial meeting, I pulled screens where the most impact could be made. I shared design ideas and areas where CX could have the most impact as well. I created a space within our Figma file for CX to work along side the design. This way, we had a single source of truth for our project.
​
We met with the Dev team after this and discussed how we should communicate. This team likes to communicate via Slack. Because of this, we did a lot of updating via Slack and met only when necessary.
The Problem
The Salesforce Authenticator App (SFA) can automatically approve trusted requests. In order to automate a request, SFA considers 5 data points in determining to automate a request. However, we call it Location Services. This is confusing to the user and frustrating. They don't understand why they cannot be automatically approved when they are in the same, trusted location.
The Details
The 5 factors used when approving a request:
​
-
Service (Aloha.my.salesforce.com)
-
Action (Log in)
-
User (Test@salesforce.com)
-
Location (Phone's proximity to a physical location at the time the request is received)
-
Terminal (Chrome on Mac)S)
The Terminology
The language is confusing. There needs to be consistent usage of the 5 data points with the same language throughout the app.
My Process
Discovery:
In order to fully empathize with the user's of the Salesforce Authenticator App (SFA), I needed to download and use it. I did this, and made sure to document my journey with automations. I understood the frustration when an automation didn't work and a user didn't know why. You could be in the same location, and one of the 5 factors may not be met, and you'd have to manually approve a request and not know why.
I also looked over the app feedback in the App Store. Automations were a hot topic, and it was not a positive one. I looked through the literature available to our users in the Knowledge Base, and it didn't explain why this could be happening. If we could educate our users as to why, they would be able to troubleshoot, or understand why it might not have worked in one instance.
​
After this discovery work, I audited the app and pulled together the areas that could be causing pain for our users. I also added in design and CX recommendations for the greatest impact. Below is the deck I pulled together to present at our Demo Days for the Identity Org. The demo generated great feedback for our designs and created excitement for the improvements.
​
​
​
Research and Design Iterations:
We had a quick timeline for this project. We needed to get designs to the dev team within a few weeks. Because of this, my CX partner and I carried out Guerrilla Research. This allowed us to have rapid iterations within our short design cycle.
​
​
​
​
​
Accessibility
​
The Salesforce Authenticator App was built before the Salesforce Lightning Design System was built. Because of this, we have to keep accessibility in mind when we're designing. With our quick turnaround for this project, we did not make it to Accessibility Office Hours. However, I did make sure to check our colors in the WEBAIM Contrast Checker. Also, my CX partner made sure our text was tagged correctly for assistive technology. In our next release, we are making sure to support multiple text sizes within the app as well.
​
Hand-off
A benefit of designing for a pre-existing app is that the components, colors, spacing, and other design tokens and patterns were already set. This made hand-off a lot smoother. The dev team was able to use my figma file. They could inspect designs, walk through flows, leave comments, and see the CX labels and text.
​
