Diagram Keys: one shape that became a canvas framework

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 — starting broad with their work, then narrowing to their legend behavior.

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.

The model outlasted the feature. Trusted user groups became part of how our team validated later canvas work — including the org charts redesign — because this project showed that a standing panel of invested users beats recruiting from scratch every time you have something to test.

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.

This was the biggest architecture decision in the project, and the cheaper version of it would have won by default. Moving editing into the right panel was technically more feasible, and for a while it was the likely direction. But it separated the object from the controls needed to use it — and it would have quietly taught users that this object was second-class: on the canvas, but not of it. Internal feedback reinforced what the research showed: it was not intuitive enough.

The direction survived an engineering team change because I kept making the case for it. When the new team came on, I partnered with an engineer who also believed canvas-first was right, and we worked through the canvas limitations together until the original proposal was buildable. The result was harder to build and easier to understand — and because every later feature built on this framework inherited that trade, it was worth making once, correctly.

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 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.

The outcome I value most is not the legend — it is what the legend made possible. The interaction model and technical framework built for Diagram Keys became the foundation for five later structured canvas objects: Shape Banks, Custom Shape Banks, Sticky Note Banks, T-shirt Sizing and Estimates, across both Lucidchart and Lucidspark.

That reuse was possible because the hardest problems were solved once, at the object level rather than the feature level: how a multi-part object lives natively on the canvas, how its parts follow different resizing rules without breaking, how people edit it in place, and how it can be generated from content already in the document. The teams building those later features inherited answers instead of re-deriving them.

I was not on those teams. They picked the framework up and built with it on their own — which is the test I hold platform work to: a pattern becomes infrastructure when teams you never worked with can build on it without you in the room. By that measure, this project shipped one feature and seeded five more.

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, roughly 12,900 distinct users worked with keys every week, peaking at about 17,600. Event volume tells the same story as supporting color: around 159,000 weekly interaction events on average, peaking near 238,000.

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.

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: