Background
Salesforce, a cloud-based CRM software that allows our customers to unite their sales, service, marketing, commerce and IT teams all in a single shared view of their customer information.
With every Salesforce license, Salesforce provides analytics capabilities via reports and dashboards: this is an easy way to analyze data by anybody with a Salesforce license. This out-of-the-box capabilities is one of the most heavily used features in the platform with about 8M MAU and over 3B report runs per month.
Reports are basically the “go to” option for quick reporting on real-time data, built natively inside SF core. Customers can also build dashboards that are based on these reports to show a snapshot of data at the runtime.
In 2023, Salesforce launched Data Cloud, which is like a datalake that allows customers to pull data from any system in real time, an open and extensible data platform. Data Cloud allows organizations to seamlessly integrate external data with their Salesforce CRM data, ensuring they have unified, real-time and relevant information about their customers. This a foundational add to the system on which the whole Salesforce platform sits on. It makes it easier and faster to combine, shape, and clean data for analysis within Salesforce. Salesforce has built a semantic layer on top of this Data Cloud that allows customers to bring meaning to their data by creating relationships between the different datasets that they can then view and analyze.
Opportunity:
With the introduction of Data Cloud, we had the need to extend our reporting capabilities to the new Data Cloud and with that we had an opportunity not only to extend the familiar and intuitive experience of reporting into Data Cloud, but we also took this opportunity to revisit and rethink several known pain points about the existing reporting experience.
Current Reporting Experience
Existing studies showed that the current reporting experience is user friendly and non-technical.
People appreciate being able to report on live data in almost real-time.
Most people use the same handful of reports over and over and they wanted a quick way to get to their most frequently used reports.
Existing Reporting Experience
Pain Points
Though reports are easy to consume there are some known pain points:
Proliferation of reports: Too many (often manual) reports are created and shared, cluttering users workflows. Users fear to edit/filter reports to their needs, so they make duplicates.
Report Builder: Building reports is a trial and error process: Training helps, but is not readily available. Easy to train 5-6 people, but hard to do train many people. Untrained users are afraid to click the Create button.
Customers (especially Business Users) are not necessarily focused on where the data is coming from: This is a challenge as we introduce Data Cloud and the complexity of multiple data sources and the semantic layer that is built on top of Data Cloud.
Challenges:
Just like any other project, I found myself having to face a few challenges throughout this project:
I was brand new to Salesforce: As a new designer at Salesforce, I had to jump in and start swimming! Everything was new. There were some advantages to being a newbie as I was bringing a new perspective, where I wasn’t biased to any existing solutions.
Limited Resources: working through layoffs so limited resources (no researcher to work with)
Data Cloud: Data Cloud was a brand new offering from Salesforce and is a concept that is a foundational change in the Salesforce platform and we had to figure everything out as we go. At times it felt like we were flying the plane as we were building it!
Urgency: We had to move very fast on this project yet we wanted to make sure that we don’t make any decisions that would block us down the road.
Define Requirements: Personas and Jobs To Be Done
The requirements were pretty fuzzy during the early stages of the project. There was a lot of confusion and questions around the new Data Cloud and what it means, how it would be architected and developed and how we would integrate into Data Cloud.
Myself and the other designer leveraged Design methods and process such as workshops, How Might We’s, research methods to lead strategic and tactical discussions with the cross-functional team to identify the personas, the jobs to be done, the business needs and define the roadmap.
We spent a lot of time during those first few weeks workshopping through some of our discovery and existing research, talking to stakeholders, identifying dependencies from other teams. The engineering team spiked on a few things.
As part of our planning sessions:
- We reviewed and aligned on personas and Jobs to be done,
- We worked through existing research and known customer pain points,
- We discussed the roadmap for Data Cloud Reporting and agreed that we would have a multi-release approach, especially since we had a lot of dependencies on other teams.
There are 2 main personas we were looking at: The business user and the data analyst and how they create and use reports. We also wanted to make sure that we include the Salesforce Admin, who is responsible for managing the system as a whole and is responsible for things like configurations and permissionning. But beyond personas, we were looking at the jobs to be done for each persona.
We identified the main Jobs to be Done (JTBD) in the analysis and report creation process and identified which JTBD relates to which persona:
Jobs to Be Done per Persona
We also relied on a lot of the existing research findings we had. I took the time to consolidate a lot of the research findings, create some affinity mapping. We spent a lot of time thinking through the complexities that would appear for our end users with the introduction of Data Cloud:
An example: A big part of Data cloud was the Semantic Layer that was being built on top of Data Cloud. This semantic layer powers the analytical experience by giving meaning to data. Analysts can build data models within the semantic layer that data cloud reporting can pull from. There could be single object reporting or multi-object reporting. These are complex notions of data that we are presenting to the end users and we want to make sure that we are designing in a way where we don't expose these complexities to the user in a way that it hinders them from being able to create their reports.
How Might We
From the affinity mapping exercises I came up with HMWs to guide my design explorations
Design Principles
We identified three Design Principles to guide our work:
1. Familiar: Do not fix what is not broken and what 8 million reports users are familiar with. Instead, incrementally layer intentional and meaningful user experience improvements.
2. Augmented: Create unique user value by connecting reports to the best of Salesforce. By considering semantics, insights, predictions and automations we connect our users closer to their data.
3. Easy: Remove hurdles by guiding users through complex tasks and offering seamless transitions across tasks. The report experience should lower the time to first moment of value.
Design Explorations
We were 2 designers on this project and my focus area was the engagement and report creation entry point.
A big part of that first mile of report creation is choosing report types when starting a new report. Report types are data templates from which Business Users can create reports. They are the doorway into reporting. These are templates that automatically define the objects included in a report, as well as how those objects are related, and specifically which fields can be pulled in.
The report types are created by the data professionals and admins and consumed by the Business Users. It includes things like basic metadata like name, description but also data models that describes the objects and fields that will be available in the report. It also has things like default layouts for th report, etc.,
With the introduction of Data Cloud, we were concerned about the report types experience becoming even more complex because the semantic data models created in Data Cloud are themselves a form of custom report type of sorts. However, they are built and managed in data cloud, rather than Salesforce Setup and we were concerned about scalability issues as more and more report types would be added.
I started exploring different ways of allowing the user to leverage report types, templates and other mechanisms to define the objects and fields to be used for their report. I looked at different flows of choosing the objects and fields for the new report: from leveraging the existing report types but adding some additional more visual (layout) templates to breaking out the process into multiple steps To exploring leveraging chat gpt, where I pivoted from the intent of the user of creating a new report to the intent of getting an answer to a question.
** This work took place in Jan-March 2023 right when Chat GPT was being introduced to mainstream usage so this is very initial thinking around Chat GPT.
** This work took place in Jan-March 2023 right when Chat GPT was being introduced to mainstream usage so this is very initial thinking around Chat GPT.
Additional Design Explorations
I also had to explore how we present Data Cloud vs Salesforce native report types on the page.
Data Cloud’s semantic layer allows analysts to create report types for their end users that are made of single or multiple objects. We wanted to make sure that our customers are not confused with the introduction of Data Cloud report types and that they are able to easily choose their report types.
I continued to explore different directions for the Data Cloud report type integration: from an option where user is presented with the Data Cloud content by default and is separated from the native Salesforce report types. In this option the customer can toggle back and forth between Data Cloud report types and Salesofrce Report Types.
Additional filtering and search would be available for quick discovery and findability of desired content.
Data Cloud’s semantic layer allows analysts to create report types for their end users that are made of single or multiple objects. We wanted to make sure that our customers are not confused with the introduction of Data Cloud report types and that they are able to easily choose their report types.
I continued to explore different directions for the Data Cloud report type integration: from an option where user is presented with the Data Cloud content by default and is separated from the native Salesforce report types. In this option the customer can toggle back and forth between Data Cloud report types and Salesofrce Report Types.
Additional filtering and search would be available for quick discovery and findability of desired content.
I also looked at what the experience would be like if we presented mixed content: where Data Cloud and native Salesforce report types are presented to the customer together. In this option the customer lands on a sort of landing experience with mixed content. Their most recently used report types are displayed up top, making it easy for them to access these templates on a regular basis. We know from our customers that they tend to use the same handful of report types when creating most of their reports. They can filter the content down to just Data Cloud or native Salesforce report types.
I also looked at forking the experience right from the get go: customer opts to create a new report, they land on the modal, asking them upfront what kind of report are they creating: a Data Cloud report or a native Salesforce report type.
Customer Feedback and Design Validation
We wanted to get some initial customer feedback. We didn’t have a dedicated researcher on our team. The PM, the other designer and myself conducted a study with 6 customers to get some of their initial thoughts.
Overall, the majority agreed that most people don’t know what Data Cloud is and therefore they need to have sufficient information to understand the difference. Participants also argued that the majority of the end users (Business Users) don’t really care what the data source is (Data Cloud or not) and therefore there is no need to distinguish between the two because it would just create confusion.
The majority of participants appreciated that the experience was familiar and stayed similar to the existing experience.
Overall, the majority agreed that most people don’t know what Data Cloud is and therefore they need to have sufficient information to understand the difference. Participants also argued that the majority of the end users (Business Users) don’t really care what the data source is (Data Cloud or not) and therefore there is no need to distinguish between the two because it would just create confusion.
The majority of participants appreciated that the experience was familiar and stayed similar to the existing experience.
Customer calls to validate our designs
Final Designs
After delivering the Northstar and these foundational experiences for Tableau Integration in Slack, I moved to another team and no longer worked on Slack Integration work. Before leaving the team, I did start working on some of the next features that were on our roadmap such as sending subscriptions to channels and individuals, continuing to to refine the working model between the core Slack Integration team and all feature teams working on Slack Integration as well as continued Northstar work (as part of a UX design team that was spun up to evaluate how to engage Business Users with bite-size data insights in their workflow).
