Building an Online Service: Golden Guidelines to Remember!
Tens if not hundreds of web services appear on the net every given day. Some of them do get the attention they deserve, yet a lot of them don’t. Now every service is different and causes of failure vary accordingly of course. Having tested many of today’s web2.0 services, I can confidently say that most of these services don’t fail because of a lack of functionality, but mainly because they fail to respect a set of basic guidelines that are often overlooked:
. A solid “raison d’etre”: the most obvious, yet the most important. Is there a market for your service? Does it solve at least one problem right and better than other services? Did you talk about your web service to friends and acquaintances with the same problem? Did they show vivid interest in your idea? Your online service really has to have a strong basic reason to exist.
. Easy (or no) registration. I think this is a fairly well understood practice nowadays, but there are still some services out there that ask you for your birth date and phone #. Yeah, yeah, sure you have to know your audience, but that’s something that can happen when you have reached the 100,000 user mark, and when your service has become so viral that people are willing to sacrifice a few minutes to have their account/page. Better yet, you can always organize surveys in exchange for some incentive when you need that data. And believe me that will dramatically reduce the bias of your data, since those users will be much less prone to entering fake information. If anything, users should be able to use your service without registering.
. Easy use cases: You have, on average, about 20 to 30 seconds to capture user’s attention. Most users will get bored (and probably never come back again) if they aren’t impressed in that short amount of time. Moreover, if they’re using another similar service, they would at least want the same level of simplicity and a more user-friendly environment. Not functionality, but user friendliness. Extra functionality is good but that’s currency you will use to build user loyalty, which by definition comes with time. Bottom line, you have a very short amount of time to make a good impression and it has to be Good! You don’t have a second chance. Keep things simple and you’ll be amazed by the results.
. “Light” home pages / landing pages: don’t overload the initial page that a potential user will first use on your site; although bandwidth nowadays is not a problem for most internet users and hosting is cheaper than ever, still it is always a plus if your page loads quickly.
. Professional web interface: brand your pages well. Everything on the web has to do with design and layout, therefore, a visually pleasing interface is a must. That should not go against simplicity and loading speed though. Hire the right designer(s) to get this piece done if you don’t have the right skills. This is an area where you cannot afford to be cheap.
. Nicely trap all errors: In case your service is still beta and a bug appears in your application, graciously let the user know that an unexpected error occurred and that the development team will promptly look into it. Surprisingly enough, experience taught me that even the most average users have an idea of what a bug is and are forgiving in this respect. They will try again later provided they are treated with respect. And by respect, I mean they are not shown some cryptic message that even developers would have a hard time deciphering. Also make sure all these errors are properly logged and sent to the development team ASAP.
. Release gradually: Gradually unveiling your product to the outside world guarantees that you solve problems that may arise on a smaller scale, and also refine your product as you go with users’ feedback in mind. First you start with a private beta, where you use a handful of users to test your product (these are people you generally know fairly well- some of them might be members of your the team) . You use their feedback to get your product a bit more robust, then you release a public beta and test your product on a larger scale. Once you reach the right level of confidence about your product and add some of the requested features that your design team has overlooked, you can release it the public. This approach will almost never fail unless your product has really no reason to exist.
