Define the Responsive Goal

A responsive Figma screen is not a desktop frame that has been uniformly scaled down. It is one interface whose hierarchy, spacing, and controls remain useful as available width changes. For this lesson, imagine a project dashboard with a navigation bar, a page title, a primary action, three summary cards, and a list of recent projects. The design must work on a 1440 px desktop frame and a 390 px mobile frame.

Before building, decide what must remain visually dominant. The page title and primary action are first priority, summary information is second, and detailed list metadata is third. This priority controls what happens when space becomes limited. On mobile, navigation may collapse, summary cards may stack, and secondary metadata may disappear, but the main action and project names must remain easy to find.

Create frames for the target sizes rather than assuming Figma will generate every breakpoint automatically. Figma can demonstrate flexible resizing through Auto Layout and constraints, but responsive product behavior still requires design decisions. Two representative frames make those decisions visible to reviewers and give the prototype predictable presentation states.

Build the Layout System

Start with the desktop frame and apply vertical Auto Layout to the main page structure. Separate the navigation, header, summary section, and project list into nested frames. Give the content area a sensible maximum visual width and consistent horizontal padding. This produces a readable column instead of allowing content to stretch indefinitely across a wide display.

Use horizontal Auto Layout for the desktop header so the title block and primary button occupy opposite sides. Set the title block to Fill container and the button to Hug contents. In the summary row, set each card to Fill container so all three cards share available width. Inside each card, use vertical Auto Layout for the label, value, and supporting text. Fixed heights should be reserved for elements that genuinely need stable dimensions, such as icon buttons or avatars.

Constraints still matter where an element is not governed entirely by Auto Layout. A floating action or decorative status element may need to remain pinned to an edge. Test each region by resizing its parent frame manually. The correct result is not simply that nothing moves; it is that each element expands, stays fixed, wraps, or repositions according to its role.

Apply Styles and Components

Define a compact visual system before polishing individual objects. Use text styles for the page title, section heading, body text, metadata, and button label. Use color styles for the surface, primary action, borders, main text, muted text, and status colors. A useful hierarchy might combine a near-black title, a medium-gray body color, a light neutral border, and one saturated accent for actions. Do not rely on color alone to distinguish status; pair it with a clear label or icon.

Convert repeated summary cards and project rows into components. A project-row component can include a thumbnail, project name, owner, updated date, status, and overflow action. Variants can represent default, hover, selected, or status differences when those states change appearance or behavior. Keep variant properties understandable so another designer can identify the intended state without opening every layer.

Components should remain flexible. Set the project name area to Fill container and supporting elements to Hug contents. Allow text to wrap where a second line is acceptable, and truncate only when the product requirement makes the full value available elsewhere. Test the component with a long project name, a short name, and realistic status labels. A component that works only with ideal sample text is not responsive.

Adapt the Mobile Composition

Duplicate the desktop screen as a starting point, change the frame width to 390 px, and then redesign the composition rather than shrinking every value proportionally. Reduce outer padding moderately, preserve comfortable touch targets, and keep body text readable. Change the desktop navigation into a compact mobile header with a menu control or a reduced set of essential actions. The page title and primary action can stack vertically if they no longer fit on one line.

Change the three-column summary region into a single column or a horizontally scrollable group only when partial visibility clearly communicates that more items exist. For a beginner dashboard, a vertical stack is usually easier to understand and test. In project rows, retain the project name and status while moving less important metadata below the name or omitting it from the compact view. This is a hierarchy decision, not a decoration change.

Compare both frames at normal viewing scale. The mobile screen should feel intentionally composed, not like a compressed desktop. Check whether headings wrap awkwardly, buttons become excessively wide, icons lose alignment, or cards gain inconsistent heights. Also inspect layer resizing settings after structural changes; copied desktop elements often retain fixed widths that cause clipping on mobile.

Create the Prototype Flow

Add at least one destination screen, such as a project detail view. In Prototype mode, choose the desktop dashboard as one flow starting point and connect a project row to the desktop detail frame using Navigate to. Create the equivalent mobile connection. Add a visible back control on each detail screen and connect it to the appropriate dashboard, ensuring the user never reaches a dead end during presentation.

Demonstrate a component state with an interactive component, such as a menu button changing between closed and open variants or a favorite control switching between inactive and active. Use Change to for transitions between variants. Smart Animate is appropriate only when matching layers and properties produce a meaningful transition; a short dissolve or instant transition is better when motion adds no information.

Preview the prototype and click every intended target. Confirm that hotspots correspond to visible controls, overlays open in a logical position, and back navigation returns to the expected screen. Keep interaction behavior consistent between desktop and mobile. The prototype does not need to simulate an entire application, but the selected path must feel complete and credible.

Polish and Present

Run a visual quality pass at both frame sizes. Check alignment against the layout grid, repeated spacing, text contrast, border consistency, icon size, card height, and button emphasis. Search specifically for clipped labels and accidental overflow by resizing reusable components and replacing sample text with longer content. Inspect the narrowest frame because responsive failures often appear first at the edges of text and controls.

Then clean the file for presentation. Name frames according to viewport and purpose, keep related screens near each other, and place exploration frames away from the final flow. Ensure the correct frame is marked as the starting point and use Present mode to evaluate the sequence as a learner or stakeholder will experience it. Construction guides should support editing without becoming part of the presentation.

The final standard is behavioral as well as visual. A polished responsive design preserves priority while its arrangement changes, relies on reusable foundations instead of duplicated styling, and offers a prototype route that can be completed without explanation. If a reviewer can resize components, scan both breakpoints, and follow the interaction path without encountering surprises, the screen is ready for presentation.