I have written a document about my feedback for improving LinkedIn and new feature proposal.
Summary
This paper contains my general feedback about LinkedIn and new feature proposal along with new theme. I consider myself a normal user of LinkedIn. It also contains new feature proposal from a perspective of a normal user who would like to see LinkedIn help him not only network professionally, but also advance professionally. The paper has two sections - Feedback and Proposed New Features. Section 'Feedback' provides my feedback and user experience of the site as it is today. Section 'Proposed New Features' provides how I would want to use LinkedIn to advance in my career.
You can read the rest of the paper here
Saturday, December 5, 2009
Wednesday, January 16, 2008
Product Design Part 4: Help customers buy into your offering.
IKEA might have a great sofa at a very reasonable price. But if I decide to purchase that, I have to start worrying about getting it delivered to my home. However, if IKEA comes up with a free delivery option, it could lead to increased sales. It is akin to Amazon's free shipping for orders above $25. The cost of free shipping adds to the cost of the product indirectly. But, this added cost of free shipping, will bring in more revenue in the long run.
For eg: Endless.com is an online store (backed by Amazon.com) that sells shoes and handbags. Historically, people are not comfortable buying these items online because of obvious reasons (reasons being size of shoes that fit your feet, texture of handbag's leather, and so on). In order to help people overcome the mental block, endless.com gives $5 back to customers if they choose next day shipping.
Thus, if you are innovating a product where you are faced with hand holding your potential customer to cross over the hump (read mental block for trying your new innovative product), then you HAVE to consider that as a concrete REQUIREMENT for your product design. The cost of hand holding your customer to cross over the hump has to be considered while designing your product. If it means shaving off certain feature of your product to give away free shipping, then so be it. Because, it is free shipping that is going to convert visitors to customers. Once, they become comfortable with the concept of your new innovative product, and they buy into your concept (which is utmost important) then you can start reaping benefits from that sell.
For eg: Endless.com is an online store (backed by Amazon.com) that sells shoes and handbags. Historically, people are not comfortable buying these items online because of obvious reasons (reasons being size of shoes that fit your feet, texture of handbag's leather, and so on). In order to help people overcome the mental block, endless.com gives $5 back to customers if they choose next day shipping.
Thus, if you are innovating a product where you are faced with hand holding your potential customer to cross over the hump (read mental block for trying your new innovative product), then you HAVE to consider that as a concrete REQUIREMENT for your product design. The cost of hand holding your customer to cross over the hump has to be considered while designing your product. If it means shaving off certain feature of your product to give away free shipping, then so be it. Because, it is free shipping that is going to convert visitors to customers. Once, they become comfortable with the concept of your new innovative product, and they buy into your concept (which is utmost important) then you can start reaping benefits from that sell.
Monday, December 3, 2007
Product Design Part 3: 'Getting used to' factor
So what is "getting-used-to" factor? If you want to get some task done using a software product, you just know how to do it as against to navigating your way through toolbars and menu items to figure out how to get a task done.
In case of consumer software product where the switching cost is almost zero, if the product is not easy to get used to, it would become an obstacle for reception of the product by consumers. If you are building a product that is a 10x better version of competing product that users are currently using, how easy are you making it for them to switch to your product. For eg: if you developing a state-of-the-art email client, will your users be able to come up to par with being familiar with your email client in less than 2 minutes after installing the product. If not, most likely users will form a first impression of your product that it is not easy to use and will simply continue using whatever they were before installing your product.
So, if you are making a product which will replace an existing competing product, one of the important criteria to keep in mind is the 'getting-used-to' factor. In this case, getting used to should be seamless.
In case of consumer software product where the switching cost is almost zero, if the product is not easy to get used to, it would become an obstacle for reception of the product by consumers. If you are building a product that is a 10x better version of competing product that users are currently using, how easy are you making it for them to switch to your product. For eg: if you developing a state-of-the-art email client, will your users be able to come up to par with being familiar with your email client in less than 2 minutes after installing the product. If not, most likely users will form a first impression of your product that it is not easy to use and will simply continue using whatever they were before installing your product.
So, if you are making a product which will replace an existing competing product, one of the important criteria to keep in mind is the 'getting-used-to' factor. In this case, getting used to should be seamless.
Thursday, November 8, 2007
Product Design Part 2: Iterative deliverables
Conventionally, product requirements are gathered by soliciting users for requirements. If the user is solicited for requirements, he will only be able to come up with some imaginative thoughts, but those might not necessarily be his real requirements.
Instead, give user a pilot product to use. Now you may ask how do you come up with a pilot product. Its a catch-22. Here is where you will be creating your differentiation or creating a new market altogether. You have to become a keen observer of the problem that you are trying to solve. Once you have intricate knowledge of the problem space, you can start to answer that by your pilot product. It is this pilot product that you provide to your users. Once the user has a tangible pilot product to play with, he will be able to point out shortcomings. Real requirements will only surface when he will be provided something tangible to play with. Here you should tap into the basic nature of us humans and that is we are experts at pointing out negatives in any walks of life. Give the user your prototype product, and he will easily be able to come up with a laundry list of shortcomings in your product. These shortcomings are your product's real requirements.
Instead, give user a pilot product to use. Now you may ask how do you come up with a pilot product. Its a catch-22. Here is where you will be creating your differentiation or creating a new market altogether. You have to become a keen observer of the problem that you are trying to solve. Once you have intricate knowledge of the problem space, you can start to answer that by your pilot product. It is this pilot product that you provide to your users. Once the user has a tangible pilot product to play with, he will be able to point out shortcomings. Real requirements will only surface when he will be provided something tangible to play with. Here you should tap into the basic nature of us humans and that is we are experts at pointing out negatives in any walks of life. Give the user your prototype product, and he will easily be able to come up with a laundry list of shortcomings in your product. These shortcomings are your product's real requirements.
Tuesday, October 23, 2007
Thoughts on Product Design
In coming weeks, I'll be writing a series of blog postings on the topic of 'product design'. Being in software industry for almost a decade now, I have come across software products fitting in the range from 'mediocre' to 'blow your mind' kind of products. I've also have avid interest and keen eye on design for non-software products too. I have always liked to import ingenious design ideas and get inspiration from them to apply it in the context of my work. I also like to debug the design thought process that goes behind great products. I'll be sharing my insights from such experiences in weeks ahead. Below is the first of ten part series of postings that I have planned.
Product Design Part 1: Keep Context in Mind. Let bigger picture define the smaller picture.
Let me ask you a simple question about designing a chair for kids in age group of 2-4 years. Should a kid's chair be designed to bear 50lbs or 200lbs? And no, I am not referring to designing chairs for obese kids who are weighing 200 lbs. This question is purely from a design standpoint taking into consideration the context in which the product, in this case - the chair, will be used. The logical answer to this question is a kid's chair should be able to bear about 50 lbs of weight because a kid of age 2-4 years would normally weigh in that range. But, if you take a step back, and see the usage of the chair in a bigger context, the answer would be 200lbs. Let me explain why. If you question the overall context in which the chair would be used, you would discover that the kids chair will not only be used by the kid himself. It would most likely also be used by an accompanying adult (parent, teacher, elder sibling). It would be inconvenient for the accompanying adult if the chair was not able to bear his weight. He would be either forced to kneel down to bring him to the level of the kid who is sitting on the chair, or bend from waist down. On the other hand, if the kid's chair was designed so that it could also bear the weight of an adult, it would make it so much more convenient. Had the context not been considered, the chair would not be able to deliver a 'wow' experience for an adult user.
While designing products, be it a kid's chair or enterprise software or whatever you are designing, it is necessary to extract the design requirements keeping the bigger picture in context. Context not only guides you to extract 'practical' design requirements, but it also protects you from feature creep. Any and every feature of the product has to make sense in the context of the bigger picture, the bigger context. Context helps you uncover features of the product that otherwise might not have been discovered with conventional way of thinking. This is as shown in the example of the designing kid's chair. Conventionally, a kid's chair would not have been designed to bear 200 lbs of weight. Only when you consider context, do you uncover such requirements. And it is such requirements that go into making products that deliver 'wow' experience to your dear customers.
Product Design Part 1: Keep Context in Mind. Let bigger picture define the smaller picture.
Let me ask you a simple question about designing a chair for kids in age group of 2-4 years. Should a kid's chair be designed to bear 50lbs or 200lbs? And no, I am not referring to designing chairs for obese kids who are weighing 200 lbs. This question is purely from a design standpoint taking into consideration the context in which the product, in this case - the chair, will be used. The logical answer to this question is a kid's chair should be able to bear about 50 lbs of weight because a kid of age 2-4 years would normally weigh in that range. But, if you take a step back, and see the usage of the chair in a bigger context, the answer would be 200lbs. Let me explain why. If you question the overall context in which the chair would be used, you would discover that the kids chair will not only be used by the kid himself. It would most likely also be used by an accompanying adult (parent, teacher, elder sibling). It would be inconvenient for the accompanying adult if the chair was not able to bear his weight. He would be either forced to kneel down to bring him to the level of the kid who is sitting on the chair, or bend from waist down. On the other hand, if the kid's chair was designed so that it could also bear the weight of an adult, it would make it so much more convenient. Had the context not been considered, the chair would not be able to deliver a 'wow' experience for an adult user.
While designing products, be it a kid's chair or enterprise software or whatever you are designing, it is necessary to extract the design requirements keeping the bigger picture in context. Context not only guides you to extract 'practical' design requirements, but it also protects you from feature creep. Any and every feature of the product has to make sense in the context of the bigger picture, the bigger context. Context helps you uncover features of the product that otherwise might not have been discovered with conventional way of thinking. This is as shown in the example of the designing kid's chair. Conventionally, a kid's chair would not have been designed to bear 200 lbs of weight. Only when you consider context, do you uncover such requirements. And it is such requirements that go into making products that deliver 'wow' experience to your dear customers.
Saturday, October 20, 2007
Is it just me or do you think that wikipedia could use better presentation of information?
Don't get me wrong. I am a big fan of wikipedia. I treat it as a good source of information, and hang out frequently devouring information on pages after pages on wikipedia. However, after reading some number of pages, it just starts to drag. Again, don't get me wrong. The information is wonderful, but the presentation needs some work. I can't tell exactly what is wrong. Maybe using a different font or maybe line spacing or maybe page layout might make the difference. Maybe all the pages have too many links and these links are blue and are underlined, which starts to hurt the eyes after some reading. I cannot precisely pinpoint what's wrong in the presentation of pages, but all I can tell that there's something missing.
In general, that's something I've always felt about software applications. Great applications have features that you won't even notice because such features just gel naturally with usability. However, when such features are absent, its just hard to define them. I guess that's what separates good applications from great ones.
Example:
1. In the browser, you use CTRL-F to find text on a webpage. In Internet Explorer, CTRL-F opens up a dialog box. You have to keep juggling this find dialog box as you search for the text on the webpage. In Firefox, CTRL-F makes search textfield and related buttons viewable at the bottom of the browser window which is just so convenient. Moreover, as you type the text in the search textfield, it changes background color of the textfield to red if it cannot find the text, or green if it can.
In general, that's something I've always felt about software applications. Great applications have features that you won't even notice because such features just gel naturally with usability. However, when such features are absent, its just hard to define them. I guess that's what separates good applications from great ones.
Example:
1. In the browser, you use CTRL-F to find text on a webpage. In Internet Explorer, CTRL-F opens up a dialog box. You have to keep juggling this find dialog box as you search for the text on the webpage. In Firefox, CTRL-F makes search textfield and related buttons viewable at the bottom of the browser window which is just so convenient. Moreover, as you type the text in the search textfield, it changes background color of the textfield to red if it cannot find the text, or green if it can.
Friday, August 3, 2007
Microsoft's Photosynth: Beauty lies in the eyes of your computer
From blogging standards, it ridiculously late to post about Microsoft's Photosynth technology. Its way too old news. But somehow, in the act of serendipity, I came across it recently, and was completely blown away with where this technology can take us. I am sure you will be blown away too. Wait until 4:05 minute into the video, where Blaise Aguera, chief architect of Photosynth, shows how a 3D image of the Notre Dame Cathedral that was reconstructed just using the pictures of it on flickr. You can also visit http://labs.live.com/photosynth/ for a web version that is shown in the video.
If you are short of time, scroll to 4:05 minute mark to see the 3D image of Notre Dame Cathedral.
If you are short of time, scroll to 4:05 minute mark to see the 3D image of Notre Dame Cathedral.
Subscribe to:
Posts (Atom)