Real Ultimate Programming

The Home for People Who Like to Flip Out and Write Code

How Do You Balance Different Target Audiences With Different Needs

The Problem

Different groups of your users have different ways of handling the same basic tasks and/or data. Names and addresses are just two of the more common types of data that vary from culture to culture. So how do you handle this situation? The immediate impetus for this post is this proggit comment about names. I can see at least 3 different approaches, each of which has drawbacks.

The Strategies

Ignore the needs of the smaller target audience(s)

This is the one I’ve seen most often in the wild, and I can see it’s appeal: if you are only giving up a few potential users/customers, you’ll probably offset your losses by increasing your saturation in the supported target audience(s). Still, I always get a vague feeling of unease when I knowingly make it harder/impossible for a group of people to use my work.

Limit your functionality to the common subset

I don’t know that I’ve ever encountered this, and I can see why. When you get right down to it, there’s not much about this world that is constant across all places, people, and cultures. That doesn’t leave you a lot of functionality to put into your app. Even when there is a common subset, your different target audiences will probably still prefer to use an application/site that supports the nuances they are used to, and nuances are the first thing to go when you start chopping functionality down to a common subset, pretty much by definition.

Hide the functionality that is subject to change until you know which variant to expose

There are a couple of problems here:

  • You may not even need the information for anything else, and users are famously reluctant to give out personal info. If you do ask them for the information, please keep Application Design Mistake No. 9 in mind.
  • It may not be feasible to hide the functionality in question. If your application/site doesn’t require users to register, for example, then it might be hard to keep track of the information necessary to know which variant of the functionality to expose.

The “Solution”

In reality, I imagine most developers would prefer some mixture of the strategies listed above, though I could be wrong. What does your solution look like?

Back to flipping out…