Product Development for Non Us Markets

December 2014. I’m on the phone with GoDaddy, from London, waiting on them to finish the phone verification for an EV HTTPS certificate. We’ve been waiting been two weeks so far.

GoDaddy:

“We called your office four hours ago. Nobody answered.”

Our conversation was at 8AM.

Not understanding timezones wasn’t the only thing that sucked about GoDaddy ^[1]. But is certainly one thing that companies outside the US frequently get wrong.

Even if you only cater to English-speaking markets, you’re addressing less than two thirds of the market by only focusing on the US. But here’s some good news:

Many successful companies spend very little on marketing: their main source of new customers is recommendations from previous customers. Here’s a bunch of simple ways to make things better for customers outside the US.

1. Find your user’s country

Computers shouldn’t ever ask you to do things that computers can do. Users hate select boxes. And having to find ‘Great Britain / United Kingdom / England’ in a massive list (which may or may not have some countries moved to the top) gets boring really quickly.

Just use a GeoIP database, they’re free and easy to implement. What about the rare case that the GeoIP guess is incorrect? Let the user change it. The point is to not waste your user’s time.

You could also use HTML5 location, but that requires users accept your location request, and we’re about reducing work, not adding to it. Additionally you don’t need the precise accuracy of HTML5 geolocation.

2. Don’t show US ‘state’ dropdowns to people outside the US

A lot of US based sites have dropdowns to pick a state, which they show everyone. People outside the US have to find a state called ‘outside the United States’ or ’non-US’ or ‘I don’t live in the US’ or some other nonsense. Again it may be buried in a list of US states.

Just don’t show this box to people outside the US. Better yet, remember that people hate select boxes - give them a text box, name it ‘state / county’ and let HTML5 autocomplete fill it out.

3. Don’t assume CCTLDs correspond to countries

While most companies with .fr domain names may be in France, the companies that use .io aren’t in the Indian Ocean.

Companies that serve startups see a lot of .co and .io domains. One of the things required for EV certificates is that companies have an entry in a qualified independent business registrar, who’ll review their entry before publishing. But some more ’enterprise’ business registrars, who are otherwise quite good, treat .co companies as Colombian: if a company needs to get a business directory entry added, it’s worth checking for CCTLDs and steering people away from that directory.

4. Don’t tell non-US customers times in PST or EST

You’re making your customers do arithmetic you should be doing. There’s no real delicate way to put this but:

It’s fine: you didn’t think, but now you know. Spend a moment on everytimezone.com and have some consideration for the people who pay you.

5. Show the customer’s local time in your admin tools

The local time gives a massive amount of context to an interaction. A customer query recieved first thing in the morning is more likely to be someone tackling something that’s been on their agenda. A query recieved at 4AM is likely to come from someone very concerned.

Someone might need to get home to see to see their family. You may need to call the customer at their office, or perform some other interaction that is normally only done during business hours. Being time-zone aware avoids hassling customers unnecessarily.

A user’s browser tells you their timezone - send it as part of their order, and display it when you’re looking at their orders.

6. Handle internationalized domain names

This is actually pretty easy, once you realise two important things:

• Unicode domain names are simply a display format - what’s shown as, eg, lancôme.fr in browsers (provided the browser uses French as a language) is actually set up in DNS as xn--lancme-lxa.fr (this latter format is called punycode).
• You can safely run the encoder/decoder over non-unicode domain names and the output will be the same as the input.

The JavaScript ‘punycode’ module does everything you need. You just need to encode when users give you domain names punycode.toASCII(domainName);, and decode when you’re showing domain names to users punycode.toUnicode(domainName);. Simple stuff.

7. Know the specific stuff for countries you care about the most

Sure, you don’t have time to implement consitionals for every country in the world. So think about it in terms of revenue: you should still know the quirks for the countries you deal with regularly.

We do a lot of business in the UK. The UK has ‘counties’, which are like states, but they’re not used in postal addresses and haven’t been for some time. Asking for ‘State/County’ in the UK is meaningless and a waste of time. So we don’t!

Conclusion

You don’t have to get everything perfect, and you don’t have to spend your life making small changes for every country: know what your largest non-US markets are, and put a little effort into the things that will make a big difference for them. With only a small investment in time you’ll easily win advocates in those markets.

_{[1] Actually, kudos to GoDaddy: I’ve met two founders of well known companies that started on the basis of GoDaddy being awful.}

_{[2] Thanks to quinnanya on Flickr for the pic!}