Why making your website responsive isn’t enough
And in general, that’s great - but there is rarely an explanation or any supplied data to backup how responsive design fits into their digital thinking.
It can feel like a tick in the mobile box, as if a responsive website is a magic bullet that will satisfy the growing demands of mobile device users and magically increase traffic, engagement and conversions.
This completely avoids the questions clients should be asking about each project questions like “How should we be engaging with users on mobile devices?” and “What tasks are users most likely to perform on mobile devices?”
Ultimately it falls to us, the designers, developers and digital visionaries to educate our clients, past, present and future on what responsive design actually is and how to best apply it to each and every project.
Research over the last few years shows a shift in how devices are now used across different scenarios, and at different times of the day:
Phones are used heavily in the morning - on the commute to work for example - with users acting in a ‘quick response mode’ in answering emails or looking up news bites. As you would expect, desktops and laptops are then utilised heavily during working hours while tablets are used in leisure time after returning home from work during the evening.
But that is a simplistic view of daily usage patterns. It becomes much more complex when you breakdown your users into personas and look at specific scenarios.
There are many other use cases that you can’t group into the above behaviours, as device usage changes depending upon a user’s activity. For example, there’s ‘show-rooming’, where users visiting a retail store will use their mobile devices to actively check for competitive prices on products they are physically looking at or touching.
These users want to find information fast to make quick decisions and this demands two things - a website experience optimised for mobile devices that provides like-for-like functionality with their desktop layouts where it matters; and fast load times that are impacted by (amongst other aspects) optimised images, CSS, JavaScript and HTML code.
Let me share a personal scenario with you which boils down to the designers/developers deciding to remove functionality from the mobile responsive layout in order to simplify the page.
I recently purchased a new LED TV. I did some initial research into the the best 22 inch LED TVs currently out on the market, and via a couple of technology review sites I narrowed it down to two front runners. I decided to venture out to an actual bricks and mortar store to see the TVs in action for myself before committing my cash.
And before I knew it, I had my phone out in the store checking for the best online prices. This is where my purchase propensity with one particular retailer dropped like a stone, despite them having a responsive website.
A direct model search keyword didn’t return the model I was looking for, but I persevered, and decided to use the navigation structure, drilling down into ‘Home Technology > TV & Home Cinema > LED TVs’ with 104 results found. OK, let’s start to filter the results down by manufacturer and screen size.
It was at this point that my visit to this particular retailer’s site ended, because amazingly they didn’t provide any mechanism for filtering search results beyond price and star rating.
This bad mobile experience stuck in my mind and being the curious designer that I am, I decided to revisit it later in the day and sure enough - there were no filters on the mobile phone viewports.
Curiosity got the better of me and I decided to check the experience on other devices and to my surprise and shock, on both tablet and desktop versions of the search results page there were the filtering options I had needed, offering eight different metrics to filter by.
Just think about how many mobile customers and sales they could be losing out on because users end up frustrated, searching for products and simply abandoning the site before they even click ‘add to basket’!
With the rise of 4G, it’s easy to lose sight that the majority of mobile devices still use 3G connections due to location and device age. The experiences we design and build need to perform just as fast on older devices or slower network connections as they do on the latest technology
There are many contributing factors to optimising performance, from loading images only when they come into view on screen (lazy loading), to optimising Stylesheet and JavaScript code so the browser can build and display the page faster.
But there is another method we use.
Also known as RESS (Responsive Web Design + Server Side Components), is a hybrid of delivering a fully responsive website where the delivered component parts of the page are chosen by the server. This enables us to focus on designing experiences that are more suited to a particular device but more importantly, reduce server and bandwidth overheads.
Navigation is a great example. I often see websites including both mobile and traditional menu systems as separate blocks in the page source code, hiding one while displaying the other. Each menu brings along it’s own baggage in the form of extra Stylesheet and JavaScript code that isn’t needed. This can add up to 10kb of extra weight to a responsive page, and on a slower 3G mobile connection every byte matters.
With RESS, we can detect the device type, it’s screen size, orientation and operating system. Each component on a page can have a library of different device implementations. The most appropriate is chosen and rendered by the server based end device. This can also extend to the Stylesheet and JavaScript code dependencies, as the server will only transfer the associated code for those chosen components.
Multiply this across 10-20 components for a larger site and you can start to see how simplified mobile components can have a positive impact on the the overall performance of your responsive website.
Our entire focus at Leighton is to deliver digital experiences that truly satisfy the customer. Our projects aren’t simply developed and delivered based on a single brief or one or two meetings. Extensive audience research is carried out before any design work even begins, while right throughout development, we’re continually testing and iterating, something that continues both pre- and post-launch.
Clearly, having a mobile responsive website is a fundamental part of our whole approach to an unrivalled digital experience, but mobile responsiveness alone isn’t enough.
The entire experience needs to be based on the audience’s specific requirements and expectations, and although having a mobile responsive website will be a key component, alone it isn’t enough to give you the confidence you need - there’s so much that needs to be taken into consideration.
And in general, that’s great - but there is rarely an explanation or any supplied data to backup how responsive design fits into their digital thinking.
It can feel like a tick in the mobile box, as if a responsive website is a magic bullet that will satisfy the growing demands of mobile device users and magically increase traffic, engagement and conversions.
This completely avoids the questions clients should be asking about each project questions like “How should we be engaging with users on mobile devices?” and “What tasks are users most likely to perform on mobile devices?”
Ultimately it falls to us, the designers, developers and digital visionaries to educate our clients, past, present and future on what responsive design actually is and how to best apply it to each and every project.
Research over the last few years shows a shift in how devices are now used across different scenarios, and at different times of the day:
Phones are used heavily in the morning - on the commute to work for example - with users acting in a ‘quick response mode’ in answering emails or looking up news bites. As you would expect, desktops and laptops are then utilised heavily during working hours while tablets are used in leisure time after returning home from work during the evening.
But that is a simplistic view of daily usage patterns. It becomes much more complex when you breakdown your users into personas and look at specific scenarios.
There are many other use cases that you can’t group into the above behaviours, as device usage changes depending upon a user’s activity. For example, there’s ‘show-rooming’, where users visiting a retail store will use their mobile devices to actively check for competitive prices on products they are physically looking at or touching.
These users want to find information fast to make quick decisions and this demands two things - a website experience optimised for mobile devices that provides like-for-like functionality with their desktop layouts where it matters; and fast load times that are impacted by (amongst other aspects) optimised images, CSS, JavaScript and HTML code.
Let me share a personal scenario with you which boils down to the designers/developers deciding to remove functionality from the mobile responsive layout in order to simplify the page.
I recently purchased a new LED TV. I did some initial research into the the best 22 inch LED TVs currently out on the market, and via a couple of technology review sites I narrowed it down to two front runners. I decided to venture out to an actual bricks and mortar store to see the TVs in action for myself before committing my cash.
And before I knew it, I had my phone out in the store checking for the best online prices. This is where my purchase propensity with one particular retailer dropped like a stone, despite them having a responsive website.
A direct model search keyword didn’t return the model I was looking for, but I persevered, and decided to use the navigation structure, drilling down into ‘Home Technology > TV & Home Cinema > LED TVs’ with 104 results found. OK, let’s start to filter the results down by manufacturer and screen size.
It was at this point that my visit to this particular retailer’s site ended, because amazingly they didn’t provide any mechanism for filtering search results beyond price and star rating.
This bad mobile experience stuck in my mind and being the curious designer that I am, I decided to revisit it later in the day and sure enough - there were no filters on the mobile phone viewports.
Curiosity got the better of me and I decided to check the experience on other devices and to my surprise and shock, on both tablet and desktop versions of the search results page there were the filtering options I had needed, offering eight different metrics to filter by.
Just think about how many mobile customers and sales they could be losing out on because users end up frustrated, searching for products and simply abandoning the site before they even click ‘add to basket’!
With the rise of 4G, it’s easy to lose sight that the majority of mobile devices still use 3G connections due to location and device age. The experiences we design and build need to perform just as fast on older devices or slower network connections as they do on the latest technology
There are many contributing factors to optimising performance, from loading images only when they come into view on screen (lazy loading), to optimising Stylesheet and JavaScript code so the browser can build and display the page faster.
But there is another method we use.
Also known as RESS (Responsive Web Design + Server Side Components), is a hybrid of delivering a fully responsive website where the delivered component parts of the page are chosen by the server. This enables us to focus on designing experiences that are more suited to a particular device but more importantly, reduce server and bandwidth overheads.
Navigation is a great example. I often see websites including both mobile and traditional menu systems as separate blocks in the page source code, hiding one while displaying the other. Each menu brings along it’s own baggage in the form of extra Stylesheet and JavaScript code that isn’t needed. This can add up to 10kb of extra weight to a responsive page, and on a slower 3G mobile connection every byte matters.
With RESS, we can detect the device type, it’s screen size, orientation and operating system. Each component on a page can have a library of different device implementations. The most appropriate is chosen and rendered by the server based end device. This can also extend to the Stylesheet and JavaScript code dependencies, as the server will only transfer the associated code for those chosen components.
Multiply this across 10-20 components for a larger site and you can start to see how simplified mobile components can have a positive impact on the the overall performance of your responsive website.
Our entire focus at Leighton is to deliver digital experiences that truly satisfy the customer. Our projects aren’t simply developed and delivered based on a single brief or one or two meetings. Extensive audience research is carried out before any design work even begins, while right throughout development, we’re continually testing and iterating, something that continues both pre- and post-launch.
Clearly, having a mobile responsive website is a fundamental part of our whole approach to an unrivalled digital experience, but mobile responsiveness alone isn’t enough.
The entire experience needs to be based on the audience’s specific requirements and expectations, and although having a mobile responsive website will be a key component, alone it isn’t enough to give you the confidence you need - there’s so much that needs to be taken into consideration.
