Know Your Customer: How Web Analytics can save your IT applications team money

We’ve all dealt with requirements that were written by well-meaning, but Mosaiclogotechnology-confused procurement departments, or business users who believe that people still use the Mosaic Browser (my first graphical browser!). Few authors of quasi-technical requirements put much thought to the actual cost of implementing a modern, rich, dynamic web application on decade-old technology.

A purposely over-the-top hypothetical quote :

The application must support Microsoft Internet Explorer 5.0+, Netscape 4+ at a minimum graphical resolution of 800×600 pixels.

While you may at first chuckle at this obvious bit of anachronism, think back to the last system requirements you spec’ed out for a web application.

What browsers did you ask to support? Were you shocked when the development team told you you couldn’t have that cool AJAX drop-down because your browsers didn’t support it? Were you suprised when compromises had to be made to the look and feel, or flow of the application? How many users really use those old browsers, anyway? How many of your users do?

“They shoot browsers, don’t they?” — Jeremy Keith

Don’t know the answer? Don’t worry, it’s pretty common. A lot of businesses make requests for web-based applications without first doing internal due diligence to understand their target market. Sure, you can build a web application that settles for the lowest common denominator — but why sacrifice when you might not have to?

Understanding your users’ browsing platform should be one of the first steps to building requirements for projects that involve a significant IT spend on web application development, whether it be enhancements to existing applications, or greenfield development.

Here’s 4 reasons why skipping this important step of due diligence will cost you more money, or users, or attention:

  1. You’ll Be Too Conservative. Fearing that you’ll lose the 0.5% of users who may be on Internet Explorer 5.0, you’ll insist (against your CTO’s recommendation) that all users are important, and if it means sacrificing a few bells and whistles, so be it.
  2. You’ll Be Too Boring. You’ve heard about rich internet applications, Web 2.0, AJAX? If you’re trying to support these new technologies on browsers that are 5+ years old, forget it.
  3. You’ll Spend Too Much. The 80/20 rule will be in full effect when you realize late in the development cycle that no one tested with Netscape 7.2. “But it’s in the requirements document!” cries the project sponsor. Frantic testing will unveil the fact that half the functionality is broken or visually skewed. You fire the designer, and the project goes into a death march to the lowest common denominator.
  4. You’ll Be Unhappy with the Final Product. You’re building the web application to replace your mainframe claims processing system. Or your billing system. Or your financial forecasting package. And the final, boring mess will look exactly like what you had on your old green-screen system, except it’s different. Users are complaining that it’s not easy to use, and your CFO is now revisiting your ROI projections. Projects aren’t supposed to end like this… are they?

Fortunately, judicious use of web analytics and good old fashioned business analysis can provide you with concrete data to build a solid foundation of business cases and technical requirements. The chart below illustrates browser market share over the past 9 months:

Browser Stats April 2009

Source: StatCounter Global Stats, April 2009

You can see that the bulk of market share goes to a very small percentage of very modern and powerful browsers. How can this information help you? In Part 2 of this series, we’ll explore how up-front legwork in web application development can lead to a happy outcome for all.