Taking Responsive Websites to the Next Level

Responsive web design started three years ago when media queries made it to W3C’s recommended standard in June 2012. It was the most anticipated CSS feature at that time (the one that put responsive before web design) and it became a game changer that would open a door of endless possibilities for designers and developers alike. The most important trend that followed shortly after its introduction was mobile first.

After three years of making responsive websites, I think we need to take a moment and see where we are heading and if the path we started on is the right one. So far the only thing responsive about our website is the way it looks and feels on a mobile device and occasionally print. If, in fact, a device-first approach is the way to go, then we should keep in mind that we can do much more to help our users. We could take advantage of all the good stuff HTML5 APIs offer (battery status, network information, etc) in order to respond and adapt to certain events such as: the network going down, the battery getting low while browsing a website, etc. But why stop here? A responsive website should respond, in real time, with a solution to a user’s problem.

There are many ways to support this type of responsiveness, and even more benefits that come from this heightened response, but in order to achieve this you’ll need to think about what you’re trying to do. Making websites look good on mobile devices is easy, but making it react to the way a user interacts with it is a whole new story which requires knowing certain information about the user. Usually, gathering this information would be prohibited by the government, but because we are using the information to improve user experience, we are still able to make websites.

Responsive Website Example

Each one of us uses the web differently, so why not make website that responds to our behavior and adapts within certain bounds to our unique way of using the web? For too long, users have had to adapt to the way a website works; it’s time for websites to adapt to user behavior. We should not block certain types of users from using our sites simply because they are not in the targeted group; they may still end up using the site, but becoming frustrated when they can’t navigate it as easily. Instead of potentially alienating users who are not a part of the group that the website is catered toward, we should focus on creating a website that will respond to everyone.

Let’s use Angry Joe, a hyperactive person and a passionate gamer, as an example. Angry Joe loves blowing off some steam while playing games, but usually ends his gaming with a rage quit if things don’t go as planned. Joe has started shopping online recently, but he is having a hard time using a well-known gaming shop because he has a very high DPI mouse that causes him to navigate around the screen too fast and click on things that he is not interested in. Additionally, being an avid PS4 fan, Joe does not want to see the always-visible sidebar advertising old games that he knows he will not want to buy. At this point, though Joe really likes this company, the website is deterring him from shopping there anymore.

Now let’s see how a responsive website would respond to Joe and convince him to stay. His first problem is site navigation, which might not be an issue for a regular user; however, Joe, and his highly responsive mouse, usually browses in a chaotic and fast-paced way and loses patience each time he makes a wrong click. To solve this problem, the website would respond by increasing the button size and the margins throughout the page to minimize the chance for him making a wrong click.

Joe’s second problem is his annoyance that the website does not recognize his love of PS4 games. To fix this, the website will respond by having the PS4 category as the first menu item that appears, and will list PS4 games before any other kind of product. Additionally, Joe has never clicked on the sidebar, so it does not need to be kept active. The removal of the sidebar not only reduces Joe’s chance of a mis-click, but also allows for the website to list five products per row instead of only four.

At this point, we managed to improve Joe’s experience and focused everything around the things he likes just by watching his interaction patterns and responding to the pain points. Now Joe is a happy client and continues giving his business to this website. He even refers new customers because he likes the overall user experience and client service so much.

Even though Joe is only one example, there are many other online users out there that have similar problems with website navigation.  There is much more that we can do for our users if we are willing to pay more attention to the small details. Making a website that looks good across different devices is just the tip of the iceberg. Instead, let’s start making smart websites that respond with a solution to a user’s problem, not just adapt the content to fit on different devices.

 

Paul Axente

Paul Axente

Senior UX Designer

Paul Axente is a Senior UX Designer at 3Pillar Global in Cluj-Napoca, Romania. He has over five years of experience in web design and user interface design, specifically with HTML, JavaScript, jQuery, and CSS3.

Leave a Reply

Related Posts

High Availability and Automatic Failover in Hadoop Hadoop in Brief Hadoop is one of the most popular sets of big data processing technologies/frameworks in use today. From Adobe and eBay to Facebook a...
How the Right Tech Stack Fuels Innovation – The Innova... On this episode of The Innovation Engine podcast, we take a look at how choosing the right tech stack can fuel innovation in your company. We'll talk ...
The Road to AWS re:Invent 2018 – Weekly Predictions, P... For the last two weeks, I’ve been making predictions of what might be announced at AWS’ upcoming re:Invent conference. In week 1, I made some guesses ...
Building a Microservice Architecture with Spring Boot and Do... This is the fourth blog post in a 4-part series on building a microservice architecture with Spring Boot and Docker. If you would like to read the pre...
Building a Microservice Architecture with Spring Boot and Do... Part III: Building Your First Microservice, its Container, and Linking Containers We're about ready to actually get started with building a microserv...