Background
Salesforce is a cloud-based software platform offering tools to help businesses manage sales, customer service, marketing, and more. Users can analyze and visualize their data by creating and exploring customizable reports and dashboards, enabling insights to drive business goals, improve revenue, and manage expenses.
To create reports in Salesforce, the user starts with selecting a report type, which defines the objects, fields, and relationships included in the report. There are two main report types: Standard Report Types (predefined and uneditable) and Custom Report Types (created by admins for tailored needs). Custom Report Types (CRT) allow users to define object relationships and field selections, enabling up to four objects to be linked. Custom report types offer flexibility to build and adapt reports to specific business requirements. They provide capabilities that go beyond what standard report types offer. They enable users to create highly tailored and precise reports, ensuring that the data presented meets specific business requirements and insights.
Problem Statement
The Custom Report Type feature, designed over a decade ago, has remained unchanged since its initial creation. This outdated setup has drawn significant dissatisfaction from reporting customers, who have provided feedback pointing to issues with the user interface and editing flow. These concerns highlight the need for a modernized and more efficient setup experience to better meet user expectations.
“It's 2024. How and why is the Custom Report Type Editor UI still stuck in Classic? Yes, some retro video games are making a comeback nowadays (thanks, Nintendo!), but features being stuck in Classic shouldn't be a thing anymore...” - Customer 1
“The creation of a custom report is not that bad - it's editing existing custom reports to either add or remove fields that is very painful. And in some larger orgs there are hundreds of custom reports types tied to thousands of reports, so deleting and creating new custom reports is not an option.” - Customer 2
Goals & Objectives
This project aimed to address longstanding customer pain points by prioritizing immediate needs, including:
- Upgrading the UI from Salesforce’s Classic interface to the current Lightning Design System.
- Help our users quickly find the objects they are looking for on the Custom Report Types landing page.
- Introduce more context and details about the objects and object relationships throughout the custom report type creation process.
- Simplify the editing flows of the custom report type creation and editing process.
- Evaluate the overall design and flow of Custom Report Type (CRT) setup and creation experience.
The Team
1 Lead UX/UI Designer - 1 Product Manager - 1 CX writer - Five Engineers
Discovery
Though we already had strong signals from our customers about some pain points, we needed to dig deeper to better understand and prioritize the areas we should focus on.
The PM and I conducted six 30-minute customer calls to hear directly from some of our customers about the pain points. The customers shared their screens as they described and showed how they are using the product today. We were able to observe as they use the current experience and see first hand the areas that are the most challenging for our users.
Some of the current pain points:
Findability: Finding fields via lookup, which according to customers is the most powerful tool that this experience provides them as content creators, is currently buried on the side and is not discoverable.
Scalability: With the continued adding of objects into custom report types, the object lists can become very long and tedious to sift through.
Editing: It is very hard, cumbersome and time-consuming to edit a custom report type once you created one.
Usability issues: The “edit layout” section is the most time consuming and complex part of the CRT creation flow and can be tedious. Getting the report type down to where you want it, taking the fields that you want to show by default, the drag & drop experience: all that takes a lot of steps!
Outdated design and UX: Customers expressed a much desired facelift of the experience as a whole.
Initial Design Explorations
The solution was to design, build and maintain a Slack Integration Platform that would enable feature teams at Tableau to build integrations that would require bidirectional communication between Slack and Tableau. The Slack Integration Platform enables Tableau developers to build integration features with Slack, easily, at scale.
From a UX perspective, we delivered quite a few UX and Design artifacts to support this Slack Integration Platform effort. Some of these deliverables included:
From a UX perspective, we delivered quite a few UX and Design artifacts to support this Slack Integration Platform effort. Some of these deliverables included:
Slack Integration Use Cases and our Platform Working Model:
As the lead UX Designer of the core Slack Integration team, I led an exercise to identify the primary Slack Integration use cases and flows that I owned. These primary use cases are the foundational features and flows, they do not have any dependencies on each other; they stand on their own. These primary use cases will not have dead ends because they will be supported by the secondary use cases that different feature teams will design and build.
Tableau Slack Authentication Flow
One of the primary flows that my team (the core Tableau Slack Integration team) owned is the authentication flow. This is a foundational piece that provides the ability for Slack and Tableau to reach each other to send information and data. I worked closely with the authentication feature team (including their UX Designer) to map out the full end-to-end authentication flows. These flows had hand offs from Slack to Tableau and from Tableau back to Slack that needed to respect Tableau's permissioning and security models.
Notifications in Slack
One of our first deliverables on our roadmap to reach all people with data was to send different notification types to someone from the Tableau site to them in their Slack workspace. This makes it easier for an Analyst to distribute data and insights to the right groups and individuals in a timely and actionable manner. We enabled 3 different types of notifications in Slack: when someone is AtMentioned in a dashboard/view, when someone shared content with you, and for data driven alerts.
Link Unfurling
Another primary feature that we launched was to provide previews for shared links, or link unfurling. This is the default treatment for links posted into Slack. When a link is spotted, Slack crawls it and provides a simple preview. This preview provides people additional context of the shared link. Additionally, the link unfurling technology is foundational in Slack to support some of our other features such as previewing content in a search query in Slack.
Search Tableau Views and Workbooks in Slack
One of our research findings revealed that users want to search data assets in a single place. Creating a unified, in-context flow for engaging with analytics on desktop and mobile via Slack to find, access, and collaborate on different content types will drastically enhance our users' experience working with data and insights.
In order to allow our users to search Tableau content within Slack, we have to build a Public Search REST API that will meet the needs of developers building search experiences based upon Tableau content. This new API method will enable developers to query various Tableau Server resources, including workbooks and views, to meet the diverse needs of our end users.
With the Tableau Search in Slack, customers will be able to:
- Dig into known analytical content with confidence and speed.
- Discover content in a particular domain with ease and confidence.
- Users will be able to easily find a Tableau view from within Slack and share it with a channel or in Direct Message
- Developers will be able to build experiences that support the analytical content search needs of the portal or application they own or are developing for.
What's Next
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).