Figma cursor components

Nothing moves in a static mockup. A card with a lifted shadow could be hovered, dragged, selected, or just styled badly, and whoever is reviewing the file has to guess which. Put a closed hand at the corner of it and the ambiguity is gone in a glance.

That is the entire job of a cursor component: it is the evidence that a hand is on the screen. These turn up in hover state annotations, drag and drop sequences, canvas and editor mockups, app store screenshots caught mid-click, and every slide where the audience needs to see where the attention is.

One Type property, and a lot of resize

The set is a single component with one property, Type, and every variant is drawn inside the same 20x20px box, so swapping an arrow for an I-beam does not shift the anchor point in your layout. The everyday shapes are all here: the default arrow, a text cursor in two treatments, a pointing hand, an open hand, a closed grabbing hand, zoom in and zoom out, move, plus, and help.

Then comes the resize family, which is bigger than most people expect. Left, right, up, and down on their own. Left-right and up-down pairs. Horizontal and vertical bars, two diagonals, and a single-arrow set covering all eight compass directions, corners included.

If you are drawing a table with resizable columns or a canvas tool with a bounding box, that granularity is the reason to use the set rather than redraw an arrow at three in the afternoon.

Two generations of pointer art

The file also carries a second family labelled macOS 26: a reshaped default arrow, a version with a menu badge, the beachball, a crosshair, text cursor, zoom in and out, the hand in pointing, open, and grabbing forms, move, and ten resize pointers named the way the platform names them, north-south, west-east, north-east south-west.

Which family you pick is a small decision with a real effect. If the screenshot is of a Mac app, a wrong-generation arrow is exactly the sort of detail that makes a reviewer feel something is off without being able to name it. For a web product the classic family is the safer neutral, since the browser will draw whatever the visitor’s own operating system supplies.

Picking the right pointer

Cursors are one of the few pieces of interface vocabulary people learned before your product existed, so borrow the meanings rather than invent them. The web’s full set is documented in MDN’s cursor property reference, and mapping your mockup onto it keeps the design and the build speaking the same language: pointer for links and buttons, text for editable text, grab and grabbing for draggable objects, col-resize on a column edge, not-allowed over a drop target that will refuse.

Nielsen Norman Group’s drag and drop guidance argues for the open hand and closed hand pairing in particular, since the change at the moment of grabbing is what tells someone the object is now attached to them.

One rule worth holding to: never place the pointing hand on something that is not clickable, even in a marketing image. That image will outlive the mockup and it teaches a false affordance every time it is used.

Building a collaboration view

Multiplayer screenshots are the other reason this set gets used. There is no name label built into the component, which is fine, because the pieces to make one are elsewhere in the kit: place a cursor, sit a tag with a person’s name just below and right of the point, and override the arrow’s fill on the instance so the pointer and the label carry the same color. Two or three of those over a device mockup and the screen reads as a live document rather than a screenshot.

Keep every cursor on a single top-level layer named plainly, and lock it. Cursors are the layer you most often need to hide right before export, and hunting for one buried three groups deep inside a card is a small tax you pay repeatedly.