There's long been some amount of translation involved in turning statically designed page layouts into functionally responsive web pages & a number of design tools have cropped up over the last few years to help bridge this gap. But just a little bit of understanding can go a long way toward helping designers create static layouts that will translate seamlessly to development.
For some time, the web was measured in pixels. This made sense as long as screen resolutions were fairly uniform. But the switch from 800x600 to 1024x768, the web’s first major resolution upheaval, was then followed by a steady drip of new screen sizes for which to account. The iPhone, then the iPad, then… well, you know. More than a decade into this explosion of new web-enabled devices, specific screen resolutions are rarely even mentioned as sites are built to display appropriately over a range of displays according to device category. Screen sizes now range in width from 320 pixels (iPhone SE) to 6016 pixels (Apple's new 6k Pro Display XDR), & modern websites need to support the full range of viewports. And even though most web browsing occurs on mobile screens between 360 & 414 pixels wide & on desktop screens between 1366 & 1920 pixels wide, the nearly nearly 1 tenth of U.S. internet users browsing on a tablet still need a compelling experience.
To support this demand for flexibility, units of measurement need to be relative, rather than static, & CSS offers Percentage, Viewport Width & Viewport Height units to accommodate this responsive behavior.
Percentage units can be very useful, but carry with them a complex hierarchical system that determines percentage… of what? Sometimes it’s the percentage of the object itself & other times it’s a percentage of parent div. So in order to achieve more consistency & modularity, Viewport Height & Viewport Width units were created, which equal 1 percent of the viewport height & viewport width, respectively. On a 1440px wide viewport, 50 VW units will always display as 720 pixels in all instances. And at a 360px wide viewport, it will always display as 180 pixels. This consistency & flexibility allows us to begin thinking of spacing & sizing units in terms of grid systems.
A grid column typically represents 1/12th of the screen, or 8.333 VW units, which we can use as a base for not only horizontal measurements, but also vertical measurements. If objects are going to be plotted horizontally along a 12 column grid, the vertical spacing should also reflect the horizontal spacing, if not the rhythm. In other words, an object might not necessarily be placed 6 columns from the top of the page, but instead gridded internally, 1 column's width away from the object above it.
The end goal here is to produce organized layouts that expand at larger viewport sizes, rather than simply stretching out horizontally, & that contract at smaller viewport sizes, rather than simply getting smushed. Here’s what this looks like at two different viewport widths…
As these graphics illustrate, VW units can be measured in pixels relative to any given viewport width according to the viewport width. So if we’re designing static comps in Figma intended for responsive web development, we simply apply the corresponding mathematics. If a canvas is 1440 pixels wide, a column’s width is 120 pixels (1440/12), & a quarter column measurement would be 30px (120/4). If a canvas is 992 pixels wide, the columns are 82 pixels & a quarter column would be 21 pixels.
Quarter columns are the smallest unit of measurement that should be used, as they shrink to 16 pixels of spacing on a 768 pixel wide viewport (minimum width for a Tablet device). Spacings smaller than a quarter column should be described in pixel measurements, but, where possible, based on the same math. For instance, if a canvas is 1200 pixels wide, smaller units of spacing might be 13 pixels (12.5 rounded up) or 6 pixels (6.25 rounded down).
Occasionally, it's best to use pixel units to describe the interior spacing of a component & VW units to describe the padding & exterior spacing. This is most useful when spacing must maintain a specific relationship to a text size described in pixels, & in these cases, the spacing measurements should be relative to the type size, rather than the size of the canvas.
Not all designs are full width, & many designs may need gutters on the left & right side of the page. In these cases, there are two approaches to designing responsive gutters: the 12 column & 14 column approach. The approaches we avoid are capped widths & pixel-based gutters. The problem with capped widths is that, when a design reaches its maximum width & the viewport keeps expanding, the inner padding will continue to swell, breaking the design. And we don't use pixel-based gutters because our development software, Webflow, doesn't yet support CSS calc() math, though this could change in the future.
In the 12 column approach, a half column will give you gutters of 50 pixels on each side of the page on a 1200 pixel wide viewport, allowing for 11 columns of content space. This means equispaced content may not fall directly on the grid, but this isn’t necessarily bad if the design makes good use of negative space. This is a little bit of an ad hoc approach to the grid that can end up creating a lose, creative energy in the design, as opposed to other more predictable, more rigid approaches to grid.
The other approach is to use a 14 column grid, wherein the outer 2 columns represent what would be 86 pixel gutters on a 1204 pixels wide canvas, leaving 12 columns for the interior content. This is a better choice when you either need more gutter space, or else need a lot of interior grid alignment (since the remaining 12 columns divide evenly into 4, 3, & also 2 columns).
Within a 14 column grid, the same mathematical approach applies, but the numbers change. For instance, you might use a 1204 pixel wide canvas, since it divides evenly into 14, & you'd use 86 pixel wide columns. (This approach can also be used with a 13 column grid, effectively halving the gutter widths.)
The main accomplishment of either of these approaches is that your gutters expand & contract along with the viewport, ensuring all of the math for the interior measurements stay in tact.
In the end, a vertical spacing approach that is horizontal grid based will allow for easier translation during development, &, in theory, designs that aren't only more consistent, but should take less time to create, based on the systematic approach.