Figma · Product sense · Mid · 45 to 60 minutes

Should Figma change core selection behavior?

Figma is a collaborative design tool for creating and editing digital interfaces in the browser. Answer this product management case and get it graded line by line against a weighted rubric.

product sense
ux judgment
prioritization
risk management
decision making

The situation

You are a PM on Figma's core editor experience. The VP of Product asks you to recommend whether Figma should invest in a new way to edit several objects at once, even when that interaction would not follow the selection behavior most designers already expect from creative tools. The push is coming from a real user pain point: repetitive edits inside the editor can be tedious, and shaving friction from actions people do all day could have outsized value. But the cost of getting this wrong is high. Selection is one of the most fundamental behaviors in a design tool, and changing it could create confusion, accidental edits, or a feature that feels powerful only after a lot of learning. Engineering and design partners are open to exploring the space, but they want a clear product point of view before committing to a broader build. Your job is to decide how to frame the opportunity, whether it is worth breaking convention, and what evidence would be enough to call the feature ready for release.

What to produce

Write a 1 to 2 page product recommendation memo.

Your answer must

Define the core user problem, who feels it most, and why it matters in a frequently used editor workflow.
State a product principle for when Figma should, or should not, break established selection conventions.
Recommend a product direction, including at least one alternative you considered and rejected.
Describe the main user experience risks, especially confusion, accidental behavior, and learnability, and how you would mitigate them.
Specify what ready means before launch, including clear validation signals or success criteria for quality, usability, and adoption.

Constraints

You cannot assume Figma can add a large new permanent UI surface just to explain the feature.
Your proposal must preserve trust in the editor's everyday selection behavior for existing users.
Do not rely on heavy training, documentation, or sales support to make the feature usable.
Assume the team can run design prototypes and limited product tests, but not a long multi quarter platform rewrite.

Format

Use short sections with headings such as problem, principle, recommendation, risks, and readiness.

How Figma actually played it

Figma's VP of Product and a product designer tell the story of multi-edit, a feature that departs from the usual way selection works. They cover the philosophy behind it, how it was reshaped across several attempts, and how the team judged it was ready. A good case on why simple-feeling features can take the most iteration.

Features that feel obvious in hindsight can still need many rounds of rework.
Breaking an industry convention needs a clear principle behind it.
Define what ready means before the feature flag is switched on.
Second-nature features deserve first-order priority.

Built from Behind the feature: the multiple lives of multi-edit by Sho Kuwamoto and Nikolas Klein, Figma.