Principles of responsive UI

Throw away 12 column grids and never use pixels again. All you need to know about flexible grids, fluid typography, relative length units and breakpoints

Anna Arteeva
Prototypr

--

Responsive interfaces are real treasure for web and product development. There are numerous benefits of going responsive:

- Cover more devices and, hence, more users

- Save development and maintenance efforts as require only one codebase

- They look and feel great

Photo by Daniel Korpai on Unsplash

Why responsive design is hard?

In the last decade, there were introduced many new ways to create sophisticated UI layouts for a wide range of devices. The same website or application can look good on giant desktop screens and small mobile devices without major sacrifices of User Experience. Nonetheless, despite advancing technical possibilities and growing design and frontend teams, the web is still flooded with dull Bootstrap-like interfaces.

Why is that? Because many designers do not yet fully understand the principles behind responsive design, yet frontend developers are reluctant to take responsibility for it — it seems like design territory. In a typical Design - Frontend setup there are a lot of blind spots, no-ones land, which lay in the intersection of design and development.

First of all, none of the design tools allows creating truly responsive interfaces (and by the way, I believe it should stay this way). It’s also very inefficient. Designers can’t take full ownership of it unless they jump into code. On the other hand, front-end engineers don’t have sufficient training, authority, or interest in making design-decisions directly in code.
As a result, the blind spots remain ignored, the web is flooded with mediocre websites, state-of-art Interfaces can’t happen unless we find a way to close this gap between design and frontend.

There is no silver bullet. Mythical UX unicorns (UI Engineers, Creative Developer, whatever you call it), are impossible to find and fit into a typical team process. I believe the easiest way to solve the problem is:

  1. to understand what is technically possible on both sides,
  2. to establish a collaborative workflow where a designer and a make choices on the intersection of two fields together.
  3. to let both frontend and design partners own responsiveness and micro-interactions

Let’s start with the definition.

Website or application is responsive when it looks good on all devices: mega-screens, laptops, tablets, and phones. It uses the most-effective layout for each screen size, visibility and appearance of certain elements can differ, font sizes and spacing are relative.

Misconceptions: what is and is not responsive UI

The image below is not an example of a responsive, but fluid layout, elements stretch or stick to other elements depending on the screen size, but the overall layout remains the same.

How to Make Your UI Design Fully Responsive With Sketch — Part 2

Here is an example of a responsive web page

Dessert Recipes Blog Responsive Design by Tubik

This article will help you to understand the difference between fixed, fluid, adaptive and responsive layouts.

Now you can see why design tools are limiting for multi-screen design. They require way too much effort to create something, that has to be recreated in code anyway. It is inneficcient. Designers should stop wasting time on pixel-perfect mockups and extremely detailed specifications, because it would look unpredictably different in browsers anyway. Mockups should roughly visualize, design concept, layouts on main breakpoints, without getting too much into details.

There are three options for doing it right:

  1. grab your frontend colleague and finish the responsive part together
  2. get access to code and do it yourself
  3. trust (or teach) your frontend colleague to make design decisions

Should designers code or developers design” is a separate topic. I am not trying to convince designers to code themselves, but to understand the principals and to be aware of technical possibilities. It is just as useful for frontend partners to learn design principles and develop an intuition for good and bad UI.

Let’s get started!

Media Queries

There is a false belief that responsiveness relies entirely on media-queries and fixed breakpoints that correspond to the most popular resolutions: mobile, tablet and desktop. In reality:

  1. It is possible to build complex responsive layouts without any media-queries
  2. It is a good practice to avoid them when possible
  3. Layouts should break when it makes the most sense, not only on transitions between conventional devices
  4. Take into account device orientation
  5. Use pointer types to design better experiences for touch or regular screens. Modern tablets can have resolutions of laptops and people can use external keyboards on their phones, relying solely on screen size is not sufficient

Flexbox and Grid Layout are made to be responsive. Learn more about the use of Media Queries (still relevant in 2020)

Relative units

You’ve probably have heard of 8pt grid system. It became the standard in web world. In simple terms— 8pt defines the base space unit, all elements in UI are relative to it — Typography, Spacing, block elements etc. It often means does not mean it’s the minimal

Defining spacing in pixels is extremely inflexible. Ideally, there should be only one element with size in pixels — global font-size — everything else should be in relative units.

Let’s take space between sections — it should be larger on desktops and smaller on phones. If you do it in pixels, you would have to set a different number for each breakpoint. It would require many lines of code, hence more effort, and it would still look bad on edge cases. Alternatively, using a single value in relative units allows to define spacing on all devices without any breakpoints with one line of code — View Height (vh) or View Width (vw), which stands for 1% of screen height or width, respectively,

Another example is text spacing. Text margins and line heights can be defined by unites relative to the font size of this current piece of text with “em”. This way you can set the margin for all Headings to half of the font size with only 1 line: margin-top: 0.5em.

In this case Heading 1 with font-size: 30px would get top margin 15px, Heading 5 with font-size: 16px would get top margin 8px.

By the way, “rem” is another font-size based unit, but it always relates to the global font-size (most of the cases 1rem = 16px).

Learn more about relative units and fun things you can do with them

Fluid font sizing

It is especially useful for Display Headings — the giant pieces of text that should scale down on mobiles. You might not believe me, but you do not need breakpoints for this either!

Here is an excellent article that explains all about fluid typography. Hopefully, you will never use pixels for your font sizing anymore.

Here is a simple calculator that I use to create responsive font-size formulas

Grids.

I will not stop repeating: 12 column grids are massively outdated and do not make any sense anymore! If your developer is still stacked with Bootstrap grid, you are gotta tell him about The Grids — they are not much effort to use once understood (which can be challenging at the beginning but certainly worth the effort). And for those who concerned, all modern browsers already support them, don’t take it as an excuse.

There is no reason to stick only to relative or to fixed sizing for containers. Sometimes it makes sense to make a layout consisting of columns with, the first one — fixed width of strictly 200px, the second one stretching between 20vw (20% of the screen width) and 20rem, and the last one taking the rest of the space, but not less than 400px. And the layout would break automatically when one of the requirements do not match, no media-queries needed.

Another benefit is the positioning of blocks on the page does not depend on their order in code. You can create a custom layout map for any screen size, while code will remain untouched (the SEO team will love it!).

Here are more Grid-layout examples to give you an idea of what is possible

Here is the guide to get you started

Usable forms

No one likes filling in long, tedious forms, and it is purely a UX challenge to make them as frictionless as possible. Start with making sure that autofill works correctly for all inputs — Name, Address lines, Bank cards. All it requires is to have an input type defined for each input. Try to stick to standards as much as possible — users will appreciate more a standard input with autofill for a credit card, then a fancy animated four little windows that ignore autofill and copy-pasting.

Forms look and feel different in different browsers and experience of browser native forms is always better, easier to implement and more accessible then custom-made. It’s Fine that your dropdown looks different on desktop, Android and iPhone. So do not invent a wheel.

Here is a brilliant article about forms on mobile

Flexbox

Flexbox is a current industry standard for layouts and positioning elements relative one to another. Even though Grid is a game-changer for page layout, Flexbox is still the best way to order items within sections.

There is no way around, understanding what Flexbox can do is a foundation of good design.

Conclusion

I hope it was helpful. Did I miss something? How do you use handle responsiveness in your team? I am curious to hear insights and stories, please share in comments or with me directly.

--

--