Diagnose a slow, laggy Figma prototype

WHAT THIS TESTS The interviewer wants to see a structured diagnostic mindset applied to a design tool, the same instinct you would use profiling a web app. Figma runs in the browser on the GPU, so the bottlenecks are concrete and findable.

A GOOD ANSWER COVERS First, investigate heavy assets. Large embedded raster images, high-resolution screenshots, and images that are far bigger than their displayed size force the renderer to push enormous textures. Compress or resize them and remove unused fills. Effects like layer blur, background blur, and stacked drop shadows are expensive because they recompute on every paint. Second, audit structural complexity: total node count, deeply nested groups and frames, and complex vector networks that were never flattened. A file with tens of thousands of nodes will lag regardless of hardware. Third, examine prototype overhead: an excessive number of interactions, Smart Animate transitions between very large frames, overlays that stack, and scrolling containers with huge content. Reducing transition scope often restores smoothness.

COMMON WRONG ANSWERS Immediately blaming the user's machine or network without measurement. Suggesting you delete layers at random. Confusing file size with node count, when it is usually the live node and effect cost that drives lag, not bytes on disk.

LIKELY FOLLOW-UPS How would you find which page or component regressed. How do components and instances affect performance versus detached copies. What is the cost of using images as fills versus placed layers. When would you split a file into multiple files.

ONE CONCRETE EXAMPLE A prototype lagged on every screen change. Inspection showed a full-bleed background image embedded at 6000 pixels wide reused on forty frames, plus a background blur on each modal. Resizing the image to display resolution and replacing blur with a semi-transparent overlay cut interaction lag dramatically and restored smooth Smart Animate transitions.