We are in the midst of a quagmire, and not the giggidy giggidy alright kind…I’ve recently been tossed into the fray of deciding how best to determine a browser strategy that will meet both the needs of existing customers as well as not prevent our organization from adopting modern Web technologies that don’t necessarily yield the best results in legacy browsers.  For example, if you’re writing Angular applications, I am hopeful none of your users are on IE 9 or less – yes, some people are still using OLD IE browsers!  What does UX have to do with a company’s browser compatibility strategy?  After all, this is a technology decision right?  In my opinion, we should definitely be a strong voice in the decision, but shouldn’t own it.  Ensure your stakeholders understand the impacts of the decisions being made so that any browser compatibility initiatives are aligned both with end-user needs and business expectations.

A few quick takeaways for those who are into the brevity thing:

1) Know your users as well as where you want/need to be now and a few years from now – don’t get too bogged down into the details of the analysis, the major gotchas will become evident quickly (basically, you don’t need to know the entire picture before taking action).  The needs of an E-commerce site could be very different from an Enterprise site or Business-to-Business Web application.

2) There isn’t a single, one-size fits all solution (as always) – a prescriptive approach is necessary but must be precise and will be determined be each organization’s situation.

3) Pick an approach that is doable in your environment (current product road-map allows for work required to implement change, funds are available and management is behind funding these changes, expertise is available for the desired technologies, and the organization is ready and willing for change!)

The details…

Take the time to understand your users and what is driving their current usage patterns.  The more empirical usage data the better you’ll be able to focus on which facts require in-depth research! However, the usage data cannot stand on its own, it is imperative to know the “why” behind the “what”.  Do you have tech-forward adoption with new technologies or are your users stuck on legacy operating systems with legacy browsers?  Are your users in the process to upgrading and you don’t know?  These are just a couple of questions that could impact strategy that wouldn’t be understood from the raw data alone – some legwork and talking to your users is necessary.

What is industry doing?  Quick searches to industry leaders and competitor’s products will yield enlightening and straight-forward directions; some may work for your situation, some could lead to disastrous results.  Either way, it’s a positive step to investigate what other teams are doing to understand a baseline goal of what you should achieve and how to communicate the message appropriately with your users.

Once a basic understanding of how your products are being utilized is complete, it’s a good time to revisit what the organization was hoping to accomplish via potential changes and determine the correct course for action.  With route A, will your organization be maximizing future potential without jeopardizing current relationships?  With route B, will your organization be too focused on current relationships that don’t provide enough revenue and risk profitable, future relationships for the sake of ‘now’?  There are number of variables and we could go on and on, you have to choose what makes sense for your organization’s goals.  I chose to focus on products and customers that provide the most revenue and strategic importance in balance with which products had the highest usage.  For example, you may want to evaluate all the squeaky wheels to see if more resources are being spent to appease them than they are worth…it can be shocking sometimes.  It makes sense to focus on business-driven decisions in conjunction with the usage data to come up with a strategy that is timely and most importantly DOABLE.

It’s ineffective to develop a strategy on which your organization is not prepared to execute!

Testing – The Potential of the Problem

One of the first steps that should be taken is to test your products to ascertain the current level of compatibility across the browsers/versions that will be supported.  This simple exercise can actually be complicated because it will likely require your testing teams to have or emulate multiple browsers and modes.  In traditional IE shops, this will likely mean training and potentially some technology purchases as well.  In addition to the technical/practical changes required to test across browsers, you’re taking the testing teams away from scheduled test schedules…which will have a variety of impacts on established product delivery dates.  It’s essential to note the UI features that are problematic across browsers.  This way, the adoption of those problematic elements in future design/development efforts can be weighed with their necessity, usability, and impact of extra dev/test time required to manage them.  One thing to note is Internet Explorer and the variations of compatibility in native, compatibility and enterprise modes when a user is running IE11.  If you care about supporting legacy applications in modern browsers, evaluating the various mode combinations in IE11 may be a valuable option.  However, you may find that most of the issues are viewing modern applications in legacy browsers, especially any UIs that are laden with JavaScript.

All Aboard

Now is a great time to start getting all the internal stakeholder teams on board with what has been discovered.  The earlier the better.  You don’t want to surprise your product teams with a “hey, we’re now supporting x, y, and z, you better get on the train, it’s left the station” sort of impression.  Top down support is essential.  Influence management is a positive approach.  However, you may not have the time it will take to be effective via influence alone, especially in an organization supporting many sets of products when you’re trying to achieve a single strategy.

One decision to weigh heavily is what an organization will do with legacy application while they are tossing older for emerging technologies.  Is this a UX problem?  Well, it is if you’re dealing with an experience that spans multiple products/pages/applications that utilize different technologies and have different experiences in different browsers.  If your organization is adopting responsive/adaptive UI development techniques you may be able to leverage those practices as another method to address a product set with varying compatibility.  Specifically around users who have older browsers. Supplying different fidelity UX in an adaptive model will provide your users a positive experience. Those with older browsers can get dished content in a less dynamic/flashy UI than those with modern browsers, all the while the business logic remains the same.  But then again, this requires a disciplined development team and an abstracted UI layer…all of which come with a higher price tag to implement.

Does your shop have the expertise to support the development changes that will be coming? Is training feasible, how bout outsourcing?  How does the potential to outsource impact morale?  How will utilizing a set of new tools/practices be received?  All questions to consider!

Unless your organization has unlimited resources, prioritize the changes accordingly.  It’s unrealistic to think you’ll be able to make the changes all at once across all products.  Utilize whichever decision method makes sense for you organization to identify a set of ‘first round’ products to test and schedule development accordingly.  Then follow-up with the lesser priority products until the compliance review and execution is complete.

Where’s the Beef?

Or cheese I guess it should be…Where’s the money?  The plan is on paper, people have bought in…but nothing is going to happen unless dollars are allocated.  Dollars get the training, the outsourced help, the time allocated, etc.  This isn’t last, this is first.  However, having a clear view of where products stand and how big the problem is can paint a picture management can understand and buy into, literally.

One more thing to consider.

The allure of new technologies is going to outpace adoption; it takes too much time to get resources up to speed compared to the rate at which they’re coming on to the scene. This problem is exacerbated the greater an organization’s product set becomes. Industry trends like are competing and these days they are less stable, even the ones that do win out.  Angular is doing well, but Angular 2 is coming, there a dozen others out there doing OK,  Polymer is showing promise, who knows what else in the near future?  Regardless, it isn’t effective to adopt every year, or maybe it is for your organization?  However, more than likely, it makes sense to evaluate annually and plan for the next 2-3 years on as few of technology choices as possible and know the impacts of technology choices on your cross-browser compatibility.

In Closing

Regardless of technology choice, make a plan to support modern Web standards (like HTML5/CSS3) rather than certain browsers – If necessary for your users, ensure you maintain backward compatibility to suit the those needs.  Having an abstracted UI layer will ensure your products can be upgraded as new technology choices are made.

Before starting your browser strategy, these steps may be helpful to keep in mind:

  • Understand your users
  • Test your products across browsers you plan to support, document the current state of compliance and determine problem design elements that should be avoided
  • Determine if your current certification meets your user’s needs, both current and future
  • Develop a prioritized approach that is in alignment with your user’s needs, involve internal stakeholders in the planning to achieve maximum buy-in
  • Ensure the plan is doable within your environment, set your organization up for success
  • Communicate the plan with your customers
  • Rinse and repeat!