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
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.