January 29, 2008
Designing a social platform is in some ways similar to designing a competitive multi-player game. The following considers the implications of this similarity in some detail.
* * *
Today’s social networking platforms (platform here defined as a social site’s capability to offer third-party software to its users) are already diverse, yet their purpose is the same: providing users with reasons to return to said social site — reducing user fatigue and churn, increasing the elusive fun factor, adding value that the site itself does not have the resources, the expertise, or the inspiration to build.
Developers and the platform (its owners) each have a set of goals. Platform’s ability to achieve its goals is largely predicated on creating an environment where developers can reach as many of theirs as possible.
Platform developers have some or all of these goals:
- Earn money
- Acquire fame
- Procure intellectual stimulation
The goals of the platform, governed by the key purpose described above, are as follows:
- Attract and keep top developer talent
- Encourage development of net-positive products
- Maximize constructive competition among developers
- Minimize objectively net-negative developers & products
The platform owner wields the following controls: distribution (viral or direct), data from (and about) the users, access to platform-wide information, financial opportunity, and policy. Influencing developer behavior by managing their incentives via these controls is the elegant way to manage the platform towards its goals.
Having defined the absolute basics, it’s tempting to simply project them onto some classic game design text, but the result would necessarily be too abstract. Therefore, the following is a set of what I think are particularly representative examples mixed with some of the key principles themselves. It isn’t meant to be an exhaustive, or even an uncontroversial list. The purpose of this essay is only to convince the reader that a good way to consider social platform design is from the game design-theoretic perspective, not to prove the correctness of any one of the claims I make below. Also, as I think of more poignant examples, I will add them below.
Simplicity, Consistency, Fairness
Most critical of all, the platform must be perceived to be a fair (game), and winnable. If the game is revealed to be fixed, or simply tampered with by the platform, the players’ rational response would be to stop trusting the platform, and, more importantly, allow themselves to cheat.
It will be necessary to change the rules every once in a while. Announcing the changes early, giving the developers a chance to provide feedback to proposed changes (probably behind the scenes to avoid time-wasting lobbying), and disclosing the motivation behind the changes, are all useful.
It’s important for the platform owner to be prepared for some unexpected outcomes: for example, users might favor completely unanticipated applications, or a particularly unpleasant developer team might reach the victory condition fastest, etc.
Goals & Opposition
1. Simply linking developer’s financial interests to the desired behaviors on the platform is perhaps a little tricky (and rife with opportunity to cheat for the unethical developers), but there clearly are possibilities.
For example, if the platform offers revenue sharing, the platform’s “tax rate” can vary for developers exhibiting some desired behavior.
2. Fame is the best developer goal to exploit, since it applies to both commercial and hobbyist developers, though somewhat differently. Hobbyists simply want the bragging rights, commercial developers understand that fame is interchangeable with money. For those at the top of the charts, fame converts to better eCPMs and allocations from brand advertisers.
– because of its control over information, the platform can easily influence developers’ time horizon in applications’ features. Compelling developers to consider long-term user value is easily accomplished by defining and publishing the monthly active users (as opposed to daily) as the primary metric of success.
– conversely, providing daily active user information is also absolutely crucial in facilitating healthy competition among developers, and should be published as well to make sure best application practices proliferate as quickly as possible, though never as the primary success metric.
– prominently listing best-loved (highest user-rated) products that also have scale (to discourage hyping) will encourage developers to “bribe” users with features that are purely user-value oriented.
3. Catering to the need for intellectual stimulation is a little nebulous, but obvious at the same time. Designing the APIs in a particularly elegant way will naturally help bring in the best and the brightest engineers; throwing together something that barely does the job will inevitably turn off the elite. One subtler example: creating “simple” and “power developer” APIs will help the newcomer developers get up to speed very quickly, but not rob the advanced ones of the full power of the platform.
It’s worth pointing out that ultimately, until non-advertising business models are devised for social applications (and probably even after they are) valuable distribution (reach + frequency) is going to be the main underlying goal for all developers, commercial and otherwise. The examples above simply illustrate what the platform can do to refine the definition of “valuable distribution” for the developers.
The most critically acclaimed competitive multi-player games are often praised for their balance. With the goals clearly defined, the players are given a set of tools (skills, powers, etc) with which to achieve them. A key design goal is then to make sure that no one skill or power is so obviously superior to all others that the entire game collapses into all players exclusively using the superior tool non-stop.
Balance applies in social platform design in a slightly different (but highly relevant) way.
The platform’s most valuable control (and lure) is distribution, which is typically made available to the developer through the colloquially-termed “viral channels”. Perhaps the hardest task in social platform design is creating the rules and limits applying to viral channels.
If the viral channels were made completely unavailable, and the users would discover social applications through direct marketing only, the growth of even the best apps would be linear (this can be improved, but not very much). The platform would most likely see very little user traffic.
If the viral channels were made available in an effectively unlimited fashion, the goals being what they are, distribution-hungry developers would rapidly fall to spamming the social site’s user base. Yes, it’s simply bad, and it couldn’t happen to you, but consider the following thought experiment:
Imagine a door-to-door salesman, with a stack of marketing brochures, and a goal to get as many people as possible, as soon as possible, to accept one marketing brochure for their later perusal. The sales company states its belief that the best practice in this case is to knock on each door, introduce yourself, win over the affection of the home owner, and finally offer the brochure up. However, there is neither a penalty for nor a limit as to how many brochures the salesman can simply stuff into people’s mailboxes without any interaction with them. The sales company also publishes daily rankings of all the salespeople they have on payroll, and compensates people better the closer they are to the top. It’s also pretty clear from the numbers that some other salespeople are simply stuffing mailboxes. Our salesman is desperate to do good, but his bonus is getting cut down more and more, while everyone around him is cheating! The outcome is pretty obvious.
It is very much worth noting that the viral channels must never be allowed to become a substitute for retention, a way to mask attrition. They are a great way to rapidly grow something good, or bad. Assuming there will be an occasional “bad”, limiting these channels to the minimum power necessary to maintain good growth (but not overwhelming) for an application, and no more, is likely the best conceptual design.
Another way to attempt to balance things out is to keep viral channels relatively unlimited, but also emphasize the functionality to remove or de-install platform applications, make sure that users can easily rid themselves of an annoying or unwanted product. Although effective against application spam, this approach has the side effect of creating a new kind of a churn, fatiguing and frustrating the innocent users.
Game Play & Miscellany
1. It’s desirable to arbitrarily encourage “good” behavior by developers, disallowing or at least punishing abuse. it’s clear that encouraging “goodness” via pure policy and enforcement is long-term intractable, and possibly drives developers to build smaller, shallower products, to stay under the radar and abuse the platform from there.
2. It’s important to create what passes for a level-playing field, where though the best and strongest developers are obviously rewarded, not so much so that it discourages newcomers. Over-rewarding is a recipe for disaster.
Example: offering increased distribution power (better communication resources or direct promotion) in reward for some objectively-measured positive behavior could place the beneficiary so far ahead of its competitors that those will simply cease fighting and providing the winning developer with competitive motivation to innovate.
A good way to use additional-resources rewards is to take away the benefits automatically after some small numbers of days or hours, and reinstate them after a little while, if the developer’s positive behavior persists.
3. Zero-sum games are bad. “For me to win, everyone must lose” encourages scorched-earth approach to application building, and frequently harms the users. Creating opportunities for developers to collaborate, and benefit from this collaboration is a crucial defense against the cacophonous collateral damage of overzealous product promotion.
4. “Leveling up” is very important in RPG game design. There is generally a logarithmic nature to this process: a new entrant can gain a few levels relatively quickly, but as the levels increase, this process becomes harder and harder. This concept can be readily reused when designing a social platform: new applications and developers should receive automatic promotion, be given a short boost, an almost unfair running start over existing contenders, then left to compete with the established players. The key incentive balance here is to send an “it’s never too late to join” message to the incoming developers, while not frustrating the veterans trying to defend their dominance and hold on to their hard-earned leadership.
I think I will stop here for now.
There are lots of ways in which game design is nothing like social platform design. I tried to expose the similarities, while ignoring the differences. Everything I know about game design I learned by studying the online writings of Greg Costikyan, Dani Bunten Berry, and other game designers kind enough to share their insights.
January 24, 2008
Some of our products are skin-able, allowing users to express their opinions or state their affiliations within our products. These skins are mostly user submitted, but are published for all users to see and reuse, so we can observe some interesting things about skin usage and popularity.
Here’s the relative popularity of skins referring to NFL players (italicized) and US presidential candidates combined in a single list:
The absolute counts are quite large, the skin selection is exclusive (you cannot set more than one), the product audience is an important get-out-the-vote demographic, so the order of this list is at least somewhat significant. I read somewhere that Obama was favored on the internets (or is it just facebook?), and sure enough, he has over twice the “votes” of the next presidential candidate, but Tom Brady can definitely take him — he’s got almost a 20% lead over Barak.
January 22, 2008
I decided to jot down some observations and thoughts on launching successful social networking development platforms… like the one facebook launched at f8, Bebo’s clone of facebook’s, or the one MySpace will be launching, etc. This is a list of some observations of what facebook (and Bebo) did well pre-, at, and post-launch.
1. Create a feeling of technological openness. Top-notch developers love to know the ins and outs early – seeing the early bugs, unfinished features, etc. Visiting and engaging the CTOs of pre-launch partner companies will create instant camaraderie between the platform development team and the developer community.
2. Treat developers equally, but leverage the best ones by letting them closer in. After launch, quickly giving the technically superior developers direct access to members of the platform team (via a special email address and IM), will allow them to report and help debug real-time performance problems, and further cement the teams’ respect for each other.
3. Plan and manage a community, and introduce a community manager early – ideally, these are pretty technical people that gain fast credibility with hard-core developers. Introduce a few colorful personalities to make developers feel welcome, pre-launch. These people should organize meet-ups, participate in chats, IRC channels, mailing lists, visit companies in person. The key impression to create is that someone from the platform team is on your side, ready to plead your case to powers that be.
4. Shift the support/documentation load onto the early developers. Smaller developer groups will naturally seek to help each other, they will gladly participate in joint-effort projects to document the platform APIs, support each other technically, etc.
5. Respond very quickly to platform issues, and take the early scaling problems seriously. The feeling of “this must be really important to them” will carry a lot of weight with the developer community in the early days. Developers will stay up day and night to build great applications if they know the platform team is doing the same to support them.
6. Emphasize the money-making nature of the platform. The larger developer groups are going to be at least somewhat skeptical of the platform, since they are already working hard and have many real challenges. Bible-thumping the “you will make money” point will help keep developers focused during the early platform days.
7. Make your campus a place that developers very much want to visit. The invitation to visit should be a prize, a chance to hang out with the platform team and meet your heroes. Organize hackathons and coding parties welcoming all, but invite the key developers to visit the platform group separately. Having an inner-circle developer group will help handle future PR crises.
8. Pre- and over-communicate policy changes and make major changes with at least the perception of open debate. Nothing takes away from the credibility of the platform like a sudden negative change. The greatest impact is venture investors’ fear of instability, reducing its value as a legitimate investment opportunity. No matter how much money you have to throw at this initiative, having a few billion dollars of venture money will make a difference.
9. Make the #1 measurable goal of your PR team the amount of coverage that successful (or just interesting) developers get. People will jump through all kinds of hoops to be in the papers. Double so if the article lists them next to a [your] big brand.
10. Hold frequent developer events and invite leading developers to speak at those. Elevating developers (especially the smaller ones) to a pseudo-celebrity status can create a great deal of good will.