Sales Cloud Mobile Forecasting
What I Did
As the only product designer, I sketched potential solutions, developed wireframes, and designed high-fidelity mockups. I worked collaboratively with product designers, engineers, and product managers contributing significantly to moving this project forward and ensuring that it remained a priority for our team.
What is Forecasting?
Forecasting is a collaborative sales process of data entry and analysis that informs a company how much revenue they should expect for a sales period. Forecasting is such a critical part of the sales process because it allows companies to make more intelligent business decisions based on expected revenue.
Through research, I identified the following personas as being involved in the forecasting process:
My target users for the mobile forecasting design were the sales reps and managers because they input and want to update forecast data in the Salesforce mobile app.
Heuristic Evaluation
Forecasting on Desktop Today
Before kicking this project off, I needed to understand how forecasting works on the Sales Cloud desktop experience today. It’s a complicated feature, so I’ve called out the main elements below.
Note: throughout the description of this project, I’ll refer to “adjustments.” An “adjustment” is when a sales manager updates the value of a forecast. The adjustment, or update, only applies to the forecast and does not affect any of the underlying opportunities. Sales managers usually make adjustments based on a gut feeling rather than relying on data.
Forecasting on Mobile Today
After better understanding how forecasting work on desktop, I did evaluated the Salesforce mobile app. A consistent piece of feedback my product manager and I had been hearing from Salesforce sales executives and from our customers was it was not useful. Below was the state of forecasting on mobile when I took over the project:
The biggest pain points with the forecasting tool on mobile were:
Only available on Android, not iOS
Did not allow users to make adjustments to a forecast number
Only offered one simple view of the forecast when on desktop you could create multiple views based on team members or products
Project Kickoff and Alignment
To kickoff this project, I set up a whiteboarding session with the product manager and two lead engineers to align on what a minimum viable product would be and outline technical constraints.
Below is how we defined the MVP.
Design Explorations
Once we all had agreement on an MVP, I started exploring options that would allow users to make adjustments and change the time period or view. My goal was to a large quantity of ideas in an afternoon of work so I used my iPad to sketch allowing me to quickly iterate. I added these sketches into a slide deck and shared them with stakeholders to start gathering feedback.
WHAT WORKED
Having an edit button on the home screen of the forecast is most closely aligned to the Salesforce Lightning Design System and would be familiar to our users.
WHAT DIDN’T
The slide to reveal actions behavior shown in the first sketch is something that is used in some Salesforce mobile products, but is too closely associated with email. Seeing a swipe to reveal actions outside the context of email would be confusing and unintuitive to the user.
The hold and press to edit a value shown in the second sketch concerned would not be discoverable.
Salesforce Lightning Design System Explorations
After getting feedback on my sketches, I focused on creating higher fidelity wireframes as close to our Salesforce design system as possible.
What Didn’t Work
Following the Salesforce design system patterns wasn’t working for a few reasons:
The edit button was not in close proximity to the content it applies to.
The edit button was taking up too much real estate in an already small space on mobile.
A universal edit button would apply to the entire page, including your teammates’ forecasts, leaving too much room for user error.
Second Iteration
I recognized this was a time where I needed to diverge from the Salesforce design system, collaborating with other designers to create a new mobile pattern. Below is my first iteration at diverging from our own system in a way that would still make sense.
WHAT WORKED
In working closely with engineering, I discovered that from a technical perspective I could redesign the header to show the current time period. I added a gear icon to this header, the same icon we use on desktop, to change the time period and view.
The multi-select drill-down page is a design I pulled from the Salesforce design system and worked great for the user to select a view and period at the same time.
I removed the edit button from the home page and kept it on the drill-down page where you can see the list of opportunities related to a forecast category. I thought users could make adjustments (updates) to their forecast with the context of the opportunities on the same page. I used the pencil icon to edit, an icon our users are familiar with.
I redesigned the yellow flag used on our desktop app to a yellow bar on mobile. This is a flag indicating an adjustment or update has been made.
WHAT DIDN’T
Adding a gear icon to the header and removing the ability to edit on the home page meant discoverability would still be an issue for users. They would have to tap on a forecast category to see the pencil icon and edit a value, adding an extra step to the experience.
The yellow bar to indicate an adjustment had been made ended up being confusing to users. Using the exact same design as what they see on desktop would be the most straightforward.
Current Designs
I shared my designs in critiques and got some great feedback. From there, I made tweaks to the flow to address the discoverability. Below is a video of the latest designs.
WHAT WORKED
I made use of the header space so the user can change the view and the period they are looking at while also tapping on the pencil icon to make edits.
I kept the yellow triangle design to indicate a user is making an adjustment to remain consistent with the desktop experience and keep it streamlined for users.
WHAT DIDN’T
In this current design, users can’t make adjustments from the home screen, only on the drill-down screen so thinking through ways to add in this functionality without crowding the experience.
Users can’t see who made the last adjustment, so adding in some sort of history or log of that information on the drill-down screen.
Is there a more elegant way to allow the user to change period and type without having two drop-downs on top of each other?
Next Steps
Make changes outlined above to designs
Validate designs using a mobile prototype that users can tap through
Partner with engineering to implement this design in the next release cycle
Date September 2019 - April 2020