Responsive design for beginners: how a layout adapts to the screen

Step 1

Understand what actually “adapts”

In Ukrainian, “adaptive design” usually means what English calls responsive design: NN/g describes it as an approach where the same content and functionality are available on screens of different sizes but rearranged for the available space. It isn't a shrunk copy of the desktop or a separate “mobile site” with cut content. What changes between wide and narrow screens:

• •the number of columns: three cards in a row become one under another;
• •navigation: on a phone the menu may collapse, but on desktop the main sections are better kept visible;
• •text and spacing sizes: slightly smaller on a narrow screen, but not tiny;
• •images: cropping and proportions, so the important part isn't cut off.

💡 For this the developer needs the viewport tag “width=device-width”: according to web.dev, it tells the browser to match the page to the screen width. Without it, a phone shows a shrunk desktop. Designers don't need to write code, but knowing why “everything is tiny on the phone” is useful.

Step 2

Content by priority, not “whatever fits”

On a narrow screen everything goes into one column, so the order of blocks is a decision about priority. List the page's content from most to least important. Web.dev warns against the temptation to hide “extra” things on phones: what looks like a detail may be someone's main reason to open the page.

• •the page's main action should be reachable on a phone without long scrolling;
• •don't remove content on mobile, rearrange it: accordions, tabs, horizontal scrolling for cards;
• •tables on a narrow screen are a task of their own: turn rows into cards or keep only the key columns with a way to open the details;
• •NN/g stresses that “mobile first” doesn't mean “mobile only”. If the menu is hidden behind an icon on the phone, it's worth showing it on desktop.

Step 3

Breakpoints chosen by content

A breakpoint is the width at which the layout rearranges. Web.dev advises against tying them to device classes, brands or operating systems; instead, start with a narrow screen and widen it until the layout starts to break: that's where you need a breakpoint. Between major rearrangements there can be minor tweaks, such as slightly larger spacing or text.

• •draw the narrow version first, then stretch the frame and stop where gaps or overly long lines appear;
• •watch line length: web.dev notes that classic readability theory suggests an ideal column holds 70–80 characters per line. If text stretches wider, limit the content width;
• •for a practice project three layouts are usually enough: a narrow phone, a medium width (tablet) and a wide screen;
• •individual components, such as a card, can rearrange based on the width of their own container rather than the whole screen: CSS has container queries for this (MDN). Show the developer how the card looks in a narrow and in a wide slot.

Step 4

Set up Figma so the layout stretches

Responsive design in Figma isn't three separate pictures but frames that behave correctly when the width changes. Check this simply by dragging the frame's edge. The main tools:

• •a column layout guide (called layout grid until May 2025): according to Figma's documentation, columns and rows are ideal for responsive interfaces; fewer columns for a narrow screen, more for a wide one;
• •constraints: for example, “Left and right” keeps an element pinned to both edges so it stretches with the frame;
• •auto layout: “Hug contents” sizes a block to its content, “Fill container” fills the available space, “Fixed” keeps a fixed size;
• •minimum and maximum width in auto layout: a card won't shrink until unreadable or stretch across the whole monitor.

💡 Build the page from components with auto layout: then for the wide version it's often enough to switch a row's direction from vertical to horizontal instead of redrawing everything.

Step 5

Test in awkward conditions

Responsive layouts break not on an “average” screen but in edge cases. The WCAG 2.2 accessibility standard gives clear reference points: content should reflow without horizontal scrolling at a width equivalent to 320 CSS pixels, and text should resize up to 200% without losing content or functionality. Check:

• •the narrowest screen: long headings, buttons with long labels, names and amounts;
• •enlarged text: whether blocks overlap;
• •buttons and links: WCAG's minimum target size is 24 by 24 CSS pixels; main buttons are better larger;
• •images: developers usually give them “max-width: 100%”, and web.dev also recommends setting width and height so the page doesn't “jump” while loading. Specify proportions in your design;
• •if the page is already built, Chrome's developer tools (DevTools) let you quickly view it at different widths.

💡 Exercise: take a website you often use on desktop and draw its mobile version yourself without peeking. Then compare it with the real one and show both in the community: compare whose solution works better and why.