840 days since this post was last revised. Specific details are likely out of date.

What are the pain points and considerations when large companies/applications move existing products into a single responsive codebase? The largest challenges are seldom technical. They are often cultural.

I have worked on a large number of responsive web projects; everything from small boutique sites, to large content driven websites, e-commerce sites and web applications. I relate this fact not to blow my own trumpet; merely to inform that I have not arrived at these conclusions based upon a single market area or industry type.

This post is not technical. It is a very high-level collection of meandering thoughts when it comes to implementing responsive web design projects at scale in larger organisations. It is perhaps more useful for stakeholders or team leaders than developers. If your company is about to start down this path I merely hope some of it may provide insight. Or comfort that your experience and difficulties are not unique.

A common desire

Large companies/establishments develop an appetite to move from a number of silo’d products and codebases (for example, a mobile site, tablet site, desktop site and any number of ‘apps’) to a responsive web design with a single codebase for any number of reasons. Here are some common ones:

  • A single shared product, built from a single codebase (rather than multiple silo’d codebases) enables more rapid innovation.
  • A single codebase can free up resource to work on new features (rather than implement the same feature in multiple products).
  • A single codebase allows new features to reach all customers at the same time, regardless of the device they use to interact with the company.
  • A single responsive codebase requires less developer resource to develop and maintain
  • A single responsive codebase can mitigate considerable volumes of support issues and product training

However, know this right now. As attractive as this all seems and sounds, working toward a single responsive codebase is not a path free from danger. However, I am in agreement with Horatio:

The measure may be thought bold, but I am of the opinion the boldest are the safest
Horatio Nelson, March 24th, 1801

Moving any number of disparate existing codebases into a single unified codebase should raise a number of concerns and thoughts. Furthermore it will likely require some fundamental shifts in the way you and your organisation build things currently. Let’s look at some typical areas that should be considered:

Why you are doing this? Document a responsive manifesto

Before setting out on a large responsive journey, I recommend writing a very short document, agreed upon as a pact (of sorts), the content of which should be agreed upon by all the ‘chiefs of staff’.

Briefly define why this responsive project is being undertaken. What does each party/stakeholder hope the benefits are of completing the project (easier feature development, less development time, reduced support etc).

When things get fraught and ugly (they often do), this is the document to which you can all refer back to, and remember why you set off on the journey in the first place.

Really large responsive builds often take more than a year, and should personnel come and go in that time, this single page document will also serve as the manifesto for your project.

How can a responsive web design enable faster product and feature iteration?

With the existing silo’d products of large companies, the time from new ideas to execution and ultimate release is unduly protracted. Perhaps understandable given that these ideas need to be synchronised across multiple silo’d products/teams with often diverse principals and guidelines (particularly for front-end code).

By developing for a single responsive product, features will be available to all users sooner and at once. When a feature/change is complete it’s complete. For every user.

The lack of repetition in itself reduces development time but you can probably do better still. But to achieve that aim can sometimes (it’s not always the case but in my experience it is usually the case) require a fundamental shift in the way new features are designed and developed.

However, this new approach typically enables faster product development that is farther reaching in the scope of users it will support. Let’s talk about that now.

Embrace a fundamental shift in feature development ideology

Often companies design and build features first, as they want them in a target device (iPhone for example) and then try to make that feature work the same way, or as close as possible, by adding code/script for less capable devices.

This approach makes the entire codebase larger than it need be for the overwhelming number of users with more capable devices (who can handle the feature as it was designed with relative ease).

However, an even greater cost is that subsequently, that ‘filler’ code can never be removed in future – just in case a user with that device shows up. This leads to a slow and bloated codebase that is hard to maintain.

It doesn’t have to be this way.

You can allow all users to achieve their objectives and provide the best possible experience for more capable devices at the same time. The two ideals are not mutually exclusive.

One concrete example: older Android devices can not handle horizontally scrolling panels (think iTunes store). Instead of adding JavaScript based controls to scroll panels forward and backward as a fallback pattern for Android 2.x devices, just allow the content to flow down the page. This is achieved simply with next to no additional code. The user still sees the content and can still choose from the items (the objective they need to complete). As no extra code was needed you have not created a maintenance burden for the future. Task parity, not visual parity.

Ensure that users can perform their objectives on any device (whatever that is for you, putting something in a cart etc) but accept that the way that objective is presented need not be identical across all devices.

This is a faster and more profitable approach. This is such an important point for stakeholders to grasp it bares reiterating. So I will.

A progressively enhanced experience is more cost effective

Owners of older, less capable devices, typically generate less profit for companies and require more support. By the same token, the numbers of these users will only ever diminish (no one is making old devices). At present, these older devices will always require more development time as they are less capable (you will need to work around their shortfalls to attempt to gain parity with more capable devices).

Crucially, this approach does not mean neglecting users of older devices. You will actually improve their experience and likely enjoy greater profitability from them. How so?

Allowing all users to achieve their objective

Users visit a site to achieve an objective: buy an item, read an article, whatever your users do.

So, when building new features it should be imperative to define the objective in two distinct ways:

  • What is the simplest and most accessible way possible to facilitate that objective in code and interface form – that becomes the ‘base’ experience.
  • What is the best possible way we can facilitate that objective in code and interface form – that becomes the ‘enhanced’ experience.

From the outset, the core experience is the default and this then gets enhanced for users when their device facilitates it. This way, the core experience usually comes ‘free’ as it is typically made up of the simplest possible code that gets re-used by the enhanced experience.

By starting with a solid and simple solution (albeit, typically less visually appealing) that even older devices can handle, there remains an completely inclusive core. Development time can then be concentrated on newer, more capable (usually profitable) devices. This is the essence of what is known in the development world as ‘progressive enhancement’.

To summarise: all features should be built quickly in the simplest and most accessible manner, then enhanced to perfection for more capable devices.

What does it mean for the developers of the existing silo’d products?

Moving from multiple products/codebases to a single code base should free-up existing development resource. This doesn’t mean it’s necessary to ‘let go’ of existing developer resource. This free resource can be used to greater effect. You have effectively just recruited a slew of skilled and trusted developers that crucially have a deep understanding of the product.

Rather than using developers to replicate functionality across multiple products (as is currently the case) they can be used to innovate and prototype new features that can be more easily rolled out. There is seldom a shortage of needs when it comes to developer resource!

I imagine right now you could relate a number of new ‘on a rainy day’ features you’d like to see completed? This approach could provide that ‘rainy day’.

What about apps

By building a single, responsive, codebase you will have the ability to enjoy the best of both native and web based applications. A hybrid application will be able to make use of the web version of the site but further enhance the experience with native functionality. Scanning in a credit card number from the camera, authorising payments via touch ID. These kinds of native features would be made possible with a hybrid application approach; only the differences/enhancements would need building. The core of the experience (the responsive web site) would again be shared.

Changing how designers solve visual problems

I typically work with designers so by way of example, I will relate the changes a responsive design tend to mean for them.

It will be preferable to create solutions/features with as little variation across screen types/sizes as possible.

That line can make designers hyperventilate so I’d better explain my reasoning.

From the users point of view, the more visual variations, the less familiarity for users who use a product on multiple devices (a common scenario).

From a product perspective, the more variation, the more code needed to make the variation possible. The more code, the slower the product and the more difficult it is to maintain in the long term.

The pursuit of a single ‘template’ for each page type that works across every viewport should not always be followed to the nth degree. It makes more sense to be pragmatic. For example, if a large viewport (screen size for the purpose of this discussion) makes a completely different template more suitable for the user, I don’t think we should avoid bringing in another template.

Therefore its preferable to solve a problem once, in a manner that is applicable and workable at all screen sizes. To exemplify, if you currently have three distinct products, with three distinct styles and you attempt to retain all three of these visual treatments for different screen-sizes in your new responsive product you have not succeeded. You have merely merged codebases, likely to provide negligible benefits over existing silo’d ones. That is not to say that visuals may not differ across viewports. At times it is essential and indeed preferable. However, ensure that these changes are for the right reasons (the user) and not convenience (we already made it that way in the past). It’s important to create enough identity in the component parts of your visual solutions (whether that be pull quotes for news sites, or sliders and widgets on apps) that they can perform their necessary function in whatever situation they find themselves.

Most importantly, if designers don’t usually have access to a front-end developer to prototype their ideas, make this change as soon as possible. Nothing brings a product on faster than being able to rapidly prototype new designs and features on the devices you expect them to be seen. If a picture speaks a thousand words, a prototype lets you live the experience first hand.

Settle internal disputes with agreed limits

Is the speed or the aesthetic of a product the most important? Some argue the former, others the latter. Neither is necessarily correct. However it is beyond dispute that performance is a feature:

In any good application team there will always be a war: speed vs aesthetics. The two aren’t necessarily exclusive but it’s not uncommon for developers to resist design features as they add to code bloat (and therefore impact speed) while designers push for new features as they benefit the user from a UI perspective (it’s no good having a blazing fast site/app if no-one wants to use it).

The key to deciding such disputes is limits. What is the maximum size or time you are prepared to accept for the product load (in data terms to the user and ‘time to glass’ from a usability point of view)? Set that limit. Agree on that limit. Right it down somewhere prominent. Do not deviate from that limit.
In future when it comes to implementing a new feature or visual variation, simply ask decide whether it can be implemented within that limit? If not, can it be achieved another way? Test it, refine it and make it work within budget or find another way.

Neglect documenting those limits at your peril!

Be kind to one another

Creating a single unified product at large scale can be a Herculean task. When a project of this size warrants the involvement of so many teams and departments it’s important to help each other out. Maybe you need to create something altogether new to support the new project. For example, perhaps you don’t currently have APIs available for certain data.
Don’t rush and cripple these things with impatience. Talk about them early and keep communications open. Get good people in place and let them do what it takes. If it is a feature that will likely be imperative to long-term success of your product, remember that you can often have things early but broken. It may be preferable to have things late but ‘right’.

Politics and all that nonsense

The politics rife in large organisations never ceases to amaze me but it exists regardless of my bemusement.

Regardless of your role in the company, if you are feeling pushed out, or feel your role is in jeopardy because of the impending change a responsive web design will bring, speak to someone. It will likely go one of two ways:

Either you are paranoid and it will allay your fears or you really are being pushed out, in which case you don’t want to work for these people anyway.


You are about to start something amazing. But remember a few things:

  • It’s not supposed to be easy
  • It’s (rarely) a matter of life and death so try not to lose sleep over it
  • Try and accommodate one another and the needs and challenges of each team
  • Remember why you are doing this (refer to the Responsive manifesto)
  • Put the users needs before your own, this will ensure the best decision
  • Normalise designs to provide familiarity for your multi device users
  • The fastest code is the code that isn’t written; minimise variation unless unavoidable
  • Progressively enhance the experience from accessible basics. That will reduce support and maintainability issues
  • Concentrate development effort on the newer and more capable devices, let go of pixel precision on ailing devices and platforms