Don't fool yourself, making your site responsive is not a content strategy
Over the last twelve months, we’ve routinely received client requests asking how much it would cost to make their existing Drupal 6 or Drupal 7 site responsive. These projects mostly consist of optimizing an existing site for users accessing the content through tablet or smartphone. In many cases this mainly consists of rejuggling the position of the existing blocks of content, depending on screen width. At Code Enigma, we have successfully completed a couple of these projects (and also struggled with some of those…), but more often, we turned the work down. In some cases we didn’t even submit a quote because the premise of the project was wrong.
Clients sometimes tell us: “Our Google Analytics data shows that mobile users have more than doubled over the last 12 months, so we need to make the site responsive. And all my competitors are doing it as well.” It’s what digital assets managers hear at every conference they attend. It’s what they read in an unstoppable number of blog posts. The problem with this motivation is that making your site responsive only makes sense if it helps you deliver on real site objectives.
Making a website responsive isn’t a goal, and much less, it’s a content strategy. Ric van Westhreenen wrote in a well argued blog post that Responsive Design is a poor man’s Content Strategy. He further explains:
Responsive design has nothing to do with Content … It helps nothing with the basics of content strategy: the transfer of certain key messages to your target audience.
I can’t but agree with him. Site Responsivenes is nothing but a technicality which needs to be taken into account when developing your content strategy, but nothing more. So let there be no misunderstanding. We are not against Responsive Design. The changes with Mobile communication are irreversible. But looking at things in perspective, we'd rather have you focussing on the following two points. Paradoxically, these two arguments are somehow conflicting:
1) Web & Mobile have totally changed the way people consume content. As a result they will interact with it, share it, refer to it, etc. And you no longer control what device/medium the content will be displayed on. You might control that content on your main website, on a certain operating system, viewed with a certain browser. But the volume of devices, operating systems, browsers & sharing mechanisms is only increasing. Therefore, any way in which you con provide content as “device agnostic” is a win. If your content can be that flexible, that it can easily be displayed in any type of device, you’re basically providing Structured Content. According to Westhreenen, the CMS he's working with, Typo3, is the only CMS working well with Structured Content. As could be expected, we have to disagree on that point. But that's another discussion, so lets dedicate another future blogpost on that topic. Watch this space.
2) Now for the second point. Mobile users are nowhere like desktop users. They have different content needs. It is less likely for mobile users to read >500 words plain text. So simply republishing your desktop content for mobile users won’t work. And even within mobile users, it is worth diferentiating between Tablet and Smartphone users. A user on a smartphone is most likely performing a quick search for some factual information like contact details, venue information, practical data. So this type of content should be prominently present on small screen, or at least easy accessible. Tablet users on the other hand are more often associated with leisure and tend to be less in a hurry than mobile users.
And this is where these two points apparently have a conflict. As a site owner, should you now create one set of content that can be implemented anywhere? Or should you create device type exclusive content adapted to the users needs? Well, our answer is that it’s not one or the other. They are not that exclusive as they seem. So we do recommend you create structured content but thanks to taxonomies and views, you can then have the content displayed in different ways and with different priorities. Because some content is more relevant to mobile users, doesn’t mean that desktop users won’t read it at all. Similarly, tablet users might actually prefer to open longer, more dense pieces of content on their tablet to go and read the piece in a quiet environment instead of in front of their desktop.
Now let’s go back to the question that started this conversation: Should I make my site responsive or not? Well before taking a decision on that, we recommend webmasters, digital assets managers, Marketing managers, etc to take a step back. We need to ask ourselves a series of questions first:
Who’s the main audience of my site? If your site is mainly used by a professional audience on the workfloor, it is likely the mobile friendly site is only a nice to have.
Does my site require a login? If so, optimising your site for mobile should include simplifying the login mechanism. Typing on mobile devices should be avoided as much as possible.
What’s the expected lifecycle of my current site? If your site is already a couple of years old, and you’re planning to give the site a full overdue in the next 20 months, don’t bother making your site mobile friendly now. Save that piece of budget instead in preparing the new site properly, by doing decent user research, etc etc. Note that when developing a new site from the bottom up, your site design can be “Mobile First”. This means the design of the site is done with different mobile devices in mind from the very beginning.
Is my content optimised for mobile users? Is the current content on my site relevant for Mobile users? Even in the case it is displayed perfectly, is it likely to be consumed?
Does the content need to be enhanced? Do you need to create additional content? If so, take this cost into account. And start on it before the actual technical side of the work.
What can I realistically achieve with my budget? Too often we see in early conversations that the client only has a budget for cosmetic changes, which will only give a false impression of responsiveness, but which will irritate mobile users by half working solutions.
Mobile App? Mobile Site? Or fully responsive? Do you already have a mobile app? If yes, why do you want a responsive site? Will it replace the App? What functionality does the App have that you want to bring over to the site? Or maybe you could consider a mobile only site. This seems to be old practise, but if your site is simple and has different CTA requirements on mobile, it might be the most cost effective solution, until the next full redesign comes along.
How “heavy” is my current site? Over the last few years, broadband internet connections have moved from a luxury to becoming well established at the office as well as at home. As a result, site builders have increasingly started to include multimedia content. Many sites have acceptable page load speeds on desktop and laptop, but when accessed over mobile, the user experience is severelly impacted. Making your heavy site responsive isn’t going to be enough for users if the page takes more than 3 seconds to load. Too likely, the user will have scrolled away from your site by then.
Could your site benefit from the advantages from mobile users? Mobile devices can communicate their precise geo-location, they can place calls, etc. Can your site take advantage of these features? If so, new functionality will need to be developed, and in that case we no longer speak about making your site responsive, but about making an adaptive site.
Does your current navigation work on a mobile site? Site navigation is expected to be intuitive. But the UX standards and expectations on Desktop and Mobile devices are very different. Can your site’s structure be adapted to Mobile navigation, without losing its intuitivity?
Is my editorial workflow ready for Mobile? As we saw before, we will expect content to be much more flexible. One example of that is that single pieces of content might now have different size versions of the same image. Some fields of the content piece might be reserved for mobile, others might actually be hidden on smartphones, etc. With these content building blocks come new decisions. What images will we show where? How heavy can my embedded video be? Where can the piece be published? What’s its priority on mobile vs desktop? etc. So now we also need to answer the question: who will be empowered to make these decisions? The author? The editor? The marketing department? Certainly not your web developer? So you might actually need to take a complete new look at the media asset management system and editorial workflow, as well as establishing new design standards and best practices.
OK, enough questions. Now I might have scared you away from even considering a responsive redesign. And that wasn’t my intention. As said, we have also worked on some succesfull projects in this area. What differentiated these then? Well the decision to make the site responsive was never a stand alone decision, but a result from a deeper analysis of the site’s objectives in the middle long term. Often new features for mobile were introduced and even if the site was not fully redesigned, some pieces of it, like CTA for example, were re-engineered.
So where should I start then? Start by identifying what people come to look at on your site. Think about user personas, and user journeys. With that in mind, review your current content: What is relevant, what can be dropped, what needs rework? Review your editorial processes. Make a list of must have functionality for desktop, tablet and smartphone users. Make an honest analysis of how much development work will be needed to implement the missing components. Do you have the budget? What is the expected Return on Investment? Can you still justify spending that money? At this point, you're well placed to make that call.