[Tableau — Set and Parameter actions]
Delivering what was needed, not asked for
Dec 2017 - Dec 2018
Design is all about perspective. You have to solve problems at the right level.
Complexity shouldn't just be hidden under a toggle, hoping users don't find it. You need to truly understand where the complexity is coming from and what users actually care about.
The creative team.
Myself, a designer I was mentoring, and two product managers
Lenses.
The perspective you approach a problem with changes how you think about it. As a designer, I find it vital to jump between perspectives to understand the issue at the right level. An action item may come in at the feature level but may be best solved at the system level. Someone may have a workflow issue, but when you dig in, it is truly about the details, such as the UI strings that establish the wrong expectations and mental models for users. Throughout a single project, it's essential to understand your current perspective, how it could shift, and what that means about the underlying problem to solve.
For this project, what came in as a feature request ended up tracing back to fundamental challenges with how Tableau handles parameters and datasets. However, as we dug into the actual user needs, we learned a simpler feature could be a much better solution for their needs.
The process for building Set and Parameter actions started as a simple feature request, but as we ran into challenges, we had to revisit the goals and core system to find the best solution.
A simple request
Tableau has had parameters for a long time. Parameters can be created from the domain (or values) of a field. Users simply wanted 'dynamic parameters'. This meant that if the domain of the underlying field changed, they wanted the possible values for the parameter to update. The fact that it didn't felt like a bug to users.
Except it wasn't that easy. When I dug into the details, it turned out the expectations the UI created were all wrong. A parameter was essentially its own data source that could help define other data sources, and any sort of dependency on another data source would break down in either circular dependencies or complex logic we would have to create to prevent such cycles on update. The fix wasn't a simple.
Interactive Analytics was the underlying need
After many customer conversations, post=it notes and affinity diagrams, we distilled the users' needs to 4 key scenarios: essentially performance, cohort analysis, reporting scenarios, and dashboard as an app. To simplify even further, though, users needed to be able to build a dashboard where interactive analytics (beyond filtering) were driven by data selection.
One of my brainstorm sketches around how to improve the experience of selection in Tableau.
Sets, the forgotten feature
While exploring the concept of 'saved selections' for complex analytic flows, I came across the feature of Sets. Sets in Tableau were a feature creating based on a user request from years before I joined. As it added a simple boolean field do your data, it actually was the perfect feature to store selections. However, sets as a feature had never been fully developed, and weren't accessible at consume-time for dashboards. I dug into sets to understand and explore how they could support a better flow of analysis for our users.
My exploration and illustration of various analytic scenarios where Sets shine as a way to make a case for investing in the feature
A design exploration I created showing Sets as a shelf, and just-in-time UI on drag to support new analytic scenarios
Exploring the potential power of combining, nesting and calculating sets
An exploration on a potentially more visual and guided ways to create rich sets
Bringing the value to the customers
During a team brainstorm, we developed the idea to use actions to define sets and parameters. Not only did this bring the power of sets to dashboard consumers, it also allowed parameters to be driven directly by data at the moment of consumption, removing the need of the parameter to be dependent on a dataset. We worked with the developer team to quickly create prototypes of these concepts. I then helped create examples and demonstrate the value of these features to leadership until we made the case to adjust the roadmap and ship these features.
The feedback from customers were fabulous, and the applause at the next Tableau Conference was amazing. It felt great to ship features that our users loved.
A small selection of customer tweets about set and parameter actions.
After shipping Set and Parameter Actions, we continued to build on the momentum of Interactive Analytics. A developer team was refocused on Interactive Analytics, and were able to ship a number of additional features around sets and parameters.
Reflection
Systemic thinking allowed us to not just blindly build what the user asked for, but instead, create a whole new area of investment, built a series of features loved by the community that were often easier and cheaper to build. Early on during my career at Tableau, I remember a user chatting with me during a user session that he loved how Tableau again and again delivered what users actually needed, not what they asked for. It was at this moment where I felt like I had succeeded.