Flowmark

The Problem

Designers who need a quick flow diagram in Figma are usually in the middle of something else: mapping a feature, annotating a handoff, sketching a product structure. The existing options force a trade-off. Leave Figma for a dedicated diagramming tool, or fight with plugins that auto-route everything and won't let you control the direction a line takes.

That mid-task context set the design constraints for everything that followed. The panel had to be compact and low-friction, read like a native Figma tool rather than a SaaS dashboard, and never block the user's actual work to promote its own features.

Iterating in Public: 28 Versions in Three Weeks

I invited a handful of early users to try the plugin and collected their reactions through an in-product feedback form. What came back drove 28 panel versions in three weeks. Four exchanges show how the loop worked.

"It feels stuck."

"Every time the plugin opens the screen is just black with no loading state. It feels stuck for a while. Adding a comment also hangs a bit." (translated)

The actual wait was short, but with nothing on screen it read as a freeze. Within two days I shipped a loading skeleton and busy states for the buttons. The comment kept nagging me anyway, and it eventually pushed me into a real performance pass: measuring startup jank, moving license checks off the boot path, cutting plugin start from 2.2 seconds to under 100 milliseconds. That detective story is on the Execution page. The design lesson was simpler: to a user, waiting without feedback and being broken are the same thing.

"So tiny, and so far away"

"The setup hint says cmd+V, but I had no idea what it would paste, so I couldn't find it. When I finally did find it... so tiny, and so far away XD" (translated)

Native connector setup used to be a full-page step that blocked whatever the user was doing. This comment made the cost concrete: setup was interrupting people mid-task, which is exactly the situation the product exists for. So I inverted the flow. Manual connectors became the default that always works, and native setup collapsed into an expandable card inside the tab, opened only when someone actually wants the upgrade. The old model was "set up before you can work". The new one is "work first, set up when it earns its place".

"What happens if I keep pressing it?"

"After submitting a Pro key, Refresh and Request access are still clickable. What happens if I just keep pressing them? XD" (translated)

Access flows are where a small tool earns or loses trust. An earlier version had already changed "Request received" to "Waiting for approval", because "received" reads as "ready to use" when it isn't. This comment exposed the next layer: buttons that stay pressable after their job is done make people wonder whether anything happened at all. I reworked the sequence from request to submitted to checking to unlocked, so that each state says exactly where things stand and controls retire once they have nothing left to do.

Two people, same wall

"Could the label input grow with the text? Flow descriptions can get pretty long." (translated)

"It's great and working smoothly. One thing I'd like to mention is about adding text annotations on the connectors. Would this be possible?"

Two users, independently, pointed at the same wall: labels were where the tool got in the way. The fix I wanted was obvious and looked impossible. I wanted people to double-click a label on canvas and edit it in place, like FigJam, but the Figma plugin API has no double-click hook and cannot render an input on canvas.

The way through was to stop writing behavior and start designing structure. I rebuilt the label as an auto-layout hug frame, so a double-click drills straight into Figma's own native text editing. The bubble resizes as you type, with zero plugin code running; it even works while the plugin is closed. A relaunchButtons entry gives unlabeled connectors a sanctioned entry point. The remaining design question was who wins when the canvas text and the panel disagree, and the answer became a rule: the canvas is the source of truth.

Designing the Free / Pro Line

Flowmark launched with a paid tier from day one. Not because I expected meaningful revenue at this scale, but because pricing is a design problem, and I wanted to work on it with real stakes.

The Free/Pro split follows one rule: locked features should be understandable in one glance, with no verbose upsell walls. Free keeps a complete working tool: core connectors, four shapes, three colors, bottom comments. Pro adds range: the full palette, line styles, caps and dashes, the full shape set, comment directions, auto-connect. Locked controls stay visible in the panel, marked quietly, so the boundary is legible without interrupting work.

The restraint runs deep enough that one early user teased me about it: the little gray "Flowmark Pro unlocked." confirmation was "so calm. Give it a luxurious VIP badge!! hahaha" (translated). Fair. But the quietness is deliberate. Pro is a wider toolset, and unlocking it should feel like the tool getting out of your way faster. A celebration screen would just be one more thing between you and your diagram.

To find out whether I had drawn the line in the right place, I added anonymous telemetry. Deliberately minimal: four event types, enough to answer three questions. Do people come back? Do they create connectors? Which locked feature do they actually bump into? Each pro_prompt_shown event records the feature that triggered it, which quietly turned the paywall into a demand survey.

The answer was lopsided. Advanced line types drew 48 prompts from 30 different installs, more than shapes, colors, and caps combined. If I ever move the Free/Pro line, that's where.

Working Inside Figma's Constraints

The Figma plugin runtime shaped the architecture more than any technical preference of mine. The native connector API isn't guaranteed to exist, so every connector feature runs on two tracks: native when available, a manual SVG fallback otherwise, switched by feature detection at runtime. And when a fallback happens, the panel says so ("Added with a manual connector") rather than letting two different behaviors blur together.

The data later returned a verdict on that investment: of 137 connectors created by real users, 132 were manual. The fallback turned out to be the product.

"Being able to pick the connector direction manually is great. The plugins out there are all fully automatic, and sometimes they just won't route the way you want." (translated, user feedback)

Key Design Decisions

Manual-first, native as an opt-in upgrade

The reliable path is the default, and the more capable but fragile path is an invitation. Usage data backed the inversion: 96% of connectors created were manual.

Design for the middle of someone else's task

A compact panel, scrollable content with a fixed action bar, high-frequency controls compressed into summary modes. Success here means the panel interrupts canvas thinking as little as possible.

Treat waiting and fallback states as first-class UI

"Checking native setup…" instead of a wrong first guess, explicit fallback notices, and approval states that say exactly where things stand. Communicating reliability is design work in its own right.

Price with a hypothesis, then instrument it

A visible but quiet paywall, plus telemetry that records which lock users hit, so the Free/Pro boundary can be corrected with evidence instead of instinct.

Design Solution

The shipped product: a single compact panel with three tabs (connectors, shapes, comments), manual and native connector tracks behind one interface, canvas-editable labels, and a Free/Pro boundary that stays out of the way until a locked feature is actually wanted.

Outcome

Six weeks of public telemetry, filtered to exclude internal machines:

• 151 installs, with a launch-week spike of 73 followed by steady organic discovery (8 to 16 per week)
• 26% of installs created at least one connector: 137 in total, 96% of them manual
• 45% of installs hit the Pro paywall, 158 prompts in total, with advanced line types the top trigger by a wide margin
• Zero purchases through checkout
• About 14% of installs returned after day one

For a solo side product with no marketing budget, the reach was fine. The honest numbers are the last two, and they ended up teaching me the most.

Reflection

The paywall data says 68 people wanted something behind the line. The checkout data says none of them wanted it enough to pay. Sitting with that gap is uncomfortable, but it gave me hypotheses I could never have formed without shipping: the price may be anchored wrong for a one-off need, a brand-new plugin from an unknown developer may sit below the trust threshold for any payment at all, or the bundle itself may be the problem, since demand concentrated on line types and one feature may not carry a whole Pro tier. If I ran the next iteration, I would test a single-feature unlock against the bundle before touching the price.

Retention taught a quieter lesson. A 14% day-two return rate looks alarming until you remember what kind of tool this is: flow diagrams are an occasional need, not a daily habit. Designing honestly for that means showing up well at the moment of need, which is a different problem from the one most retention playbooks assume.

One more thing I want to remember: the fastest design progress in the whole project came in the three weeks when real feedback, small versions, and public shipping formed a tight loop. The 28 versions never felt like a grind. They were the product finding its shape against actual users, two days at a time.