Making copy + paste “just work” in a deeply nested canvas
At Playful, we built a product called Hatch — a tool to let novice-to-intermediate builders create real software. Think part website builder, part visual programming tool. Real software means deeply nested layouts: layers inside layers inside layers. And the most routine action in any design tool, pasting an object, kept landing things where users didn't expect. I owned the interaction design for a paste system that could read intent, behave predictably at any nesting depth, and recover gracefully when it guessed wrong.
My Role
Lead product designer
The Team
3 engineers, 1 PM, 1 QA
The Company
Playful Software
No one notices copy+paste until it’s wrong.
A single paste in a nested canvas has to answer several questions at once: which container receives the object, where inside it, and what happens when that spot is out of view, inside an auto-layout stack, or in a section’s overflow. To ground the answers, I audited how tools like Figma and Webflow resolve paste targets, mined support feedback for the moments paste broke trust, and watched users in usability sessions. Three signals kept repeating: selection is the strongest clue to intent, an invisible paste reads as a failed paste, and pasting between sections is usually an attempt to sync position.
Screenshot of the Hatch design tool.
Writing the rules that decide every paste
Rather than spec behaviors case by case, I distilled the evidence into a ranked set of principles. This gave the engineering team a decision framework instead of a pile of edge cases to build against.
01
Honor selection
What the user has actively selected is the strongest clue to intent. Paste into the selected section or container whenever possible.
02
Paste in view
An object pasted out of view gives no feedback the action worked, so it must never happen. Users who see nothing paste again and dirty their project.
05
Embrace acceptance
These rules match user expectations in most scenarios, but there will always be cases where they fall short. The fallback rule makes it easy for the user to correct any wrong assumptions we make.
06
The fallback rule
If all preceding rules fail, the object is pasted to the direct center of the user’s viewport and reparented to the section occupying that space.
Stress-testing the rules across 10 scenarios
I pressure-tested the rules against every paste situation Hatch could produce. I documented each as a step-by-step storyboard with coordinates, selection state, and expected result, precise enough for engineering to build from directly.
Paste into a selected container, at exact origin coordinates
The simple case that anchors everything: with “Container 2” selected, a copied object lands inside it at its original (x, y) — rules 1 and 3 working together.
When rules collide, “paste in view” wins
If origin coordinates would bury the object in a section’s overflow, it’s re-centered on the offending axis. If the user is zoomed into a corner and would never see the paste, the object is centered in their viewport instead — feedback beats fidelity. This is where the rule hierarchy earns its keep.
The exceptions are specs too
Three cases deliberately break the core rules: pasting onto an identical object behaves like duplicate (a sibling offset by 10, 10); objects copied from the same parent keep their relative spacing, because group geometry beats visibility; and sections — which can only be children of the page — paste below the active section instead of into it.
Outcome
Engineering shipped the system as specced, and in subsequent usability tests paste became something users stopped getting tripped up by in most scenarios. It reflects how I work at the granular end of product design: turn fuzzy “it feels broken” feedback into ranked principles, pressure-test them until the exceptions are designed rather than accidental, and work with engineering to write a spec precise enough to build without needing to fill in gaps.