How to plan responsive web services: Notes

Andrew Lewis, Natural History Museum, London, UK


This session will help you to plan how to make your web services responsive, mainly focussed on mobile-responsive and tablet-responsive displays, but also covering other less well-known aspects of responsive-design including large-screen responsiveness, orientation-responsiveness and responding to users' emotional needs.

You will get evidence-based arguments for how you should consider responsive-design conceptually, backed up with real-life issues from experience of live implementations. You will hear how to move from important theoretical principles to useful strategic implementation.

This session is user-focussed based upon an understanding of users' needs in their daily lives.

The session includes user-involvement and testing, evidence-gathering, interface design, development options, managed digital assets, budget limitations and more. It offers pragmatic solutions to challenges and tactical options to navigate projects round barriers. It also considers the role of prioritisation and compromise in order to deliver continuous incremental benefits.

Some examples from other smaller projects are also included, to give a balanced range of options when you only have a limited budget.

You should attend if you are responsible for managing the delivery of web digital experiences. No detailed technical knowledge needed to gain from this session.

- Greater overall awareness of how responsive services benefit your users
- Understanding of common issues that affect how displays can usefully respond to mobile and tablet use
- A basic technical grounding in the way responsive sites work and implementation issues
- How to prioritise development effort based on evidence of user need, including web analytics and qualitative research
- Practical planning advice on breaking down work into deliverable enhancements
- Confidence to make informed decisions about supplier engagement

Keywords: responsive design, practical service delivery, user-focussed design, evidence-based development, mobile

Notes to accompany Museums and the Web session 4 April 2014, Baltimore.


These notes are for a how-to session about planning for change. They are aimed at helping you plan how to make your web services responsive. The main focus is on mobile-responsive and tablet-responsive displays. This paper also considers more generally what responsive-design means and how the principles can be applied to designing services that are responsive in other ways such as adapting for very large screens or changing displays to suit screen orientation.

This session, and its notes, cover a simple conceptual model based on recognising priority user contexts, optimising services to meet users’ needs and how to collect evidence to inform how you should consider responsive-design. This is backed up with real-life experience from live implementations. You will hear how to move from important theoretical principles to useful strategic implementation, acknowledging that although the range and capabilities of consumer devices becomes wider, local technology, expertise and budgets remain finite and limited.

Some basic concepts

This paper does not explore the full technical details of implementing responsive services in great detail, nor is it pedantic about the origins of the terms used nor concepts discussed. It is intended merely as a convenient overview, to encourage reflection on the user needs behind these concepts and why it is an important consideration for relevant services in a digital-first world (and it is already digital-first, get over that one!)

What do we mean by responsive web services?

A responsive web service as discussed here is one that people can access via the web in different ways and which adjusts automatically to suit these different types of access accordingly.

The most common use of the term ‘responsive’ is in describing mobile-responsive web pages: web pages that actively detect when a user is accessing them on a mobile phone and that somehow change the display or functionality to make it easier to use. Typically, this includes responding by things like omitting certain features, displaying them so they suit the minimal space of small screens or laying out the interface and content differently for portrait compared to landscape orientation.

It is recommended here however, that when planning, the term ‘responsive’ should be used more generally to mean changing to suit any two or more user contexts. In the example of a mobile-responsive service, the consideration is not just about the physical device itself either, but also the context of how it is used and its effect on behaviour. It is important to evaluate the other contexts beside mobile that the service needs to be responsive to.

It is useful to keep this concept in mind, as it can help avoid narrow thinking when planning for change. To develop solutions, the aim is to identify important user contexts and the needs and behaviours associated with them. In developing a responsive web service, you can then make an objective decision about which contexts to prioritise, to best suit your key audiences or fulfil your key objectives. For example, mobile responsive discussions often assume that you will start with an existing (desktop) service and make it responsive for mobile users. It doesn’t have to, and it is often not the best way.

It is worth stating that, by definition, responsive services are user-focussed. To plan for them requires you to gain an understanding of users’ needs in their daily lives to help you consider how your services can suit them. This means looking more widely than simply what they are doing on your existing services, by also looking at what happens in everyday scenarios.

The difference between responsive and optimised

These two important concepts are linked. While a responsive service is a single service that changes its presentation when accessed from different contexts, an optimised service is one that best suited for a specific context. Each of the contexts that a service is responsive to should be optimised differently and specifically to that context.

Optimisation is about making a service best deliver its pay-off for each context. This is most commonly about reducing the difficulty of a service to use. For example, in the context of reading an article on a small screen (part of mobile optimisation) this might mean larger text and less navigational clutter. Ease of use is only one possible objective. For example, if a service is intended to inspire curiosity or wonder in people, then optimisation can mean making that service really delightful and pleasurable to use.

Ideally as a process, first the most important contexts are identified and then optimised presentations created to deliver the intended experience for each for each. Finally, the service responsively changes when accessed from each context. Of course, no service can predict all possible user-desirable contexts, let alone respond to them. In practice, planning for responsive services requires prioritisation and compromise.

Why do you need to be making your web service responsive?

This is a question worth asking. The answer is simple and relates to the proliferation of digital in people’s everyday lives. The simple fact is that the majority of people have web access on an expanding number of web-enabled, wirelessly-connected consumer devices. Crucially, an established body of usage data also shows that this has changed social behaviour.

People like their digital devices. They are not going to take kindly to being excluded from accessing your services because they don’t work (or don’t work well) on the device(s) they happen to have. Similarly not responding to newly emerging social behaviours formed by the many devices available to people, is to become increasingly irrelevant to them.

Of course, the fact that you cannot be sure exactly how people will be accessing your web services is problematic. The remainder of this session offers some simple planning principles that can help you keep your services relevant.

Basic planning process for a responsive web service

Examples in this session generally focus on mobile and tablet responsiveness. However, this is simply because these two types of web device have become the most rapidly and widely adopted. More generally, responsiveness is not specifically about mobiles or tablets in particular. They are currently important things to address and help show the underlying principles. Your services may need to be responsive to any form of digital access that arises. Of course to do this assumes that you know what is coming, which in turn requires that you be continuously watching for digital trends.

connections 500w, 999w" sizes="(max-width: 300px) 100vw, 300px" /> Figure 1. Understanding digital trends to identify and prioritise important user contexts

Useful approaches

1.      Continuously research

This might seem obvious, but it is essential to keep up to date with consumer trends in general, such as technical blogs and consumer trend watchers. There’s loads of free information out there. Many consultancy companies put out “advertorial” market reviews summarising major trends. You should get on technology lists, follow tech twitter feeds, join LinkedIn groups – lots of them.

As well as national and global trends, it is vital to be familiar with the evidence about your specific audiences from your own local data and surveys.  You should know how your organisation surveys its visitors and if necessary conduct surveys yourself. There are lots of easy ways:

Examples of resources out there (you will find others)

  1. Ofcom (2013). ‘The Communications Market 2013 (August)’.
  2. Google (2012). ‘The New Multi-Screen World. Understanding cross-platform consumer behaviour’.
  3. Pew Research Center
  4. Ridley, L. (2014). ‘People swap devices 21 times an hour, says OMD’ Media Week. Available at:
  5. Locke, M. (2013). ‘The ABC of Social TV’. Available at:
  6. Museum Computer Network list
  7. Museums and the Web (obviously J)
  8. Guardian Technology blog
  9. Gartner (2013). ‘Gartner Says Smartphone Sales Accounted for 55 Percent of overall Mobile Phone Sales in Third Quarter of 2013’ Available at:
  10. V&A Digital Media Department. ‘Digital Media at the V&A’ blog

2.      Look for the big wins

You can’t anticipate everything that is emerging. Technology changes can be complex to understand and the changes in social behaviour it causes are not easily predictable. The pragmatic approach to this is to identify any major trends and prioritise addressing them. The need to respond to web-enabled mobile phone behaviour was relatively recent. Just as this was becoming addressed, it was followed up by the rapid and relatively unexpected emergence of tablets and their different user behaviours.

While it is clear that this is a priority need, it may be that your technical environment does not allow the whole site to be changed at once, depending on what systems you use. Any plugins of third party transactional elements (usually payment gateways) may be difficult to transform. It is worth considering the usage trends. Assuming you have basic analytics in place, you should be able to drill down into the mobile stats to see where the largest audiences for mobile are on your site. You will find that not all content areas attract the same level of mobile use and this may help you assign scarce resources more effectively.


In 2012, we started rolling out responsive displays to the website, but like many websites, there are various types of pages with a number different layouts. We decided to start with the most commonly used ‘article’ template simply because we knew it would make the largest number of pages responsive in a single hit (several thousand). Once that was in place, we tackled the Home page, because that is our most popular landing page (and also obviously needed to be done). These are the decisions you need to make. Prioritise, implement and move on incrementally.

For details see the full write up of how we started this on the V&A Digital Media blog:

3.      Think contextual behaviours, not technologies

This is a subtle but important point. When you are considering to optimise a service for users, it is not the technology you need your service to respond to, it is the context that the user experiences when using that technology. This can be surprisingly complex and you need to consider the characteristics of technologies (screen size, weight, battery life, cost of data), the users’ consumption behaviour (information and facts fast, leisurely enjoyment, deep research, etc.), whether they are using a service alone or not and whether the need is for pleasure or necessity.


When we surveyed visitors to the galleries about their attitudes to mobile devices in 2012, we found their ownership of mobile and tablet devices exceeded the national average, but that while people frequently bring their mobile, they much less frequently bring their tablet. Evidence of behaviour like this helped us to prioritise some simple changes to our visit us pages to optimise them for mobiles, saving around 80% of load time for users.

This is discussed in this post:

4.      Your options depend on your circumstances

Unless you have unlimited resources (which means nobody), then you have to make some choices about where to prioritise change. Your options depend on your existing circumstances, how you currently deliver your services and how easy they are to change.  A basic choice that often needs to be made is whether to adapt your services to become responsive or to replace existing services with new ones that are responsive.

You also need to choose whether any changes or adaptations will be made in-house (if you have technical staff) or whether it is easier to outsource to a third party. The advantage of the former is that you will build in-house expertise, but the latter may be your only option if you do not have technical resource. It may also well be quicker to buy in expertise as required. If you have a technical solution that is near the end of its life expectancy, then you should seriously consider reviewing your overall platform. Similarly, if your organisation is considering changing any part of your web presence, you must ensure that your identified needs are scoped and communicated in the requirement documents used for procurement.

5.      Decouple frontend services from back end systems

This is an important principle. When you plan for responsive services, you are looking to make the audience facing service much more adaptable. Just as mobile responsiveness was rapidly followed by a need for tablet responsiveness, the way people will access the web will continue to change as technology progresses.

By separating the front end display development from the back end management functions when change happens, you don’t need to replace your entire business systems and processes which is expensive and difficult. Instead, you develop frontend services to respond to new contexts as they arise. The simplest way of thinking about this is to consider services as being comprised of modular components that can be connected together and parts exchanged as required.


In 2013, the V&A launched a digital explorer map, optimised for enjoyable exploration on a tablet. This feature demonstrates some of the principles of decoupling data and allowing rapid development to meet new user needs. In this case, as tablets emerged as the device of choice for leisurely web access we were able to develop the service without any new backend management changes in collections, events or content management systems.

For details of this development see this post:

Grids, ‘fluid’ displays and break points

Grids, fluid displays and break points are important concepts in responsive designs. Some sort of grid layout is the basis of many responsive designs. In this model, positioning of content and site features is made within blocks that can be rearranged and resized as required.

Using this model, an initial design process is to break down your content into blocks. For example, a menu may or may not need to exist on every layout in the same way or be offered in an abbreviated way. The navigation will usually be contained in its own block, as will content areas and so on. Working this out is what good web designers and developers do. It worth understanding these concepts so you can get help by prioritising the key content.

Break points are when one grid layout changes to another. They are triggered by settings detected by CSS or JavaScript about the device in use (frequently screen-width and sometimes orientation). The number of break points depends on the number of different displays you have decided you need to offer. The ‘upper’ trigger point of one display is the same as the ‘lower’ point of the next one and so on.

Within any one of the user contexts being address, the grid layout is not rigidly fixed, but is ‘fluid’. This simply means it is sized relatively to the screen size, so that it will fill out available space as required. This is the key concept that addresses the very many changing screen sizes that are available within consumer devices and will continue to appear.

In figure 2, on the V&A website there are two break points which are there to cope with mobiles, larger mobiles and smaller tablets and then anything larger like big tablets and desktop computers.

  • At smaller screen sizes, the display is a single column to match 100% of the width of the screen and navigation is a single dropdown bar (pale blue, marked ‘sections’).
  • At medium screen sizes, there is a break point at 320px width, after which the display changes to a two column layout. This retains the single blue dropdown navigational bar. The two examples here (Samsung s4 and Kindle Fire) show the same display, but at different widths, illustrating the proportional ‘fluid’ sizing. In this view the two columns are set to 50% and combined fill the screen width.
  • At 640px, there is another breakpoint at which the full desktop layout is used. Although iPads are mobile devices, the screen width is more than 640px, so a full navigation and all columns can be used. The width of these columns is set at 33%.

Back to basics – start with simple html first

You simply cannot predict all the ways your audiences access web services and it is unrealistic to expect your services to be optimised for every user case. However, you can mitigate this risk by applying one simple principle: all your web services should be built up from standards compliant html first, then add on the extra responsive features in CSS and JavaScript later. By doing this, your services should work in at least a basic way for all users. This is also best practise for accessibility and SEO as it happens, so what’s not to like?

Some very basic technical stuff

Two versions of a page or a single page that adjusts to suit contexts?

There are two ways your services can react to users and adjust. In the past this was largely implemented using server-side detection. The web server worked out what device was accessing the service and sent an alternative page. Although some responsive features can be offered this way, it has an obvious disadvantage in that the list of possible devices needs updating as technology changes and the resource cost of maintaining at least 2 versions of a design.

Although server-side detection is still used for ‘sniffing’ which browser is being used, it is becoming less common.

Whether they are simple web pages or complex web applications, the services that gets delivered to your audiences’ devices are built from some basic building blocks. It is worth reviewing these, as it helps to see how responsive works.

HMTL – (HyperText Markup Language), this is the basic content page that defines what is text, what is a heading, beginnings and ends of sections and so on. It can also define what style need to be applied to any special elements. It also contains names for elements so that they can be identified and targeted by styles and scripts.

In more recent HTML 5, new tags have been introduced to make the basic layout clear. These include <section>, <article>,<footer>,<progress>,<nav> and so on. These are so-called semantic HTML5 tags, because they show what the element are there for more clearly. It makes applying styles easier too as you don’t need to use generic elements like <div> for everything.

CSS – Cascading Style Sheets. These define the look and feel of the page. When you apply different styles, the html page elements start to look different and will be positioned, coloured, moved, and so on.

JavaScript – this is code that runs in the web device to cause interactivity. This is used to enhance functionality and can triggered additional changes in addition to style changes (like loading things etc.)

While JavaScript and CSS make magic happen, it should be stressed that they still require solid, properly marked up HTML to be in place. This is because users will have a range of different ways of accessing your services, and only some and occasionally none of the CSS or JavaScript features may be working for a user on a specific device (e.g. an older phone), so the HTML is needed to maintain the underlying service. Again, this is a fundamental requirement for accessibility too.


  • A responsive design allows services to address the needs of the majority of your users by being flexible and adjusting the layout, form and function for the various devices they use.
  • The most common technique is to have scalable resizable blocks of content that can be re-displayed in optimised ways for alternative devices. These are most usually mobiles and tablets.
  • The blocks load with ‘fluid’ sizes within each display, which allows the content blocks to make best use of the space available.
  • Between each view, there is usually a continuously fluid resizing, commonly within a small number of defined break points at which the display grid and layout changes.
  • The basic building blocks for accessible responsive content features are simple semantic HTML elements that can be identified and styled as required by the devices.
  • CSS style sheets detect screen features and respond
  • Resources are finite. Prioritise your development based on evidence of user need, including web analytics and qualitative research that show the areas used most on mobile devices.
  • Your services will naturally attract various patterns of behaviour. Don’t assume one responsive design will cure everything. You may need to make other content changes such as reducing the number of pages because people have become used to long scrollable pages.
  • Procurement of services is an important way that change happens. Having a solid grounding in the basic principles will give you confidence to make informed decisions about supplier engagement (and help them too).

Cite as:
. "How to plan responsive web services: Notes." MW2014: Museums and the Web 2014. Published February 3, 2014. Consulted .

Leave a Reply