making the diagram the page

The Clarity process page is where a customer sees the structured output of a captured process: the flow as a diagram, plus the summary, steps, risks, and impact behind it. The first version put all of that on one scrolling page, and the diagram, which user feedback told us was the most important element, was the smallest thing on it. This is the redesign that inverted that.

The problem

Two things were true at once.

The data model was text-rich. Each process had a summary, a step list, a vulnerabilities section, a financial impact section, a vision, and a projected impact. That content needed to stay. But rendered as one long page, it read as a wall of text. It was easy to lose your place in it, and for most users it was simply too much at once.

When we asked customers what they came to this page for, the answer was the diagram. They wanted to read the flow visually, point at a node in a meeting, and zoom into branches. The old layout had the basics: drag-to-pan, scroll-to-zoom, plus zoom buttons and a fit-to-view control. The problem wasn't the controls, it was the operating area. The diagram lived in a small column with a long text section beneath it, and the moment your cursor drifted outside it the scroll wheel stopped zooming and started scrolling the page instead. So even on a process that was technically pannable and zoomable, there was nowhere comfortable to actually work.

Point of view

If user feedback says the diagram is the most important thing on the page, the layout has to say that too. A small diagram with a long text column underneath is the layout telling users "the text matters more." I wanted the page itself to argue that the diagram is the protagonist and the text is the supporting cast you reach for when you need it.

What I tried and killed

Split 50/50. Cleanest on a 27-inch monitor. Fell apart on a 13-inch laptop where neither half was usable, and the diagram lost the room-filling quality that made it worth promoting in the first place.

Floating right panel with sticky scrolling, diagram filling the rest. Closer, but the right column still tried to be a single long document. Users had to scroll past Vision to get to Steps, which is the opposite of what they wanted. The information was equal-weighted when it shouldn't have been.

Diagram on top, text below (stacked). Same problem as the original, just rearranged.

I landed on canvas + floating panel with tabs because tabs let users focus on one piece of information at a time without scrolling, and they made the right panel feel like a reference card next to a primary object instead of a column of equal-weight content.

The work

As shipped, the page resolved into three layers. A full-bleed diagram canvas, edge to edge, with no outer padding, doing the visual reading. A right-side content panel anchored to the canvas, resizable between 400 and 960px (default 640), holding the structured detail. And a segmented tab pill bisecting the header border, switching between Current Process, Transformation Proposal, and Automation, so the navigation read as part of the page chrome rather than as floating UI.

From Figma into code

I started in Figma exploring split layouts, sticky panels, and tab arrangements. After a couple of days I switched to code, because the questions I had left were about behavior, not composition. How does the diagram feel at 0.4 zoom on a long process? What does the resize handle do to the tab strip when the panel narrows past 500px? Those answers don't exist in Figma.

This is how I usually work. Figma carries the first 30% of a design. The other 70% is interaction, real data, and motion, and that part lands faster in the medium it ships in.

Built with Claude Code

I shipped this with Claude Code as my pair. It read the codebase, drafted the canvas + panel scaffolding, helped me iterate on the resize logic and the smart-zoom thresholds, and turned the long tail of polish (skeleton states, lazy-mounted tab panels, keyboard handling) into something I could move through in hours instead of days. My job was deciding what should happen and when it felt right. Claude Code's job was getting it there.

Craft details

Smart initial zoom. Math.max(fitScale, 0.75) on first load, plus a 32px Y nudge so the diagram sits slightly below vertical center, leaving visual room for the tab pill above. The fit-to-view button uses a different floor (0.1), so users can zoom out far enough to see a full 60-node process even though the auto-load never zooms that far. Two different thresholds for two genuinely different moments.

Lazy-mount + hidden tab panels. When users switch between Current Process and Transformation Proposal, both keep their diagram zoom, scroll position, and selected sub-tab. I mount each panel lazily on first visit and then keep it mounted with display: none. Tab switching feels instant because the work is already done.

Diagram skeleton during regeneration. A shimmer skeleton fills the canvas while the model regenerates. The page stays alive instead of going blank.

Switching to React Flow (later)

The immersive page shipped first on the existing Mermaid renderer with proper controls bolted on, which was enough to prove the layout. But Mermaid wasn't the right foundation for what was coming next. It renders an SVG from a string, so anything beyond viewing (drag a node, rename a label, edit an edge) is a fight against that abstraction, and the editing surface we wanted next sat squarely on the other side of that wall.

I rebuilt the renderer on @xyflow/react with custom nodes for events, gateways, tasks, and labels. That move opened up the editing work that came after and gave the diagramming surface room to grow.

The hardest part of that follow-up wasn't the rendering, it was the layout engine. I experimented with several approaches before landing on the one that shipped. Dagre was one of them, attractive because it's small and synchronous, but on dense graphs the layouts didn't hold up. ELK.js with layered top-down placement and orthogonal routing did. Picking the right layout engine was research-heavy and not glamorous, and it was the difference between a diagram that lands clean on first paint and one that needs a human to fix it.

What I'd do differently

The segmented tab pill bisecting the header border was a moment I was proud of, but it didn't survive long. When we later redesigned the page header more broadly, we replaced the pill with the standard system tabs for consistency with the rest of the product. The lesson stuck: a one-off custom pattern, even a good one, costs more than it earns once the surrounding system moves. I'd reach for a system component first next time and only go custom when the system genuinely can't carry the idea.

Get real customer data into the design earlier. I eventually pulled real processes into the prototype and immediately learned things I couldn't have learned from a clean 8-node Figma example: how dense graphs zoom, how long labels wrap, how gateways stack on wide processes. If I'd done that on day one instead of day four, the layout decisions would have been faster and better-grounded.

Outcome

The redesign wasn't structured as an A/B test. A few things from Amplitude in the eight weeks after launch:

• The captures sheet, a new surface introduced with the redesign, got picked up immediately and stayed in regular use.
• Sharing behaviours moved less than the rest of the page; one of the threads we're still watching.

The deeper proof is in the design itself. The page leads with the thing users said matters most, and the supporting content is one click away instead of one scroll away.

What this changed for me

When a layout disagrees with user feedback, the layout is wrong, even when the data model makes the layout convenient. The text-heavy schema wanted a text-heavy page. The users wanted a diagram. The redesign isn't clever, it's the layout finally saying what the data should have said all along.

Promoting the canvas first also made everything that came after possible. Richer BPMN rendering, in-canvas editing, version history, the hover and right-click toolbars. None of that would have fit on the old page.