[Tableau — Set and Parameter actions]
Detangling the complexity
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.
Just a bug?
This clearly was just a prioritization issue. Parameters are used often to create calculations and interactive dashboards in Tableau. The UI allows you to create a parameter from the field. It sets up the expectation that the values of the parameter are tied to the values of the field. When the field updates, and the parameter values don't, that feels like a bug. It seems like we should just add it to the backlog and get it into the pipeline.
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. There was no simple obvious fix.
Another level deeper.
Customers were asking for a specific feature, and we had zoomed in on the details to no avail. But, with a quick shift of perspective, we decided to focus on what the underlying goal was.
After some conversations, post-it notes, and affinity diagramming, we were able to distill it into 4 key scenarios: essentially performance, cohort analysis, reporting scenarios, and dashboard as an app. Those key scenarios all boiled down to the need of building a dashboard with interactive analytics driven by selecting data, that went beyond just filtering the query.
The forgotten feature.
Sets, history of sets, can't change on a published viz, half implemented, never used. But conceptually, perfect for what we want. Someone seeing my selection prototypes suggesting that that looks like sets. Ease the burden of parameters as the junk drawer of features and make sets shine with their potential.
The hype.
Not just a feature request to deliver — a whole new potential area of investment. Show sets vision.
The results.
List of features shipped, and customer feedback in terms of tweets, etc.
The 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.