Data Connections

Designing a No-Code Solution to Simplify Data Warehouse Connections

COMPANY

Plotly

ROLE

Product Designer

Year

2024

TLDR;

The process of connecting to data within the product was cumbersome, requiring extensive programming expertise, resulting in user frustration and inefficiencies. Data scientists, our primary users, struggled to complete a core task essential for using our analytics platform.

I redesigned the data connection experience by introducing a streamlined, secure workflow that minimized setup time, improved usability, and ensured seamless collaboration across teams.

Discovering The Need

Discovering The Need

“It took you how long?”
“Six hours. And I needed to ask for help twice.”

-Plotly Co-Founder

As we all stared at our co-founder dumbfounded he began walking us through his experience of using our product. Hours of recordings documenting the process of getting access to data, connecting to it, and then using our libraries to answer a question he had about some analytics.

The process was tedious and code heavy, and it was clear: our users were struggling

The Problem:
Data Connections Slowing Users Down

The Problem:
Data Connections Slowing Users Down

Most of our users store their data in data warehouses: centralized repositories optimized for querying and reporting structured data. Unfortunately, the initial setup process to access data from these warehouses required programming expertise that many lacked. We realized our focus had been on helping users develop and deploy data dashboards, but we had neglected a critical part of the user journey: connecting to the data itself.

How Datawarehousing works

Pain points with our current infrastructure:

Pain Point 1

Repeated setup for each connection instance

Every time users needed to connect a new data source or reuse an existing one, they were required to go through the entire setup process from scratch. This included locating credentials stored in separate systems, re-entering the same information repeatedly, and debugging minor errors in configurations like typos or mismatched parameters.

Paint Point 2

Risky credential management practices.

Many users resorted to hardcoding credentials directly into code, creating platform wide environment variables or sharing them via unsecured methods like email. Without centralized management, credentials were frequently misplaced or out-of-date, resulting in reliance on administrators or broken applications.

Paint Point 3

High barriers of entry for non-programmers.

Initial configurations often required scripting or using command-line tools, which alienated less technical users. Errors during the process lacked clear feedback, leaving many stuck and reliant on IT teams for support. Additionally, Plotly’s documentation catered primarily to developers, offering insufficient visual guides or examples for other user groups.

Competitive Research

Competitive Research

With many enterprise products locked behind paywalls, I relied on available what was accessible publicly to play around with and supplementary resources like YouTube tutorials to analyze four competitors and identify patterns in their user experiences.

The findings revealed a consistent user journey across all products, with following industry trends:

  1. Form Based Connections

  1. No-Code connection to projects

  1. Access Control

Defining Solutions:
Bridging User Needs and Innovation

Defining Solutions:
Bridging User Needs and Innovation

Defining Solutions:
Bridging User Needs and Innovation

Our competitors all offered similar solutions, creating internal pressure to follow their lead and design a comparable system. While I recognized the strengths of these established approaches, I couldn’t help but ask: Is this truly the best we can do?

Was there an opportunity to innovate and push the boundaries of what users could expect from the industry?

To challenge the status quo and inspire stakeholders, I developed a series of low-fidelity designs. These concepts weren’t focused on the granular details but aimed to explore alternative workflows and re-imagine how users could connect to and interact with their data.

Solution 1: Stick to the status Quo

This approach mirrored the traditional credential-based connection setups used by our competitors. Users would manually enter their credentials into a straightforward form to establish a connection with their data source.

Solution 2: Higher Security, Fewer Steps

In this option, users would connect to data sources using their personal credentials through OAuth or similar authentication protocols. This method would automatically allow users to view only the data they have access to without needing additional permissions logic on our end of the system.

Option 3: Integrations with data warehouses

This solution envisioned a collaboration between Plotly and data warehouse providers. Users would continue to configure their data sources directly within their warehouse environment, and would then have the option to push the data to Plotly through prebuilt integrations.

Ultimately, we decided to proceed with Option 1 due to time and resource constraints. This allowed us to deliver a functional solution quickly while laying the groundwork for future enhancements. We also incorporated plans to introduce OAuth support in subsequent iterations, moving closer to the streamlined and secure experience envisioned in Option 2.

Final Solution

Final Solution

Final Solution

In addition to designing the form-based flow for connecting to data, I also designed a way for make improve the experience for accessing the data.

The two additional features were:

  1. Data Browser: To search though and view the connected data without code

  2. Custom SQL Cells: Integrate SQL queries directly into notebooks without requiring a python wrapper

Challenges:
Plans are great, until they change

Challenges:
Plans are great, until they change

Challenges:
Plans are great, until they change

Challenge #1 — Funky permissions logic

Projects and data sources had individual permission levels. When combined, it limited the CRUD actions for connections and also limited how projects could be shared.

Solution

As a short-term fix, I designed manual permissions workflows to connect data to a project and limited update and delete actions in certain cases. This made sure that all collaborators for a project were allowed to access the data used, and that dashboards did not break because data went missing. The long term solution will be to replace this structure with an O-Auth flow in the future.

Challenge #1 — Funky permissions logic

Projects and data sources had individual permission levels. When combined, it limited the CRUD actions for connections and also limited how projects could be shared.

Solution

As a short-term fix, I designed manual permissions workflows to connect data to a project and limited update and delete actions in certain cases. This made sure that all collaborators for a project were allowed to access the data used, and that dashboards did not break because data went missing. The long term solution will be to replace this structure with an O-Auth flow in the future.

Challenge #2 — Manual restarts needed for environments

Development environments are an isolated system which means changes to data credentials do not apply unless the environment is restarted.

Solution

I explored automatically restarting environments but user tests showed that they interrupted the workflow and were annoying. As an alternative, I opted to use alerts to notify when a restart was required.

Challenge #2 — Manual restarts needed for environments

Development environments are an isolated system which means changes to data credentials do not apply unless the environment is restarted.

Solution

I explored automatically restarting environments but user tests showed that they interrupted the workflow and were annoying. As an alternative, I opted to use alerts to notify when a restart was required.

Challenge #3— No live feedback upon connection

When users create a new data connection, the system allows them to save it without verifying whether the entered information is correct, as we currently lack the ability to validate the credentials during setup.

Solution

The bad news here is that this problem could not be solved this iteration. The good news is that we made this decision because we were confident we would be able to provide our users with live feedback during the data connection create workflow. In the meantime, users are shown an error when they try and use the data but are not given a specific reason why.

Challenge #3— No live feedback upon connection

When users create a new data connection, the system allows them to save it without verifying whether the entered information is correct, as we currently lack the ability to validate the credentials during setup.

Solution

The bad news here is that this problem could not be solved this iteration. The good news is that we made this decision because we were confident we would be able to provide our users with live feedback during the data connection create workflow. In the meantime, users are shown an error when they try and use the data but are not given a specific reason why.