Salesforce App Favorites Feature
A globally accessible, personalized way of getting to what you need. Lightning fast.
Role: Product Designer / Lead Visual + UX Designer / Researcher
Deliverables: Final Visual Designs, Multiple Prototypes, Visual Specs, Interaction Specs, Lead User Research Sessions
Navigation within the Salesforce app has been the same since it was released in 2003. Users navigate the behemoth of an enterprise app through stage left, which lists each page within the app; from records to custom built apps and settings. The issue, which many users had voiced complaints about, was that the stage left icon wasn’t persistent. The icon would quickly get buried under various pages within the history stack as a user drilled into various pages, which makes navigating the app cumbersome and difficult.
A Global And Contextual Solution
In addition to users voicing difficulty with navigation, they also voiced a need for personalizing their experience within the app. Not everyone navigates through the Salesforce App the same way or frequents the same items, so why should the navigation model be the same for everyone?
Favorites is our solution to both problems. The feature allows users to add records, lists, and custom pages to a curated, globally accessible list. This list can also be personalized by the user, allowing people to reorder items and remove items however they see fit. Because the feature was built with a core API, it syncs across all devices and platforms including desktop, tablet, and phone.
PM preferred direction
Nests the list access point within Stage Left and separates it from the action.
UX preferred direction
The list and actions are globally accessible from anywhere within the app.
During the iteration phase, I ran multiple research sessions parallel to the design efforts. These sessions ranged from concept validation to usability studies. After a few rounds of iterating, we narrowed down the options to two distinct directions. The first option opted for placing an icon in the header, which users could toggle for adding and removing items, and placing the list in another location. The second option favored a brand new UI metaphor: the star icon within the header gives access to both the list itself and a control to add / remove items from the list, all within a half sheet that maintains context.
Testing proved our hypothesis that users would prefer a globally accessible option to one that once again buried items within Stage Left. But our PMs didn’t agree. They largely didn’t think it was worthwhile to build an entirely new UX, compared to using items already within our design system or out of the box, and they also didn’t think their engineers could actually handle the task.
I set out on a path to make a case for our users, via numerous meetings including some skip-level, with an additional goal of improving relationships between UX and our engineering counterparts. This was done through meeting more regularly with my scrum team to discuss design progress, including engineers in planning discussions, hosting weekly office hours meetings to ensure we were making progress and that I could answer any questions that came up, and drastically improving our documentation method. Previous to this project, specs largely lived within PDFs or Zeplin but didn’t include interaction specs or detailed descriptions on functionality all in one central place.
To fix this and set my team up further for success, I constructed an additional process for specs: creating a spec deck. The spec deck houses not just static screens and descriptions, but also interaction specs and gifs to illustrate them, reference links to things like Zeplin specs or prototypes, asset links, and detailed accessibility notes. While using these new materials, my engineering teams were able to build the feature ahead of schedule with a minimal amount of errors or questions. We also began using the speck deck as a templated system for other designers within UX as well.
Kyle Haskins – Mobile Team Manager
Aran Rhee – Desktop Designer