©2020 Built with love by Nick Howland.

Salesforce1 Action System

Salesforce1 Action System

Contextual actions. Immediately visible. Easily understood.

Role: Product Designer / Lead Visual + UX Designer

Deliverables: Final Visual Designs, UI Specs, Interaction Specs, Interactive Prototype, Usability Reviews

Project Overview


For many apps, actions play a key role with engagement. This is certainly true for Salesforce1. Creation and editing of data leads to higher engagement which leads to user retention. As part of the Global Navigation Redesign of the Salesforce1 app, the action system, it’s placement, and visual treatment needed to be re-evaluated.

Salesforce 1 is a behemoth application and is our flagship mobile Sales app for the company. It’s focus was on data consumption. Users could find any of their records, which are used to capture and organize business data, and reference them while on the go. The creation portion of the app proved to be too cumbersome and confusing, so many users opted to create and edit strictly on the desktop application.

Because of this unused feature, we saw engagement drop as well as user retention drop. As as Salesforce1 user, if you could easily create and edit records on desktop, why wouldn’t you just do everything on desktop?

A new white-labeled version of Salesforce1 was also in the works, called mySalesforce. This app allowed companies to truly “harness the power of the platform” and create customized and branded applications that they could deploy to the app store. This was also a paid experience, unlike the free Salesforce1 app. With the future of our flagship app about to expand into uncharted territories, we needed to ensure that once we got users into the app, they would stay.

In order to promote creation and editing while on the go, increase engagement and retention, prepare the app for mySalesforce, and fit within the new Global Nav architecture, we needed to fix the action system.

Determining Our Scope

Due to the placement of the persistent tab navigation bar introduced in the Global Nav redesign, the action system, which resided in the footer area on most pages in the previous design, was displaced. This posed a visual challenge, but quickly introduced fundamental questions about the current approach.

To add complexity, there were seemingly endless technical constraints. As we started considering alternatives, we were quickly reminded that we were working within an enterprise environment where the actions needed to scale, and can be customized and added by customers and partners. This meant that any number of actions could be present within an the application. At times, all of these requirements were daunting, especially when comparing the app to single-purpose consumer apps with only a handful of actions.


We took a step back and started by understanding the current and previous action systems, how they worked, how they came to be and why. We conducted interviews with internal design, product and engineering stakeholders who had worked on those projects. Next, we began evaluating the usage data on the current model, which showed that only 21% of users took action in the app. We performed a competitive analysis of complex action models to see what else was in the market and we interviewed users on the effectiveness of the current Salesforce1 model.

Creating Comfortable Perimeters

At Salesforce we have our primary design principles (Clarity, Efficiency, Consistency, Beauty), which work great as overarching guidelines but sometimes more specific perimeters are needed. For the action system, we needed something that focused on the specific needs of the project at hand. Through an initial brainstorm and a few group discussions, we came up with a list of 5 principles that kept in mind the scope of Salesforce1 and it’s occasional unique needs, the needs of the platform, and the possibility of other apps using it within the Salesforce app portfolio. These principles helped guide the initial sketches and visual explorations, helped us in making decisions with stakeholders, and helped strengthen the stories we presented to our executives.

Action System Principles

1. Visibility: Know that I can take actions.

2. Clarity: Know what kind of action I am taking. 

3. Location: Understand contextual nature of actions.

4. Understand: Encourage taking actions.

5. Support: Gestures are always redundant with visual UI.


Iterate, Iterate, Iterate

Taking all of this into account we began generating low fidelity concepts and rapidly testing them with users. We did an audit of current action system patterns that are available in major applications and Salesforec application and created a deck of them, grouping them into different categories. With these categories (visible groups, thumb friendly, gestural, etc), we set out producing simple sketches and eventual hi-fidelity mockups of action systems guided by these design groups.

User Testing

After finalizing two action system directions via many iterations and numerous, smaller scale onsite user tests, we set up a full week of user testing sessions both in the Bay Area and in Dallas, Texas. Spreading out research across the country helped us better our broader user base. The directions we tested included a universal action button that floated above the surface of the screen and, when tapped, displayed all the actions within a simple icon and text based vertical action sheet (a variant on the FAB); and a horizontal bar of three exposed actions and one “more” overflow, all displayed as icons with text labels, that would slide under the header when the user scrolled down the page and would reappear if the user scrolled back up the page.


We quickly found that users rapidly failed when they were not presented with an obvious set of actions that were clearly visible. Some people even got frustrated when we prompted them to take an action and they couldn’t find a way to do it within a few seconds. The end result was a landslide user preference of the second option, the visible horizontal bar of four actions, over the large circular button that hid all actions behind it. Our hypothesis that a list of exposed and clearly labeled actions both performed better, were much more clear, and proved to be much more engaging.


  • If you want people to use the system, show them how.

    Mattron U.
    Mattron U.

Finalizing The System

To further improve clarity on the preferred direction, we adjusted the designs slightly by moving the action system from hiding and reappearing at the top to being nested underneath the page title within the page anchor. This helped increase the contextual nature of the actions, since the actions presented are unique to the page itself, by providing a clearer visual connection with what they are taking action on.

This helped us arrive at a system that is easy to find, provides context for use, is engaging, and works within the redesigned app layout. Our final design is a clearly visible action bar that promotes its contextual nature. We believe this user intent guided approach strikes a good balance between clarity of use and engagement.

Just because the project was getting ready to ship didn’t mean we were done. As I worked with my engineers to ensure that we were developing the product correctly as a team, we also created a list of metrics and future explorations to continue pushing the project forward past this initial release.


  • Engagement – One of our main goals was to increase engagement. Through usage data we can see if providing a clear and easy to understand action system promoted engagement.
  • MAU Increase – One of metrics we use to measure the success and health of the overall app is the number of Monthly Active Users. We would know if the new action system is successful if this overall number increases.
  • Increased creation of records – We would know that the new action system was performing well if we saw an uptick in new records being created.


  • Bucketed action locations – We need to acknowledge that there are different access points and levels to the Salesforce1 app. There are areas that are more global, like the landing page, and areas that are more context-based. Our action system needs to be flexible and fit these use cases.
  • Explore scroll states – this update doesn’t take into consideration a page scrolling. We could couple this clear action system with a thumb friendly access point when the user scrolls the page.


Ryan Spohn – Mobile Team Manager
Aran Rhee – Desktop Designer
Dan McCall – Project Manager

Other Projects