Barter Economy
I had a lot of hope to get straight a whole week in a line of posts. Unfortunately, this week some person at work enforced some unrealistic task to be done. Therefore, I got tired to death on a daily basis, therefore going to bed ‘early’ and ’sleeping long’ (midnight to 7am) instead of continuing my series of posts on prerequisites needed for launching a social network. Anyways, my work hassles should not bother you (except you’ve got an interesting job for me).
Until now we mainly focused on how to make a person become a user of your service, next step to take is how to convince them your service is really a plus for their lives. — If you missed the previous parts of the series, here they are:
- Part I: some prerequisites to know before immersing into social land/social nets
- Part II: Don’t lock-in. Compete with free.
- Part III: Gaining users. Lessons learned from blogging.
- Part IV: Usability. To convince people of your service. Get out word of mouth.
- Part V: Winning people over by usability. But what about user profiles, data breaches and privacy concerns?
By the current post, I want to conclude with the sub-series on usability and bridge over to the next piece of prerequisites needed, knowledge on/understanding of communities, including the piece of crowdsourcing.
The previous post was a rather short one in terms of subjects covered. I touched the question of handing over personal data and risks of data breaches. (I’ve been in this field of subject a while ago but stopped ‘evangelizing’ on it.) The other thing issued was making a point or two in usability by designing a process of gradual engagement for your users-to-be instead of demanding exhaustive questionnaires to be filled out upfront. That might remind some of your potential users about unwelcome encounters with authorities, such as the need to make their taxes.
To summarize gradual engagement: It is a bit like becoming friends: You give info about yourself and you ask the other one about [their] private info only when necessary to comprehend what they just said. Like that, gradual engagement on a web service is asking for personal info only when service — technically, not politically — cannot get accomplished without that particular bit of data. Gradual engagement happens when you, as a service provider, stay out of that direct path the user wants to take, from where they currently are to where your service lays, i.e. where it unfolds itself and can be used. So, this that can be seen as a matter of usability and interaction design. — I assume, gradual engagement will take place the easier the more you stay away from staying the user in the way.
So, how can you progress further? What’s the next step? — We now came along all the way an individual takes to become a user of your service. Mostly, it is offering your service upfront and staying out of the way then. That kind of usability and interaction design makes a passer-by to become a user of your service — at least they give it a shot. But they might leave afterwards.
Why?
For a user it is attractive to get something out of your service, even more so if it is for free and if it is really contributing, really giving a benefit for the user’s life, making a positive difference. Therefore, to make a real difference, if you’re about to provide a service, you should make sure the user really wants it — not only they might want it. Common examples for such kinds of service — and implicitly fails — are so-called FAQs (frequently answered questions) which in reality resemble PR brochures. That’s really not what the user wants or even needs. — ‘Needs’, that’s the key here: What does the user need if they go to a FAQ? Probably some piece of info they didn’t find anywhere else. If anywhere else equals a PR brochure, the last the user wants of an FAQ is another piece of that brochure in the FAQ.
Therefore, if your goal is to develop (and therefore get) a service that gets welcomed by people, I think, first thing to do is to figure out the needs of those people you want to become users of your service. If your goals simply to attract (and keep) as many users as possible — e.g. to sell ads –, you are free to simply determine an arbritary field of hassle you want to enable the user to get rid of that hassle or at least get over obstacles that field features. Once you’ve determined that field of hassle you can go ahead and determine tools that match the individual hassles and help the user to get over them. That’s what the user needs and what they’d be thankful for if you’d provide them with these. Therefore — and in case usability is okay on your service — it’s likely people come to like your service and stay. It’s like making your service be a utility: People will know when they need it and come to use it then. If it’s not a utility — if you fail to make it become a utility — people will stay away.
Although it might help a lot if you go through these steps before you set your service live, there’s one remaining issue for you — how would you live by any such great service if it’s free?
Yepp, I hear you.
My approach to this is two-fold: First is what I gained from the experience that there’s not only the currency named ‘money’ (or capital being money), and second I see benefits from crowdsourcing.
First things first. Therefore let’s start by the not-money ‘currencies’/capital: Maybe you’ve heard of some of the more recent publicity stunts, like the guy who made the old story real, swapped items to finally get him a house. He started with a paperclip, and got the house, after a long series of swaps. (Recently I heard of a Me Too who successfully performed the very same stunt in Germany too.) Or you might have heard of the guy who offered a 1000 by 1000 pixels large area on his web page and successfully sold every single pixel of that area for one dollar. — What we’ve got here is a ‘currency’ named [public] attention. There’s no exchange rate for swapping this currency for another one, but at least there is a chance to do so. Other such currencies are how much a file costs in terms of download time or needed disk space, how much desktop real estate a tool demands on the screen, how much privacy you need to hand over to a web service or simply put what you get for what you give.
It’s a bit like economy in ancient times: You give something — e.g. a piece of functionality of your web service — and get something in return. — Well, keep your eyes open for what you might get for it in return, or set up your services in away that ensures you get something in return. Then the next step for you to take is to figure out what you can swap for what you just got. So, of course, you’ve got a lot of work — first figuring out, what hassle the user enable to fight, then what the user really wants, what they need as gear, tools, utility, setting up gradual engagement, usability and staying out of the way. All of that for free, nothing to rip out of the user for all that burden you pile up on you. And now, finally, I even demand you to figure out how to get money for it? — I must be crazy, mustn’t I?
Well, that’s the way economy works in the absence of scarcity of goods. Music industry has refused to take this way. See how they struggle(d). Same for movie marketers, software giants like Microsoft. See how all of them struggle. That’s the price to pay. But on the other hand, once you’re done with this and your service scales, the rouble might roll. See Facebook, MySpace and other recent grown-big ones. The Richter Scales is not just a video funny to watch.
My approach here is to set up win:win situations. I demanded you to keep your eyes open. So, what about such as avoiding a need to sign up in the first place or what about such simple things like tags?
Keeping the need for the sign-up out of sight gives your user the plus to, well, simply not needing to sign up. That is a shortcut over doing the sign-up first and becoming able to use your service only afterwards. It’s a win for them to save of the currency named time. On the other hand, for you that bears at least a triple-win: First, people who like your service will sign up the moment they decide they need to leave but will come back later and they want to re-use their works (e.g. family trees on itsyourtree.com) then. Second, if people figure your service does not provide them with what they need and they decide they won’t come back, you won’t need to waste a small amount of storage to keep their data. Third, rippling effects: People who enjoyed your service won’t even give a minor minus for the need to sign up upfrontly. Therefore their word will go out to their fellows, and it’ll be a positive word.
Did you ever think about tagging? It’s a great for users to have that tool at hand. It’s a great way to mark things and refind them later by looking for the exact marks. But what benefit is there for you as a service provider? Does it do anything else but eating up tons of disk space? — Well, if you don’t notice it, that’s probably what you will get out of giving your users a chance to tag. But, to reveal it, tags add up. User A tags item X by set a of tags, user B tags it by set b. And so on. If you look at the tags most often associated to an item you can conclude those tags probably describe the item most closely. Which enables you to offer another service: Finding similar things by comparing the tags of the current item with other items users tagged. (Last.FM does so to provide users with suggested music titles. You could use tags to direct/target ads (such as 43 Things does for Google Ads by tags given by the user to describe a goal). That way you can grow services. And certain services not necessary for your utility you could offer for a subscription fee. So does Xing do. (But beware of pruning your core utility! Users would take their consequences.)
Using that by-product of your users effectively is nothing but crowdsourcing. It uses the crowds to get some task done. Such as tagging all the items known to your service. Crowdsourcing is what usually takes place when you’ve got lots of users, which in turn often is true for social platforms. By what we finally approach the core topic, social networks. [t]