Plotly Sidekick
This page is under construction - enjoy the preview!
The Goal
As the development team worked on integrating AI into our platform, Plotly had a unique opportunity to help introduce less technical users to our product. Plotlys core user base is Python developers, who prefer working directly with code.
AI could accelerate the productivity of our existing python savvy users. Additionally, it could help business analysts - used to a more seamless UI-driven experience - to use Plotly libraries in their work.
We faced a core challenge: how to introduce AI assistance in a way that was both powerful and intuitive for our diverse user base.
We had to design an AI interaction model flexible enough to evolve as our users’ needs and AI capabilities advanced. However, we had to move quickly. The first version needed to be delivered on an ambitious timeline while still aligning with user expectations.
My Role
As the sole AI designer at Plotly, I helped the team to deliver Plotly Sidekick - a new AI assistant for our data visualization platform. I worked with our AI developers to balance AI capabilities, user costs, and experience talking to the AI. I worked on 3 core components of the product - balancing our existing python user needs with new BI users, considering different UI surfaces, and creating entry points to help more advanced AI users set the context of the conversation with the AI agent.
Where should the first version of Sidekick live?
As a new feature, Plotly Sidekick needed an entry point and primary UX surface. I worked with our beta user group and development team to evaluate the following options for incorporating Sidekick into the product:
Option 1 | Sidebar
While the sidebar helped keep the notebook content front and center, the content in the sidebar felt cramped, and there was a disconnect about what part of the notebook the user was looking at and where the user had last left off with the AI. This raised more questions than it answered and was punted to a later ship point.
Option 2 | Inline
An inline option akin to GitHub Copilot resonated with developers, but they still wanted the ability to move to fullscreen. This option also felt too technical for our new-to-python users.
Option 3 | Full Screen
The full screen option was the lowest common denominator across the board. All of our users were familiar enough with it, and it offered the opporunity to test the AI funectionality with real users quickly.
We ultimately chose a standalone AI experience that could gradually integrate more with the product over time. Two key factors led to this decision:
User Expectations
When AI tools first launched, users were hesitant to switch to an AI-driven experience because they didn’t fully understand the capabilities. Now, standalone AI products are commonplace, making users more comfortable with this approach.
Product Development Efficiency
Building and testing a well-functioning AI was already a significant lift for the team. A fully integrated AI experience would set user expectations higher than what we could deliver quickly. Keeping the AI in a separate location helped set clear expectations.
A Full Screen DataViz Agent
The first version of Sidekick was a standalong experience that and allowed users to connect to data, create and iterate on data visualizations, and add content to their Plotly Dashboards.
Code-first and UI-first users.
Plotly serves two primary user groups, each with distinct workflows:
Code-first users understood their visualizations best when looking at the code and making adjustments as they went - UI slowed them down.
UI-first users were used to traditional BI tools like Tableau and Power BI. They wanted the simplicity of a UI based experience but appreciated the ability to customize code when necessary.
Our AI functionality needed to support both user types seamlessly. To achieve this, I designed an experience where users could toggle between code and output, with the last-used mode persisting across sessions. This approach ensured familiarity and efficiency, whether users started from a code-driven or UI-driven workflow.
More Context Controls for Advanced Users
Some of our users wanted fine-grained control over exactly what the AI was using to inform it's response. This is called "context". Users needed to be informed about what sources the AI was referencing and have the ability to re-run a response with a different set of context.
I explored a few ways to communicate the context status to our users
The final version of context we decided on after user feedback was implicit context with progressive disclosure for users who wanted more information. We discovered context was being used more as "extra information" to see if something was off, rather than information users wanted available all the time. Context surfaced front and center led to overwhelm and distraction from the task at hand - not ideal.
Finally, our users needed to have control over the context given to the AI.
Reflections
Working on Plotly Sidekick taught me to balance perfection with rapid iteration in AI product design. With fewer established UI patterns in this emerging space, we had both challenges and freedom to innovate. The project highlighted that successful AI features require strong alignment between technical capabilities and user experience, especially when serving both our code-first and UI-first users. Our most effective approach was continuously adapting based on actual user feedback rather than theoretical assumptions about how people would use AI within a data visualization context.