Unlike printed material, digital elements have the ability to transform across devices. Responsiveness is the adaptive behaviour of experiences on a digital, flexible canvas.
Desktop First
Design and implementation follow the Desktop first principle, meaning that mobile represents a variation of desktop (and not the other way around).
Desktop first, however, does not mean that mobile devices should be neglected. It is our ambition to ensure high quality across all devices.
Breakpoints
Breakpoints mark where the design might change. We use the following ones:
Handheld ≤ 480px
480px < Landscape ≤ 768px
768px < Tablet ≤ 992px
992px < Desktop
Details
Layout Container size
The Layout Container is fluid, meaning that it scales with the width of the device. It reaches its peak at a width of 1300px (excluding left/right gutters).
The left/right gutter is $space-m (20px) across all devices.
On tablets and smaller devices, the left/right gutter may be omitted for images and videos, displaying them at full device width.
Layout Grid
While on desktop and tablet the Layout Grid has 12 tracks, it gets reduced to 4 tracks on mobile devices.
Out of all changes accross devices on component or page level, changes in layout are the most likely to be necessary. For example, 3 cards that on desktop or tablet are shown next to each other, may be stacked on top of each other on mobile.
Typography
All typographical elements of 20px or smaller keep their size across all devices.
Typography larger than 20px is fluid. If the layout container is at its peak width, each typographical element will have a set size. For smaller container sizes, big font sizes approach a minimum:
The fluid font size formula in abstract is:
Large heading kerning formula
Headings bigger than 20px use the following formula for kerning:
Large heading line height formula
Headings bigger than 20px use the following formula for line height:
Space
Space by default stays the same across devices. Large space (eg. between sections) might need to be adjusted on page or component level.
Components
Some components allow their properties to be configured per breakpoint. For example, here is the Layout Grid component adjusting its amount of columns for the different viewports:
Keep it simple
The system adjusts only very little across devices. We should strive to do the same on page and component level. Most of the time it should be sufficient to adjust the layout, and reduce large space values.
Elaboration
Responsiveness can be simple or complicated. Our attitude towards responsiveness is that it should reinforce the experience to be the same for all users, regardless of them visiting from a small handheld device, a laptop or a desktop computer with a large screen.
The first, and most important insight for responsiveness, is that all our foundations are interconnected. Typography, layout, space, color and responsiveness are individual pieces of a bigger puzzle that is the Laika Design System. Because of this, diversions and system exemptions should be kept at a minimum level to ensure that our system remains maintainable and scalable. Changing one property in one foundation has effects across the entire design system.
Data research
When we started to discuss responsiveness, we started by looking at our data. At the date of our discussions our traffic was 40% mobile and 60% laptop/desktop. This led us to use large screens as the starting point for responsiveness. While we call this approach desktop-first, it’s not about de-prioritizing other devices but instead setting a starting point for where our responsive systems begin.
We also looked at individual screen sizes. Out of our mobile visitors, the smallest generally used device size was 360px. On the desktop size, the largest generally used device size was 1920px. These became our two end-values, essentially forming the minimum and maximum values of our responsive system.
The experience should be great between 360px to 1920px.
Having these to end-values made it possible to determine behaviours of certain device adaptations.
The most drastic difference between our smallest and largest value is the format. 360px is very narrow and 1920px is very wide. To have a unified experience on two completely different devices means that we need to understand what the important aspects of each foundation are.
Typography
We decided to create responsive typography around the paragraph text size. 20px typography works very well on both small and large devices and it represents a large number of our written content. On mobile, we’re less concerned with scrolling since it’s a concept that we’re very accustomed to. On desktop, 20px typography gives us the possibility to do flexible layouts but still staying true to our typographic principle of functionality. Therefore, everything that is 20px or smaller forms our static baseline.
Where adaptations are forced to happen though, is on headline level. Responsive typography has two conflicting requirements; hierarchy and harmony.
Hierarchy & harmony
Hierarchy is the requirement to have distinguishable typographic
levels to accommodate for varying content importance. Our typographic
system has six size levels, xs (12px), s (16px), m (20px), l (32px), xl (52px) and xl2 (84px). On large
devices, these proportional increments create high hierarchy and great
harmony. On mobile devices however, there simply isn’t enough physical
room on the screen to have such big variance in headline levels. The
largest size you can use on a 360px mobile device is around 40px
before the copy will essentially be one word per line.
Our approach to this problem is to have fluid large typography but static small typography. This solution gives us enough hierarchy to enforce 6 typographic levels on both desktop and mobile, but without breaking the aesthetic aspect of typography. Our large typography scales fluidly, which works seamlessly with our fluid container.
Container behavior
There are two strategies for dealing with container responsiveness, the first one being static; essentially having no responsiveness within a breakpoint bracket. From a technical perspective we would need a lot of break points to prevent massive “jumps” in container size.
The other strategy is to use a fluid container. The fluid system always takes up the available screen size up to our maximum container size.
Having a large amount of static container sizes gets close to having a fluid container setup. To keep things simple we decided to go for a fluid setup since it’s simpler. Also by systemizing foundations like typography and space in accordance with responsiveness, fluid behaviour became a flexible option, giving us the possibility to ensure high quality of both typography and visual rhythm on any device, large through small.
Space
The important aspect of space and its responsiveness is that we want to maintain the same user experience across all devices.
Our assumption was that space needed to be adapted. However we found out that small typography should stay the same across devices. To preserve the user experience, we opted for not scaling our spacing in order to keep it in sync with our typography.
This gives us the possibility to leave space as it is on all devices. If needed, we can however adjust large spaces (like space between sections) and adapt them for smaller screens and more compact layouts.