The Web marches inexorably forward, and we love to see the innovations that come from that progress. But usually, a proportion of your users won’t see the new hotness. They’re stuck on an old ‘n busted browser that they either can’t update (because IE8 is the highest version of IE available for Windows XP, and corporate IT isn’t upgrading yet, and IT policy dictates IE only on the desktop) or won’t update (through sheer bloody-mindedness? I dunno…). So what do we as designers do?

There are two schools of thought here. One is right and good and just. The other is just wrong. Dirty, wrong and bad. Let’s deal with the bad first:

Graceful Degradation

Graceful degradation is the practice of building your web functionality so that it provides a certain level of user experience in more modern browsers, but it will also degrade gracefully to a lower level of user experience in older browsers. This lower level is not as nice to use for your site visitors, but it does still provide them with the basic functionality that they came to your site to use; things do not break for them.


Once the darling of the web community, graceful degradation fell from…ahem…”grace”…(thanks, I’m here all week…try the veal…) a few years ago when all of a sudden, everyone realized that building something and then making it partially work in other browsers (or, heaven forbid in this day and age of mobile devices, on other platforms) wasn’t the best way to go about development. Or, at the very least, it’s not ideal. So what’s the alternative?

Progressive Enhancement

This is the exact opposite approach:

[Progressive Enhancement] start[s] by establishing a basic level of user experience that all browsers will be able to provide when rendering your web site, but you also build in more advanced functionality that will automatically be available to browsers that can use it.


So while graceful degradation assumes complexity and tries to fix for older browsers, progressive enhancement assumes simple and builds complexity in as browsers become more capable.

How this applies in practice

By building your site and then removing functionality/design for older browsers (the graceful degradation approach) we’re providing a sub-par experience for what could amount to a significant proportion of your audience. On the other hand, by starting with a solid foundation, and building up we provide a consistent user experience that works everywhere, on every device, in all environments, and then adding features progressively as current (and future) browsers support them. This approach is future-proof.

So that user stuck on IE8 in their cubicle? A site built with the principles of progressive enhancement will work no matter what. It doesn’t matter that they’re on IE8. Sure, they may not see a few enhancements, but the core functionality and look of the site will be there, and it’ll look great to them.

Why choose progressive enhancement over graceful degradation? It’s the right thing to do for your users. But I’ll refer you back to the site yet again for their final word on the subject:

Progressive enhancement will make both the end users and you happier:

  • Regardless of environment and ability you deliver a product that works.
  • When a new browser comes out or a browser extension becomes widely adopted you can enhance to yet another level without having to touch the original solution — graceful degradation would require you to alter the original solution.
  • You allow technology to be what it is supposed to be — an aid to reach a goal faster than without it, not a “must” to be able to reach a goal in the first place.
  • If you need to add new features, you can do so after checking if they are supported at a certain stage, or you can add it to the most basic level of functionality and make it better in more sophisticated environments. In any case, the maintenance happens at the same spot and not in two different places. Keeping a progressively enhanced product up-to-date is much less work than maintaining two versions.


Subscribe to the Perficient Digital Weekly Digest

* indicates required