Diagram Keys: The Story of Legends

The project started with a simple question: could we turn this existing behavior into a native Lucidchart feature?

Leadership saw legends as a promising area and asked my PM and me to investigate the opportunity.

We conducted 30-minute, semi-structured interviews with Lucidchart users. We recruited through email and focused on people who had been active within the previous month.

We started with broader questions about their work:

We then moved into questions specifically about legends:

Only after learning about their existing process did we show participants a simple Figma prototype. It simulated a color-based legend and supported:

When interview participants had created a legend before, we asked them to show us their work and invited them to join a Trusted User Group. This kept us connected with people who had firsthand experience instead of starting with a new group for every prototype.

We ran a card-sorting exercise with the Trusted User Group to understand what people most wanted to include. The ranking was clear:

We began with the smallest useful version: a color-based legend that people could edit directly on the canvas. They could add a color, label it, reorder or remove entries, then resize and move the complete object.

Starting with color let us validate the core interaction before adding more complexity.

We also explored keeping the legend on the canvas while moving editing into the right panel. It was technically more feasible, but separated the object from the controls needed to use it. Internal feedback reinforced the research: it was not intuitive enough.

After a change to the engineering team, I partnered with an engineer who also believed the canvas-first direction made more sense. We worked together to make the original proposal possible. The result was harder to build, but easier to understand.

Once the color interaction was established, I extended the same Add control to support both colors and shapes. Users could choose a styled shape already present in the document or drag a new shape directly into the legend.

That made the feature more versatile, but exposed another problem: large legends still required repetitive, row-by-row work.

Lucidchart already had a feature called Shapes in Use. It surfaced the shapes in a document and retained styling such as fill and border, giving us the exact information needed to build a shape-based legend automatically.

We added a call to action inside Shapes in Use. In one action, people could generate a useful starting point from the styled shapes already present instead of rebuilding it one row at a time.

The work contributed to a patent for automatically generating legends from graphical objects.

A couple of decisions inside that feature took longer than the idea itself. The first was pull-then-push. Instead of making people configure a legend up front, we pulled the styled shapes already in the document and let them push the ones they wanted into the key. The whole point was to make it easy to get started.

The second was how much should happen automatically. For a later intelligent-key concept—separate from the MVP—we tested auto-add on by default and spent time validating it before treating it as a viable direction. Blake, who I was designing this with, was a good check on me here. When one of my flows buried generation inside another menu, his reaction was basically “not another flow inside a flow inside a flow,” and he was right. In the shipped flow, we kept the call to action quiet. It only appeared inside Shapes in Use when there was useful document content to turn into a key, so it never nagged people when it had nothing to offer. A Salesforce consultant put the demand for it plainly: “if it’s smart, it would be quicker to generate something than to build it manually.”

A standard Lucidchart shape usually contained one block of text. A legend contained a heading, multiple rows, a visual value and label in each row, plus an Add control. Those elements could not all resize in the same way.

Lucidchart’s existing text-scaling behavior had not been designed for this much internal structure. The engineer and I iterated on spacing, wrapping, minimum sizes and scaling until the legend remained readable at different sizes.

It looked simple in a static mockup and became much more complicated once it had to behave on a real canvas.

We wanted the legend to feel like a fundamental diagramming tool rather than a specialized feature hidden inside a menu. We placed it in the Standard Shapes library, available in every document.

Its location communicated that:

Beta testing showed that Standard Shapes was not enough. Keys were sitting in the Standard Library on every single document and people still walked right past them. So we explored additional entry points through search, Feature Find, the Insert menu, Shapes in Use and relevant templates.

The goal was not to place the feature everywhere. We wanted it to appear where people were already likely to need it.

There was an initial push to connect the feature with many projects under development. My PM and I looked instead for places where a legend had a natural relationship with the surrounding workflow.

Diagram Keys launched in 2021. The available weekly dataset begins in May 2022 and records broad, actively promoted usage beginning in late September 2022.

Across 148 weeks with recorded activity through May 2025, the feature averaged approximately 159,000 weekly events from 12,900 distinct users. Weekly events peaked at 237,696, while weekly users reached a separate peak of 17,573.

Sustained usage told us the feature mattered, but it did not explain a recurring behavior: people renamed items far more often than they changed their visual values. We wondered whether prefilled template legends were causing the gap.

A post-launch document audit did not support that hypothesis. The rename-to-change ratio was essentially the same in template and blank documents. That changed the next step from “fix the templates” to improving the text hit area, tightening event tracking and returning to qualitative research to understand the behavior.

The impact extended beyond Diagram Keys. Its interaction model and technical framework became a foundation for Shape Banks, Custom Shape Banks, Sticky Note Banks, T-shirt Sizing and Estimates.

This project started with a behavior users had already created for themselves. They wanted their diagrams to communicate clearly and were doing a lot of manual work to make that possible.

Research helped us separate the underlying need from the solutions people initially requested. That distinction shaped the most important decisions we made: