Over the course of my career, I have been very fortunate to work with many creative and talented UX/UI and Visual designers that were able to come up with great solutions to very complex problems. Luckily, I still do. But whereas many of my creative colleagues have kept the pace with the advances of technology, it'd seem to me that others are struggling to design responsive websites properly.

Understandably, keeping the pace with the advances of technology, specially web technology, can become overwhelming - specially when you need to practically change your entire set of tools and the way you work every 2 or 3 years (if you want to keep up to date, obviously, which some people decides not to do).

While this sounds daunting, there are certain things that always remain the same. Rules that remain unchanged throughout time and that we can consider set in stone. We'll refer to these things as the "foundations".

One of such 'foundations' is the way browsers accomodate content and the way it "flows" inside a page (bear with me on this, I'll explain it more eloquently later on). That hasn't changed at all. Actually, it works exactly the same as it did 15 years ago. As long as we keep that in mind, anything new that comes out today, or five years from now, will be built on top of these concepts.

Additionally, besides the 'foundations', we also need to be aware of the 'limitations' of web browsers which we'll have to consider when designing or developing a responsive website. Hopefully, by the end of this article you will be able to learn, identify and understand both, and more importantly, you will learn how to design websites in a way that will make you very popular with your nerdy web-development colleagues.

Before we start, I'd like to clarify one major thing as I don't want to disappoint anyone by creating false expectations. I do not intend to make a "web development tutorial" out of this article - but if you, or someone that you know that works as UX/UI or Visual designer, is tasked with designing a responsive website in the future, the following rules will be pretty useful to keep in mind if you want to avoid headaches or having to redo your work.

Also, for the sake of simplicity, I will explain concepts in a different way that I'd explain it to a software developer. I'll try to keep things simple, easy to understand and in a way that you'll be able to translate into photoshop/illustrator easily. Just in case, I'll say it again: This article is not intended for developers, it is intended for designers with a very shallow knowledge of technical implementations. If you do have a solid foundation of technical knowledge and feel accustomed with implementing designs yourself, but still want to learn how to make responsive websites, I'd suggest you to pay a visit to Ethan Marcotte's excellent article on "Responsive Web Design".

So let's get started, shall we?

When we talk about layouts, we could describe a website, any website, as old or as new as it might be, as a group of 'rectangles' that can contain other rectangles within. It doesn't matter if one of those rectangles is an image of a circle, or just a link, as for web browsers it is still a rectangle. Now, while some of these rectangles behave and look differently from others, we can 'override' the default behaviour or style ourselves using what web developers call CSS, or Cascading Style Sheets. I'm quite sure that if you design websites for a living you're already familiar with the term, what it is and what it does, even when you don't know how to use it.

All rectangles are 'ruled' by some formatting properties that we, web developers, call the "box model" which you'll find pictured below:

margins are the space that separates rectangles from other rectangles

are the space that separates rectangles from other rectangles borders are just what the word implies

are just what the word implies padding is what separates the content inside our rectangle from its dimensions

is what separates the content inside our rectangle from its dimensions content is the rectangle itself, with its own width and height

This means that, for example, if our rectangle has an initial size of 300 x 300 pixels, with a padding of 15 pixels, a border of 3 pixels and a margin of 10 pixels the "real" size of the rectangle won't be of 300 x 300 but of 356 x 356 (10px of margin + 3px of border + 15px of padding + 300px of width or height + 15px of padding + 3px of border + 10px of margin). This means that if we have two boxes (one besides the other) the margin between them won't be of 10 pixels, but of 20:

Like I mentioned before, there are ways to override that default behaviour (for example, to add a "padding" without actually increasing the size of the box, or to specify that we don't want to have any top margins, etc.) but it's pretty important that you at least understand how the box model works, and how it calculates certain things.

By default, most rectangles are displayed like 'blocks' of content, even if we set their width to be less than the width of the browser window, it will still behave like a whole 'block' of content:

Fortunately, we can also change that behaviour as well by using several 'positioning' methods. Of all positioning methods, there are three of them that you most definitely need to be aware of: 'floating', 'absolute positioning' and 'fixed positioning'.

'Floating' allows us to position elements one besides the other automatically. The main advantage of this sort of positioning method is that, unlike the others, it is "layout aware". What do I mean by this? That it's aware of the position of other elements that might be besides it as well as of its container. I believe that it's something that you need to see and try yourself in order to understand it properly, so here it is. Load that example and resize your browser window while paying attention as to how the green/blue boxes are aware of other green/blue boxes as well as where they are contained (you'll notice that if one of the boxes doesn't "fit" horizontally it will automatically position itself in a new line).

When we use the floating positioning, we can either position elements to the left, or to the right, there is no way to "center" things using just floating. But don't worry, in case that one of your designs features elements positioned in the center there are other ways of doing it.

Also, you need to be aware that when you use floating, elements "flow" in a certain way within the limits imposed by its container. For example, if you use elements that are floated to the left, the priority of the web browser will be to organise them from left to right, top to bottom. If, however, you decide to float them to the right, they will be organised from right to left, top to bottom. Unfortunately for all of us, there's no way to specify that we want elements to flow from left to right, bottom to top.

'Absolute positioning' has the advantage of allowing us to specify exactly where we want elements to be inside the page, but unfortunately it's not "layout aware", meaning that it doesn't care if it's overlapping another module or if it doesn't fit inside its container anymore. You can try it here (again, resize your browser window to try it out).

Finally, there's 'Fixed positioning' that works almost identically to the absolute positioning, but it's not "scroll aware", meaning that even if you scroll down the element will stay in it's original place. To give you an idea of how it looks like, using a desktop browser go to facebook.com and scroll down. See that big blue bar that stays stuck to the top of the page the whole time? Or the sidebar with your contacts/chat? Well, that's how it works. It is what we could use, in theory, to develop the top bar of an iOS app... if it worked on all mobile browsers. Unfortunately this positioning method doesn't. The good news is that it is supported in most relatively modern desktop browsers, so we can use it there.

I'm quite sure that at this point you must be wondering how does knowing these concepts can help us design better responsive sites? Well, it's simple, really.

We could roughly define a "responsive website" as a site that offers a custom experience for each screen size. What most people avoids to mention, though, is that this definition lacks "using the same markup code". What this means is that, while it's true that we'll be able to provide a custom experience for each screen size, we'll have to do it using the same initial markup code... but using different styling, or CSS code.

At this point, it'd be good to learn that websites are coded using different 'languages', where each language serves its own purpose.

HTML, or "Markup" code defines the basic structure of the page. Remember when we talked about "rectangles within other rectangles"? Well, that's what HTML does.

CSS on the other hand, defines how those rectangles look like, and we can also control how they are positioned -like we discussed before- using positioning such as 'floating', 'absolute' or 'fixed'.

Another thing to keep in mind is that, when developing a responsive website, developers work their way up from the smallest screen sizes to the largest. The reason why we do that is because on mobile versions we don't need to load all the complexity that comes with larger versions of the site, so in order to make the mobile site load a bit faster than the others we use specific code just for mobile websites. As we load the site on larger screens, we load the initial styles defined for the mobile website and we add additional code to either replace some of the styles defined before or to add new ones. That is what we, web developers, call "Mobile first".

The problem is that many designers make designs for larger screens first, which is incompatible with the whole idea of "Mobile first". Therefore, my recommendation is to start making the designs of small screens before making the ones for larger screens. That will make your job as a UX/UI or Visual designer easier, and it will make our job easier as well. Everybody wins.

Remember that we defined websites as 'rectangles within other rectangles'? Let's take a look at the following example of a responsive website:

Small screens



On medium-sized screens, we could use the following design instead:

But I've seen some designers attempting to do something like this instead:

So why is it wrong? The reason why it's wrong is because the header was taken out from its original container 'rectangle', and moved above the header.

Another way to understand this would be by assigning numbers to each module. In order to work properly, you need to make sure that numbers appear in ascendant order:

The most important rule that you need to understand is that when we switch from one design to another we still need to keep those numbers in the same ascendant order. We might be able to display them differently, but we still need to keep them one after the other. So a valid alternative to the design presented above would be this one:

Notice how the elements may have changed their dimensions, and some of them are ordered a bit differently, but still show up in the right ascendant order.

So remember:

Start designing layouts for the smaller screens first, and then work your way up to the larger ones

When using floating, we can either position elements to the left or to the right. If we position elements to the left, modules will flow from left to right, top to bottom. If we float them to the right, they will be ordered from right to left, top to bottom. There is no way to override the behaviour of making elements flow from top to bottom

Fixed positioning only works properly on desktop browsers

Absolute positioning is a bit more flexible than floating, as we can accomodate content wherever we want, but it can't be used to make proper mobile layouts. Use it only to accomodate small items, such as notification boxes and so on

Think of 'modules' as boxes with a number. When shifting from one design to the other (mobile to tablet, or tablet to desktop) make sure that modules always mantain an ascending order

That's it! Do you have any questions or comments? Post them below!