Naming sub-accounts to trigger intuition (and fun) around customer intentions

• by Ignacio Mas
• Jul 2, 2013
• 5 min

Along with MicroSave, Ignacio Mas shares his experiences and learnings from MetaMon project – that how difficult it is to create a generalizable metaphor for money management.

Imagine you are operating a mobile money system, and you want to enhance the service by offering digital jam jars, essentially sub-accounts to which the user can assign different purposes and characteristics. The first issue you’ll have is: what to call them?

That’s already different to the experience with traditional jam jars: because you experience actual jars as distinct physical entities, you know what each jar is for without having to give a moment’s thought to names. In the digital world, you’ll need names if you want to be able to tell them apart. Indeed, one of the biggest challenges with designing digital financial services is how explicit everything has got to be.

One option is to let the username them freely: education, bicycle, etc. There is a practical issue that it’ll test the patience and dexterity of most users if they have to enter such text on the tiny numeric keypads of ordinary mobile phones, and it will be outright infeasible for illiterate people.

I have suggested elsewhere that sub-accounts might be associated with dates, which are easier to enter (the month could be selectable from a menu, and the day-of-month is one or two digits). An added advantage with associating sub-accounts with dates is that they can be created on the fly, simply by sending money to oneself to a future date. In contrast, named accounts would need to be defined before money can be sent to them.

But there is a more fundamental problem with both user-defined names and dates: users may not have an explicit purpose or time horizon in mind, as they often deal with fuzzy goals: what does one type then? User-defined purposes and dates might work for shorter-term, date-bound payments such as when school fees are due or when a loan needs to be repaid. But it is less likely to work for situations when people want to accumulate value but hasn’t yet decided what exactly they will do with that money, or when they’ll need it by (e.g. when exactly a child might marry).

An alternative approach is to have the user select the name from a pre-defined list of options which are presented on the mobile phone. Based on some customer research, you could come up with a common list of jam jar purposes. The labels could be made fairly generic to capture fuzzier goals: education, transportation, home, my business… This is what most banks do today when they position multiple accounts for specialized uses. But there is a degree of prescription and inflexibility here which might put off some users. The market may interpret it as a solution for poor people who (it is felt) need to be told what to save for, and more educated, affluent ones may reject it. There is no scope for users to project their needs in any unique way, so there will be little sense of ownership over the sub-accounts.

How about –and here’s where the fun begins— presenting a list of label options which in themselves are not needs or goals but are suggestive enough to invite users to project their own purpose into them? It might be colors: from ice blue (education!) through deep black(my secret!) to red hot (vacation!). These names have much more emotional content already. Why not go the full length, and name the accounts directly from a list of emotions: I’m feeling virtuous, I’m feeling naughty, I’m feeling peckish, I’m feeling rich, I’m feeling lucky. I don’t need to illustrate their uses, do I?

But the reality is that people are not likely to forget the purpose of their jam jars, so perhaps the names should be more focused on reinforcing intended usage patterns, in terms of duration or size of goal or speed of money movement. Rather than concrete dates, names could represent fuzzier notions of time: next quarter, later, much later, who knows when. Or they could simply be cold numbers, standing in for rough size of goal: 100, 1k, 10k, 100k.

If you think these abstract notions are too far from people’s intuitions, one could use more concrete imagery. Names might be drawn from (localized) bodies of water: an ocean (longer-term, open-ended accumulation), a lake (mid-size, one-off project), a flowing stream (regular expenditures such as school fees), a seasonal torrent (the annual town festivity). Or they could be animals: a rabbit (pocket money), a gazelle (the goal you want to achieve in a rush), an elephant (the big one). I suspect, though, that these names are a tad too obvious, and may be seen more as prescriptive than merely suggestive.

In fact, why not prompt the user to combine names? Select the color red and the amount 10kand you’ve got the account 10k of red. One could also envision a hybrid system where, for example, users could send money to a couple of dates in the next quarter (for well-known recurrent expenditures such as rent on a plot of land, a loan repayment, and school fees), plus to a couple of colors (for fuzzier, longer-term goals).

Would you like your money to be like colors or emotions or animals? Imagine if that was the first question on an account opening form, what message of difference you’d be passing. Imagine the word of mouth as clients discuss with each other what each color or each body of water might mean. Imagine the segmentation possibilities, because of youth like names of cars and musical bands. Imagine that you introduced a new naming category every six months to keep your offer fresh.

If such naming conventions connected with people’s psychology, they would offer excellent opportunities for marketing and financial education. Do you have enough elephants in your portfolio? Is all your water free flowing? Do you want to cool down your flaming yellow/red portfolio?

The Metamon project showed us how difficult it is to create a generalizable metaphor for money management. Instead, invite each user to playfully develop the metaphor that works for him or her. This is mass customization at work. Give the naming power to people, so that they can own their system of virtual jars more fully and meaningfully.