Designing Search for a Boundless Canvas
When Figma designer Jackie Chui first began work on find and replace, the feature seemed deceptively simple. Chui had already built a popular community plugin with the same name in 2019, so the initial assumption was that a native version would mostly involve adding a search bar and highlighting content on the page. That assumption quickly dissolved as the team confronted the realities of searching across Figma’s multi-dimensional canvas—sorting algorithms, specialized UI decisions, and the distinct needs of Figma and FigJam all demanded careful attention.
The team started with a cross-functional working group spanning engineering, product management, UX writing, and marketing. Their focus was on nailing the "find" experience first. A few high-level principles guided development: search should feel fast and lightweight, navigation across the canvas should be smooth, and the overall interaction should feel familiar to anyone who has searched in a browser. To test ideas early, Chui used his plugin development skills to build a prototype simulating part of the search experience. Figmates then used the feature in daily work, providing feedback and participating in bug bashes as engineering iterated.
Reordering an Unordered Space
The core challenge was determining a logical order for search results. Unlike a web page or document, content in Figma and FigJam flows in multiple directions and has a user-defined structure. An initial attempt reused sorting logic from the prototyping engine, which automatically orders objects row by row—a method that works well for organized layouts like presentation slides. But it failed when pages contained stickies and shapes scattered across the canvas.
The introduction of sections in FigJam provided a partial solution, allowing the team to sort content section by section so ordering matched visual groupings. Analyzing how teams used FigJam revealed that users often group stickies during brainstorming and sometimes overlap them to form "threads" of replies. This insight led engineer Brian Schlenker to implement a spatial sorting algorithm that clusters elements by proximity, surfacing logical groups even when they aren't housed in sections.
Heuristics also emerged from observed behavior. Users tend to post stickies left-to-right in tall sections and top-to-bottom in wide sections. These patterns informed how section shapes influence sort direction, making traversal feel more natural. Navigation itself also needed tuning. When a user searches for a word, the canvas zooms to the active match. The team defined an acceptable range of "effective font size" (font size multiplied by zoom level) to ensure text is legible without overshooting. For multiple results within the same view, they avoided unnecessary panning but drew an invisible box in the center of the screen—the canvas only pans when a match falls outside that boundary.
Two Products, Two Search Philosophies
FigJam’s search was designed for simplicity, focusing on text. Figma’s version needed to be more powerful, supporting searches for frames, pages, components, and other layers across potentially infinite pages. The team identified three primary use cases: text search, quick navigation to pages and top-level frames, and layer name search.
Early design explorations considered a floating search bar similar to FigJam’s versus a sidebar approach. The floating bar felt lightweight but was weak for layer name matches—a critical use case when trying to locate a component among hundreds of results. The sidebar handled layer names well but felt heavier and didn’t obviously accommodate text matches. After weeks of exploring variations, including hybrid designs that incorporated both surfaces, nothing felt quite right. Chui presented his ideas in design critiques, gathering input from the wider team before regrouping with Product Manager KC Oh to prioritize goals.
The conclusion was that layer and page search topped the priority list. This meant the search bar belonged in the layers pane alone, even if it meant sacrificing visual consistency with FigJam's floating design. The team removed the floating search bar and worked to integrate text results into the layers pane so the experience would feel cohesive.
The Subtleties of Shortcut Design and Replace Behavior
Search is a keyboard-heavy feature, and designing intuitive shortcuts proved to be one of the trickiest parts of the project. Internal testing revealed that users who came from FigJam instinctively pressed Enter to step through matches in Figma. Supporting Enter as next seemed like the obvious answer, but it created a cascade of design decisions:
- Searching for a page with
⌘Fshould make Enter navigate to that page - If
Entermeant next for text and layers but navigate for pages, the inconsistency would be confusing - Changing
Enterto next for pages required an alternative way to navigate - A lack of
Entersupport in Figma would break consistency with FigJam and ignore users’ motor memory - Removing
Enterentirely in both products risked disappointing users who expect standard search behavior
After prototyping and iterating, the final decision was to keep Enter as next for text and layers, and as navigate for pages.
Behavior after replace actions also required finesse. Learning from the plugin experience, the team decided the canvas should pause before jumping to the next match so users can see the success state of their replacement. Similarly, the plugin’s "Keep original case" setting was removed because smarter, automatic rules could preserve casing in most common scenarios. It’s a subtle detail, but removing one more setting simplifies the experience.
Ultimately, the project underscored that even seemingly trivial features are full of tradeoffs. There are no perfect answers, Chui reflects—each decision combined experimentation with intuition, shaped by months of collaboration across product, engineering, and design teams. The resulting native feature goes beyond copying the plugin’s UI, serving as an opportunity to refine and improve a proven design.



