Responsive

“I’ll be right back! – Received 5 Years Ago”

Responsive design is a term that gets frequently thrown around, both in frontend web development as well as design fields like UX and UI. Websites need to feel responsive in order to provide a smooth, frustration-free experience for users browsing. But what does “responsive” really even mean?

Responsive design is a broad umbrella term that is almost misleading in a way, like how people group together the terms UX and UI. There are subtle differences inside the term “responsive” itself which are important to understand to create a fully responsive web application. Some developers make the mistake of only adding one or two elements and leave the user with a half-baked application which frustrations arise from. In this article, I’ll cover a few of the core aspects of “responsive” that I think are most important for a solid user experience.

The number one aspect is responsive websites in our modern age is designing for mobile. Much of our computing happens on mobile, and it is important to have your website accessible to those using a phone or other similar device. You may have seen sites that look like desktop sites on your phone, with very tiny text and buttons you have to zoom in to see properly. These are sites that do not “respond” to changing viewport sizes resulting in a bad experience. To remedy this, I recommend designing “mobile-first.” This means you create the mobile version of your web layout first, before the desktop layout, allowing you to scale up rather than cutting vital information to fit your content on the smaller screen. In CSS and CSS pre-processors, that would use the min-width media queries, instead of max-width. I also highly recommend using flex layouts in combination with this, as they are suited towards a variety of screen sizes. The Mozilla Developer Network (MDN) has some great resources on these topics, and more.

However, you shouldn’t stop there. Performance and indicating performance also fall under responsive design. If you don’t work in code and think that optimizations should be left towards the techies, you should re-evaluate. Design choices and code both matter in this case. Consider clicking a button to load some data. The data will always take five seconds to load in. Now, imagine a scenario where nothing happens until the data is loaded. Then, imagine a scenario where a dialog, loading spinner, or other visual effect indicates a long-running action. You should be able to see why the user needs “responsive” design, to see that the web app isn’t broken and is actually doing work in the background. You can even go one step further to potentially reduce this loading time, by pre-loading the data or designing the UX in such a manner that this step is completely unnecessary.

There are lots of extra nuances in responsive design, and it is important to understand that it encompasses many elements that all need to be fulfilled. There is a ton of interesting design principles that you may discover (for example, average attention span) as you go along. This stuff only gets better as you make more and experience more of your own software – you are often a great judge of how frustrating a user experience is! When you’re done, you can always invite friends and colleagues to try out your makings and fine-tune your creations.

** One last thing! When I first started learning about web animations using CSS, I wasn’t very sure of how long I should make them. I ended up reading an interesting study that explained user attention spans in detail. In essence, it said that for small animations, 0.3 seconds should be the hard maximum, because anything over can cause the user to lose focus (the feeling is no longer “instantaneous action”). Anything from 1-10 seconds would risk defocusing the user. Anything about 10 seconds, or the average attention span you’ll find on the internet, you risk the user leaving the page. I couldn’t find the source for this, but I still wanted to share it because it’s been super helpful when I design animations that are maybe a little excessive.