Defining UX for a new API
Bringing the new Tableau Extension API from concept to launch.
The Challenge
At the beginning of this project, the team had a proof of concept, showing that extensions could be placed inside a Tableau Dashboard. This had the potential to be a game changer. It would allow users to add developer-created extensions that could interact with data from other applications directly in Tableau.
The Developer Platform team had never needed to integrate their work into the product before - previous extensibility features lived on the web.
THE USER EXPERIENCE AROUND APIs WAS NON-EXISTENT. TABLEAU’S OTHER APIs WERE GEARED TOWARDS POWER USERS AND DEVELOPERS, WHICH MADE IT DIFFICULT FOR CASUAL USERS TO DISCOVER AND ADOPT.
With a proof of concept already made, the team was locked into that existing implementation method. This framework had clear UX implications that we needed to work with.
My Role
I created a consistent set of experiences and flows around the new extension API. New extension workflows needed to blend seamlessly with existing Tableau features. This empowered our customers to explore the new extensions functionality, and ultimately helped them do more with Tableau.
Exploratory Research
Our Users
I divided our users into groups based on their permission levels within Tableau. Extensions were presented to users from each role - as a concept with some working wire-frame prototypes. These interviews helped us distill some of the most important qualities of the extensions feature for each user - shown below.
Developer
Creates Extensions
Is able to make their extension feel like a first-class experience.
Needs guidance around UX best practices.
Analyst
Builds Dashboards
It's easy to find and use an extension for their goals.
Is able to configure the extension to match the look and feel of the current workbook.
Won't use an extension if it has a high barrier to entry.
Interactor
Views Dashboards
Can use their workbook and understand their data.
Doesn’t necessarily need to know that a workbook zone is an extension.
Admin
Manages Permissions
Needs information about extension requests so that they can make the right decisions.
Has final say over what extensions can and cannot be used on their Tableau company site.
Our Business
To understand our business and technical goals, I conducted a brainstorming and prioritization workshop with the development and PM team.
I used a Must, Should, Could, Won’t prioritization technique with members of the Developer Platform team. This helped me uncover their intial assumptions regarding the implementation and functionality needed for this project.
This type of meeting is great because it pushes people out of their comfort zones.
Story Mapping and Prioritization
I used a story map to visually group the user stories from our user research and team workshops into sets of functionality that made a coherent user experience.
Story mapping is my jam. Bonus points if you can find the captain hammer t-shirt!
Key Objectives
I used the decisions from our story mapping work to distill all of our user needs into a concise set of objectives that drove the teams work for the first release of the Extension API.
01
The entry point must be discoverable
Since extensions were a new feature, I wanted to make sure the entry point was in a discoverable location, but didn't distract from other goals. I sketched out a few options that we considered as a team.
We landed on the Objects Pane entry point for a few reasons
The Objects Pane is always visible when users are creating a dashboard
This meant that the extension entry point would also be visible, rather than hidden in a menu somewhere.
The Objects Pane already existed as a way to add objects to dashboards
Users were already familiar with the existing Objects Pane, and knew how to use it.
Some of our other ideas felt too heavy-handed for a brand new feature
I knew that the first version of extensions would have limited functionality, making these options feel mismatched. We kept these entry points in our back pocket for future releases.
Dragging an extension into the dashboard from the Objects pane
02
Extensions fit into the existing Tableau ecosystem
I needed to ensure that all functionality related to Extensions fit the current Tableau style and UX. I created a series of IA diagrams which mapped out the possible user flows and surfaces touched in each flow.
IA diagrams were used to ensure that edge-case flows were accounted for.
A few UX surfaces were created in this work, including the following:
The About Extension Dialog gives users information about an extension already in a workbook. This image shows where in the extension manifest file Tableau pulls each piece of information from.
I decided to give "Extension Gallery" and "My Extensions" equal weight in this dialog to boost the visibility of the gallery.
03
Users are empowered to make decisions about their data security
Our users needed to know what level of data access extensions were requesting, and they needed to deny that extension access to their data if they did not trust it.
The following dialogs let users manage their data security:
The Add Extension dialog lets analysts decide what extensions to give access to when they are added to a workbook.
The Allow Extensions dialog informs interactors about extensions in their workbook and lets them choose whether they should run or not.
04
Admins have final say over what extensions are allowed on their server
Our Administrators needed final say over what was and was not allowed on their Tableau Server.
We decided that by default, Tableau should allow extensios on a Tableau Site, but Admins need to whitelist them after getting requests from their users.
The Administrator Security Page allows our admins to disable all extensions, or enable specific ones. It also allows them to choose which extensions they'd like their users to vet on a case-by-case basis.
05
Developers have guidance to create consistent UX
Our developers told us that they wanted to make their extensions look and feel like they belong in Tableau. I mentored a talented summer intern - Josephine Le - while she put together an online UX Guide for Extensions
Some highlights of her work are shown below:
Developers need to decide if their extension will have a configuration dialog. (Image by Josephine Le)
This shows the anatomy of a typical Configure Extension Dialog that a developer might create to allow their users to customize the extension. (Image by Josephine Le)
Final Assets
I created our final assets and redlines. I worked with the development team to get these into the product, and make small changes based on implementation constraints.
Some of the final assets that were created as part of the work on the Extensions API
The flow to add an extension to a Tableau Dashboard.
Reflections
I believe that good design helps users focus on their goals without getting in the way. The work I did on this project cemented this belief.
I worked with my team to make a variety of tradeoffs in order to ship a coherent and holistic experience for all of our users. For example, after hearing concerns about data security, we chose to prioritize communication about data security over a more interesting design to add an extension to a dashboard.
Effectively, this meant I put a lot more effort into dialog boxes and pages to display information than stereotypically interesting UX. While this type of work can feel thankless or unimportant, it can make or break a product.
