Diagramming: The connector logic could not be written down, so we built it instead

TLDR

Mural’s diagramming was slow, incomplete and unreliable, and the 2020 remote-work influx made it urgent. Research surfaced nine use cases and three failure modes: too many steps to connect elements, no orthogonal connectors, and connector behavior users couldn’t trust.

Three parallel tracks. Connector points: hover handles on shapes and stickies that create and connect an element in one move. Orthogonal connectors: static specs collapsed under the logic’s complexity, so we built a tunable proof of concept with engineering that became a living spec and shipped as production code. Reliability: no single rule set worked across nine use cases, so we prioritized flowcharts and the novice persona, choosing forgiving over precise.

Outcomes: +35% diagram completion, 40% faster flowchart creation (5 minutes to 3), 2x diagramming activity in 30 days, and a drop in connector support tickets.

Context

Mural is a visual collaboration canvas used by distributed teams to think together. In 2020 the shift to remote work brought in a wave of users who had never collaborated digitally before, and they arrived expecting the canvas to do more than hold sticky notes.

Diagramming was where that expectation broke. It sits underneath most of what teams do on a canvas: process flows, systems thinking, org structures, brainstorms that need structure. But the feature had grown by accretion rather than design. Connectors were the primitive everything depended on, and they were slow to create, missing basics like orthogonal routing, and unpredictable enough that users second-guessed whether their work was intact.

This was not a hunch. Diagramming was a documented product gap before we started: CSMs kept a running list of requests from customer conversations, and the same complaints arrived independently through NPS comments, support emails and the community forum. Four channels, no coordination between them, converging on the same thing.

I led the redesign over two quarters with one PM and four engineers.

What we did

The research produced nine use cases and a long list of complaints. The first real decision was refusing to treat that as a backlog. Reading across the evidence, the failures resolved into three: creating a connection took too many steps, orthogonal routing did not exist, and connector behavior could not be trusted. Those are different kinds of problem, so I set them up as three parallel tracks with one shared constraint: they had to converge on a single coherent connector model, not three local fixes.

Speed. Mural already had three ways to make a connector, all of them requiring the user to think about the connector as an object before thinking about the diagram. Rather than add a fourth entry point, we changed what a selected element affords. Connector points appear on the bounding box; hovering one previews a pre-connected clone, clicking commits it, dragging into empty space offers the next element inline. The intent was to collapse “create element, create connector, attach both ends” into one gesture, so the user thinks in diagram, not in tooling.

The cost was a fourth pattern in a product that already had three we could not remove, so discoverability had to carry more weight in testing than it otherwise would. Multiple prototypes, usability tested each cycle.

Orthogonal routing. I spent a sprint writing the behavior spec and then killed it because the rule set contradicted itself faster than I could resolve it, which was evidence about the problem rather than about the sprint: routing logic is a system with emergent behavior, and static documentation is the wrong instrument for it.

We replaced the spec with a proof of concept built with engineering, with tunable parameters and a small set of stated principles (avoid overlaps, hold 90 degrees, favor proximity, etc).

We added one behavior at a time and regression-tested all nine use cases against it.

The POC became the spec, then became the production code, then stayed as the reference for later connector decisions. The method outlived the project.

Reliability. Testing across all nine use cases showed that no single rule set could satisfy them all, so I made the call to optimize explicitly for flowcharts and for the novice persona, and to accept degraded precision for the advanced cases. Forgiving over exact. That was a real tradeoff, made once and applied consistently, rather than a compromise negotiated per bug. What made the call possible was diagnosing the actual cause: the bugs were a symptom, and underneath them “connected” had never been defined. We wrote definitions for when a connector is attached, how the user knows, and how resilient the attachment should be.

Outcome

Completion and activity come from pre/post-launch cohorts measured by the product team; the timing figure is from moderated usability tests. Support tickets fell without a target, which was the clearest signal that the reliability track had worked.

Reflection

I spent a sprint writing a specification that could not be written, and only the failure told me the logic was emergent rather than describable. I now check whether a behavior can be specified before committing to specifying it; when the answer is no, the prototype is the spec. That habit came out of this project and I have used it since.