Designing Scaling Projects
>A lot of times, people have ideas for apps or games that ultimately will rely on a lot of actual content. This generally is user-generated content, which is a smart model, as it has worked for tons of Web 2.0 companies such as Blogger, MySpace and Facebook. These sites work by providing potential users with rich content that they can access just by joining in, and existing users the ability to add to a content base that they can claim ownership of (this is my profile, these are my blog posts, or these are my friends).
The problem, of course, is that these potential apps don’t (yet) have any users, and thus, they have no content to draw new users in with, and nothing for anyone to yet take ownership of.
I have some ideas for how new applications can overcome this hurdle, but to protect client ideas, I’ll throw out a mythical application. Lets give it a really Web 2.0-y name, “CHECKR”. CHECKR is an application that let’s you scan product bar codes and write/share quick reviews of the product with people within the CHECKR universe or your friends on social media outlets.
Now obviously, when CHECKR first launches, it has 0 users and 0 reviews unique to CHECKR. How would you, as a user, feel if you downloaded this promising new application, only to find that there’s a vast wasteland of content? This dearth of content must be hidden at all costs!
One way to get started is to link your application up with a set of already-there data. Many services have APIs that would let you pull location data or information from them, within their guidelines. For instance, a similar database to what CHECKR is attempting to build can be found on Amazon.com, when a product is pulled up. Amazon has done a fantastic job of cultivating a culture of reviewers at the ready, and all of that data is sitting there on Amazon’s servers, hopefully waiting to be exploited with an API. Even if Amazon doesn’t allow that data to be mined, it’s almost assured they have competitors who do. Services like Yahoo! BOSS allow you to aggregate and shape your own custom search engine using data already mined. Parsing and presenting this data (initially) or using it as a “Reviews from Web” button (after version 2) would help ensure your users can use the app.
Second, sites like Amazon, but even more importantly, applications in this generation, generally do a very good job incorporating game elements into their review processes. Giving users virtual currency, badges, differently-colored usernames, special titles, and other minor rewards helps integrate them into the community you’re building.
Finally, a lot of applications (a LOT of applications) are ultimately drawing some marketing data from it’s users. The demographic data that would be required is hard to get… If you had an app you’d never heard of, and they suddenly asked your first name, last name, a photo, gender, home address, etc, what would your reaction be? For most people, it would be to run, but I bet many of you have shared that much and perhaps more to Facebook. The difference between your idea and Facebook is that Facebook has already demonstrated value. It’s like a pool party that you’re invited to where you can see everyone’s already jumped in and is having fun. It’s rather natural to want to join in.
Once CHECKR has demonstrated a use, and if I design it in such a way that people naturally want to give it good data instead of garbage data, people will populate it with rich analytics data. When people put their high school yearbook photos on Facebook, they are thinking that they’re sharing it with friends, not with Facebook. No one wants to tell Foursquare where they are, but they don’t mind telling their friends where to find them. If your users need to input their real names to ensure their friends can find them, or want to put their address in so they can find the hottest local reviews, then you’ve succeeded in rolling in the analytics into the application’s design naturally.
However, one thing to note is that as you move along through the process, that you roll out features that might “expose” your application’s lack of early content. While it may be cool a year down the line to have a badge for people who have done something in the application 25 times, to make that a search filter criterion in the application’s first iteration is to both put a feature that’s impossible to use, but also a feature that gives away your application’s newness.
Another way that you can avoid this is by building a scaling function directly into your application from the start: to say that when you have 0-10,000 users, the application is more forgiving with when it, say, leaves a posting active or how long it leaves a spot on a map marked. When it has 10,000-100,000 users, it can be less forgiving, and when it has more than 100,000, the application can assume the info is essentially in real time. In CHECKR, for instance, maybe I put a little pin on a map where someone has submitted a review “recently”. When I have only a few users, “recently” could mean within the last week. When CHECKR is a household name and verb, I can let reviews only stay on my map for a few hours. My goal, either way, is to hopefully ensure that the application looks the same to a guy who found it on day 1 as the guy who found it 3 years after it launches.
And ultimately, that’s my goal- I want to appear to be a tightly formed system that users will trust and populate. While I have moral qualms about harvesting analytical data from users, most app makers don’t. Yet, if they force users to give that data, they will end up with unsuccessful apps from at least one standpoint (either they get garbage data, no users or both).
