Alyshia Olsen

AO

Extending Tableau's Design System

Adding new Data Connector patterns and components to our Design System

The Challenge

When I joined the Connectivity team, Tableau was in the midst of a product-wide visual facelift, called unification. The unification efforts were generally understood internally, but the connectivity developers were a contracted team from Argentina, and did not have access to internal company resources.

As we worked together to implement new Data Connectors, I became frustrated with the level of detail my team needed from my redlines. This specificity had not been necessary when working with internal teams who were more familiar with the design language.

THE EXISTING VISUAL DESIGN PATTERNS WERE NOT PROVIDING ENOUGH CLARITY FOR OUR REMOTE DEVELOPERS.

Fortunately, the majority of our Data Connectors had the same set of components; the trouble was fitting them together appropriately. I decided to share the internal heuristics I knew by heart with my remote team, so that they could answer their own questions in ambiguous situations, and pull me in when appropriate.

Team

Connectivity

Deliverables

Design Guide for Connectors
New Widget Design
New Connector UX

Responsibilities

Design Lead
Visual Design

Timeline

January 2017 - May 2017

Team

Connectivity

Deliverables

Design Guide for Connectors, New widget Design, New Connector UX

Responsibilities

Design Lead, Visual Design

Timeline

January 2017 - May 2017

My Role

I worked with another designer (Ethan) to create visual guidelines tailored to the Tableau connectivity experience for our team to use. Together, we created a Data Connector Dialog pattern. Additionally, I worked on the visual and UX design for a new multi-select list view control to be used in our connectors. I also continued to work with the team, completing the UX for a few connectors that needed more design love.

A New Pattern

Ethan and I worked off of Visual Design's existing patterns to create an expanded set of guidelines that dealt explicitly with Connection Dialogs. We called out which widgets we expected to see in Tableau Connector dialogs, and handled the sizing, spacing, and layout of these components within a Connection Dialog. We also included guidance around when to pull a UX designer into the process for sanity checks.

These guidelines, shown below, gave our developers the tools they needed to answer their own questions while delivering Connectors that met our Tableau Design standards.

Special Cases

Some connection types had a more complex flow, and needed more hands-on design involvement. Two of these connectors I worked on - Google Sheets and Google Analytics - are shown below.

Google Sheets

The Google Sheets connector was unique because, unlike most data sources, Google Sheets data is created and formatted by humans. We wanted to give our users an experience with previews to help them visually find the right Google Sheets file.

I brought this connector design from start to finish, and I actually use it all the time now!

Google Adwords

Google Adwords already has a fairly complex flow in the browser, allowing users to start with a report template and customize the data extracted. I worked with a design intern - Aimee - to strike a balance between the experience users were accustomed to in Google Adwords with the more straightforward experience Tableau users expected from their connection dialogs.

I designed a brand new widget type for this connector...after considering the options and vetting the plan with Visual Design, of course.

Continuous Improvement

As the Connectivity team brought me questions and new experiences to implement, I continued to add to the Connector Design Guidelines. For example, when I created the Google Adwords connector, I added a new list view control type as well as a two-column layout option.

A few pages of the specifications I created for the Interactive List View Control are shown below.

When I created this new control, I got first-hand experience learning about the types of considerations visual designers need to think about.

REFLECTIONS

Working with a remote team for the first time was humbling; it showed me how much I relied on quick in-person conversations and back-and-forth with my developers. When that wasn’t possible, I needed to learn new communication techniques.

I learned to translate my thinking into a format that made sense to my developers when I wasn’t there to walk them through it. Instead of adding every single detail to my redlines, I learned to empathize with my developers, and prevent misunderstandings by including the right details and explanations in my specifications.