At some point during building a new web project we will define a browser support matrix. But if we’re honest, how do we usually define this list? Developers tend to add their bias regarding old, or browsers that don’t support all modern code standards. Other people in a project prefer to look into the current web server statistics and base their decision on these numbers. Both approaches are not correct though, and here’s why.

The Developer Bias

Every developer will understand and admit that we’re biased which browsers we want to support. Therefore a decision made with that bias will likely not reflect reality of people who will try to access the website/app.

The Analytics Fallacy

Okay, instead we’re now going to look at the current analytics data that we have from the current project. I mean, wouldn’t it be great if we build browser support based on who really uses our services?

The fallacy here is that this takes an existing project’s data and assumes that the audience will be the same. If we do that, we can be very assured that the audience will be the same. But this isn’t great. By taking the existing data we admit that we don’t want to provide a better solution to more people. People that couldn’t access the website before will likely not be able to do so in future. And these people won’t show up in your analytics.

When building an international website, have you considered that your Google Analytics will lack data from China? In China, Google Analytics is blocked at government-level, so all Chinese users won’t show up in your statistics. Now, with that in mind, would you reconsider supporting UC Browser if you know that you have thousands of users from China accessing your website via this mobile browser? In fact, for Asia, this browser accounts for 17.4% of the traffic (as of December 2016), more than Firefox or Internet Explorer together.

If your business or service should be available in Africa, have you considered that 35.4% (as of December 2016) of people there use a mobile phone and Opera Mini as a browser to access websites? Opera Mini here is on a race with Chrome for the number one position and quite even with it, leaving all common other browsers way behind. Now remember how Opera Mini works: It’s a proxy browser that won’t show up with its real user-requests in your Google Analytics as well.

With that facts in mind, we realize that we need to rethink our way to decide for browser support.

The Need for Assumptions

One way of defining proper browser support is to look at your actual statistics and try to figure out where there could be issues. If your website isn’t responsive yet, consider how different the numbers would look like if the project would be a great experience on a variety of devices, not only on Desktop or mainstream smartphones. If your website doesn’t have users from certain countries or continents, consider why that is and think about what needs to be done to include people from these countries. Think about connectivity, costs for internet access, different devices, different languages. The Web Worldwide helps you getting more context on that; it’s a research by Akamai, one of the biggest content delivery service providers worldwide and shows how people in different countries are connected to the internet with which connection speed and on which type of network and how much this costs them.

You see that I want to you assume what users your platform could get if only the circumstances are good for them. By doing that, we can suddenly think of reaching millions of new users with the project. Now it’s time to think about the consequences of including all of these possible users.

The Need for Trade-Offs

It’s clear that it would be a desire now for any product owner to reach all users worldwide. Unfortunately, nearly all capacities at projects are limited. This means we need and should find trade-offs now, and this is totally fine as we have thought of the available chances and now are able to evaluate how important they are for the project.

If your product affects German people, it’s okay to not translate the project into 42 or more languages. We should not forget to target as many users as possible, so a German language and English language for the non-German-speaking people living in Germany would still be desired. As the audience is Germany, we could happily decide now that we don’t need to support UC Browser (it’s not a thing here), and we can also think about not supporting Opera Mini (not much used here). We could decide not to host the infrastructure on Amazon Web Services or Google Cloud Engine and not to use a global CDN for it, since this causes more work but little value for German users.

But if your project needs to be available worldwide, we need to make the trade-off on the developer side. We must provide a basic experience to all the people and if that means that we can’t use certain technologies, then it should be decided to not use the technology. It’s often that we choose developer convenience over users (and that could comply with projects like the local one described above) but now is not the case where we should.

The Roundup

By expanding our view from current users towards possible users we’re reframing our bias towards an opportunity and can turn a project into success by opening up the availability of it to more users than previously.

Lastly, I can recommend this article by Chris Zacharias who worked for YouTube back when he wrote it and how they experienced this on their platform: By reducing the page weight of YouTube, suddenly the number of users increased drastically.