Comments Meet the Community
When Figma launched the Community, the goal was to bring hundreds of thousands of users together to share, learn, and connect. But a library of resources alone doesn't create conversation. If the platform was truly meant to facilitate engagement, creators and audiences needed a direct line of communication. The solution: two types of comments on Community files—a general feed below the file and contextual comments anchored to specific spots on the canvas, similar to how in-editor collaboration works.
Engineering lead Emily Zhong, who worked alongside design and product teams, found that porting the existing comments feature into the Community was not the copy-paste exercise she initially expected. The team had to replace the iframe file preview to support viewport communication and factor in performance for potentially many comments. The harder problem proved to be interaction design: refining clunky UX details so the new feature would feel native to users.
Contextual comments, in particular, introduced a paradigm shift. Comments are typically thought of as a linear feed of questions and answers, but anchoring a note to a specific point on the canvas requires spatial thinking. Users need to view and pan across the file while still reading attached feedback, all without degrading the established view-only experience.
Exploring the Design Space
Rather than static wireframes, the team used recorded GIFs and interactive prototypes to explore a wide range of options. These demonstrated how different canvas interactions and feed placements could change the viewing experience. A tight feedback loop across engineering, design, and product helped narrow the possibilities down to those that were both technically feasible and aligned with the launch timeline.
From this exploration, three core priorities emerged:
- Get users into the commenting experience as quickly and easily as possible.
- Display contextual comments in a space large enough to clearly understand the file area they reference.
- Keep the solution technically feasible, simple, and on schedule.
This led to an early decision: contextual comments would live only in a fullscreen view. There, the canvas could expand enough to house both the design and its notes, with comments bringing the viewer into that mode upon clicking the canvas. Minimized views had panning and clicking disabled to nudge users toward the fuller experience.
Usability Problems Surface
Most of the feature was built when routine bug-bash testing exposed a bigger issue than misaligned UI: the experience felt awkward. The team identified two distinct problems and reworked their approach accordingly.
The "No Exit" Problem
The original design made it too easy to enter the fullscreen view. Any click on the canvas triggered an expansion, but exiting required finding a small collapse button in the corner. This trapped users who clicked accidentally or preferred navigating on the smaller preview. After experimenting with a full-window takeover, engineer Jessica Wang proposed a modal solution inspired by photo lightboxes. This reused familiar enter-and-exit patterns and made navigation less surprising. The team also restored drag-to-pan on the minimized canvas to accommodate those who preferred not to go fullscreen.
Feed vs. Preview Disconnect
Contextual comments also mixed into the general feed, indistinguishable from non-contextual ones. Clicking one unexpectedly scrolled the user to the top to see it on the canvas, with no obvious way to return to their original place feeling jarring and broken. To fix this, comments received clearer visual cues: a pin icon next to the avatars and a “See in context” label hinting at the scroll behavior. Selecting a contextual comment now shows a “back” button at the top, allowing users to jump to the comment and then smoothly return to wherever they were reading in the feed.
Less obvious problems: animation details
Outside the core functionality, a few animation-related problems came up that had a big impact on how polished the feature felt. None of them had an obvious first-pass solution, and each required rethinking how the canvas and its container interacted.
Smooth panning between comment locations
In the expanded view, clicking through comments in the sidebar caused the file preview to jump instantly between locations. That was acceptable for in-editor comments, but in the Figma Community, where users may be navigating unfamiliar files, the abrupt movement felt jarring.
Supporting a smooth pan meant modifying the viewer code directly — the same system used to render prototypes. Fortunately, the interpolation logic already existed; the real work was exposing the animation and timing parameters through the viewer's TypeScript interface. It was a small change, but it was also a first look at writing Skew, the language the viewer is built in.
Hover expansion without re-renders
To signal that the file preview could be opened into a modal, we added a subtle expanding effect on hover. The obvious approach — increasing the container's height and width on hover — didn't work. Because the viewer re-renders whenever its viewport or container size changes, even a six-pixel expansion caused choppy performance as the browser repeatedly recomputed the canvas.
The fix inverted the problem. Instead of starting small and growing, the viewer container always held the expanded dimensions. A separate overlay element sat on top of the canvas with a border that masked the edges, making the viewer appear minimized. On hover, the border width shrank rather than the canvas growing, revealing previously hidden edges and creating the illusion of expansion.
Animating between absolute and fixed positioning
Animating the file preview from its default state into a modal wasn't difficult in terms of size, but the transition between two positioning schemes was. In its default state, the preview uses position: absolute, so its top, bottom, left, and right coordinates are relative to the parent container in the page flow. In the expanded modal state, it switches to position: fixed, where those same coordinates are relative to the browser window — the behavior used for sticky elements like navigation bars.
Browsers can animate most CSS properties automatically given start and end values, including the coordinate properties. But animating between different position values isn't supported natively. Switching either state to the other's positioning wasn't an option: the default preview would end up stuck to the viewport while scrolling, or the expanded modal could be scrolled past.
The solution was an intermediary state triggered just before the expand or collapse animation. In that state, the current position value and coordinates are taken, and math is applied to convert them into the equivalent values under the next state's coordinate system. For a brief moment before the animation starts, the view is translated so the browser can interpolate the coordinate values smoothly.
These largely invisible parts of the experience came from many revisions, with countless GIFs exchanged to nail down the animation details, timings, and edge cases. For a new grad engineer, being part of that tight feedback loop made the work especially rewarding — it wasn't just about writing code, but also contributing to the product's UX and design decisions.
Comments are live in the Figma Community. If building features like this sounds interesting, Figma is hiring.
