I have looked at a number of web services both from their inception and early alpha, to beta programs and later stage developed businesses. I have been doing this for years and it was definitely a highlight in thinking about my current role. Services have ranged from simple features that make an every day task easier, to a full blown subscription based service that operates independently of any other system. From publishing applications in the cloud, business efficiency apps, entertainment and media related services, and obscure tools and utilities, gaming and leisure tools – I have kicked the tires on quite a few systems.
While I am not claiming to be an expert in the area of user testing, application development and deployment, or launching a service I wanted to brainstorm about some potential areas of importance (to me) when thinking about launching a web service.
Analytics
Paramount from the time of launch are the analytics behind any web service. They provide clear insight into where traffic is coming from, where people are spending their time, and where any bottlenecks are occurring. They provide the best way to take an instant pulse of what is going on.
Areas within the realm of analytics range in theory and importance. One area that I spend a lot of time in are referral sources which provide transparency into where people come from before visiting your site.
Currently my two tools that I used for most sandbox projects are Google Analytics and Sitemeter. Both provide overlapping features, but I feel between the both of them I get the real time stats I want (SiteMeter) with the long term trends that I am able to pivot around all sorts of data points. In upcoming projects I have also become interested in trying out Mint – but have never used it personally on any sandbox project.
Scalability
Thinking about how your service will scale from the beginning can mean the difference between a scalable realistic launch with an expected interested and growth curve to a service that cannot handle the load of being linked for any number of social news sites that can bring your site down fast.
Realistic testing of a web service prior to launch is paramount. Hopefully you can do predictive load testing on both the servers themselves and stress test things from a front end user perspective. Overlooking the little things are why many people open the door early to family and friends, those trusted to tell you what is wrong in return for an early peek.
Speed
I have talked about the fact that speed is a feature before and I still stand behind that. The fact that Google results appear in less than 1 second can mean the perceived difference in relevance over another search engine that takes longer. Speed of a system can influence trust, perception, and return visits. I personally look negatively upon a service that delivers on what it promises, but in an unrealistic time frame. For example; if an office application “in the cloud” promises similar features to Microsoft Excel but navigating between cells takes greater than two seconds and calculations take multiple seconds, than the value of working in the application in a browser vs. on the desktop diminishes rapidly.
Deployment and Information
One of the areas that is sometimes overlooked when pulling the curtain back is being prepared for people to find every public facing point of your site. Below is my checklist of things to provide;
1. FAQ – frequently asked questions – usually preemptive of any real users but generated form the friends and family beta round discussed above. Generally, if one person asks you others will have the same question. This also provides an excellent place for someone who is coming through for the first time to get a general sense of
a. The name and short description of your service
b. The problem or purpose of your service
c. Who is behind the service and where it came from
d. Quick facts about the service
2. Contact Form – Whether you are a one man operation or a company filled with employees, having a proper contact form is very important. This also includes having a choice of an email address somewhere near, around, below, or close to the form itself. Give people the choice to fill out the form OR contact you directly. Many people tell me that this induces spam, sales contacts, waste of time contact, or otherwise. To these complaints I ask; How much is a customer worth who wants to get in touch with you? (translation: deal with the spam)
3. Who? All about the team
a. Since so many services are created by a small team or one person, do not be afraid to tell people what is behind the curtain. Having multiple email addresses such as sales@ support@ webmaster@ is confusing and will deter people from making contact. Rather have the form itself route things to the right person with a drop down, or have one clear delivery to everyone.
4. The problem – The solution
a. More often than not I stumble on what the purpose or meaning is behind something. By having this clearly defined can provide that clear concise communication you can get at if you simply drill down into the facts about the service.
Another thing to remember is what your service looks like to first time visitors. Logging into your service as a first time user can show how things look and feel the first time around without an account that is filled up.
To be continued…
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=8de1638b-7b97-40ef-9b42-5d10e8a1615a)




Pingback: My Sandbox Projects » Eninvent