First Figma steps to turn a brief into low-fi concepts

WHAT THIS TESTS: This question evaluates process discipline and your comfort with ambiguity. Senior interviewers want to see that you separate problem definition from solution rendering. They are listening for whether you establish information architecture and user flows before you worry about color, type, or component fidelity. The subtext is collaboration: a low-fidelity concept should be reviewable by product managers and engineers without you in the room.

A GOOD ANSWER COVERS: A strong response walks through four specific phases in order. First, brief audit and file setup: read for user goals, constraints, success metrics, and edge cases, then create a Figma file with a cover page, a brief sticky note, and separate pages for exploration and review. Second, information architecture and user flow: map the happy path and key edge cases using simple rectangles and arrows, deciding what screens exist and how they connect before drawing any interface chrome. Third, grayscale wireframing: create frames at the correct device breakpoints, use a single type scale and no color to keep the conversation focused on layout and hierarchy, and stick to basic shapes rather than polished components. Fourth, annotation and async handoff: add comment stickies or side annotations that call out assumptions, data dependencies, and open questions, then set sharing to comment access and sequence frames numerically so reviewers can follow the narrative without a live walkthrough.

COMMON WRONG ANSWERS: Candidates often red-flag themselves by jumping straight to a design system or component library before understanding the problem. Another failure mode is producing one beautiful high-fidelity hero screen instead of mapping the full flow. Spending cycles on color palettes, drop shadows, or micro-interactions at this stage signals misplaced priorities. A rigid, linear process that cannot accommodate brief changes also worries interviewers, as does forgetting to mention any collaboration with PM or engineering during the initial setup.

LIKELY FOLLOW-UPS: Interviewers often push on how you know when to move from low to mid fidelity. They may ask what you do when the brief lacks clear user goals or contradicts existing patterns. Another common thread is how you integrate feedback that invalidates your initial architecture. You might also be asked to describe a time you pivoted the entire flow after an internal review.

ONE CONCRETE EXAMPLE: Suppose the brief asks for a new scheduling widget inside a SaaS dashboard. You would start by creating a desktop frame at 1440 pixels wide, then drop in three grayscale blocks representing a calendar view, a sidebar filter panel, and an upcoming events list. You would draw arrows showing click paths from the dashboard entry point into the widget and back, and place red comment stickies asking whether the default view should be week or day. The file is shared with the product manager and two engineers with comment rights, and no icons, color, or final typography are introduced until the flow and hierarchy are approved.