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.
Monday, December 3, 2007
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.
Labels:
information design,
webpage design,
wikipedia
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.
Thursday, July 12, 2007
Customer service phone call - an opportunity to 'humanize' your business
Companies are becoming more and more inhuman when it comes to customer service support phone calls. They make the customer feel stupid by making them talk to their voice recognition software, and making their dear customer answer questions repeatedly until a robot correctly understands what is being said. Imagine the embarrassment when calling customer service while you are in a public place where there is a possibility of others overhearing you say 'internet connection down.....internet connection down' endless number of times in different accents just so that the voice recognition software understands what you are saying. Why do businesses today want to embarrass their customers. All this does is just create ill-feeling towards the company. Reducing the cost of customer support by using voice recognition software to automate tasks is a good idea, but is it really worth it when what it exactly does is create ill-feeling towards your business.
Instead, customer support call is a great opportunity to 'humanize' your business. Its a great opportunity to present a human side of your business. In case you have screwed up and your customers are calling you for that, its a great opportunity to let them talk to a live person who would be able to convey more humanly (and emotionally too) that you are aware of the issue and are trying your best to fix it. Customers wouldn't mind screw ups so much if they are assured that they are being worked on and will be fixed soon. Humanizing your business will create empathy towards your business in the hearts of your customer. It will only create more loyal customers. Imagine how ecstatic your customers would feel because they got a chance to talk to a live person straight away, when they were anticipating pressing numbers for different menu options or clearing their throat for preparing to speak to a voice recognition software.
When it comes to putting your customer service on steroids, following comes to my mind:
1. Have a front line of customer service representatives (and lots of them) just for triaging the call. This would give the impression to the customer that they had a chance to talk to a a live person right away. After this initial welcome and triaging of the call by a real human, it would make it less painful to wait on hold. Also since the call would be triaged by a human, it would be more routed correctly to related second-level of representative.
2. To make #1 even better, instead of putting customer on hold after triaging the call (by a real human), get a callback number from the customer and tell them you will call back in certain amount of time. This would free up the customer who would gladly accept the incoming call later from your customer service department.
Do the above options really cost companies too much when weighed in the loyal customers it would bring in. Would it really cost companies too much when weighed in the fact that happy customers will evangelize their business bringing in even more new customers. Is squeezing cost on customer service really a good idea? Instead, humanize your business and provide more humans on other side of the phone when your customers call in. All your customers want is to talk to a human instead of pressing number for endless menu options and repeatedly saying something which your voice recognition prompts them to say.
Instead, customer support call is a great opportunity to 'humanize' your business. Its a great opportunity to present a human side of your business. In case you have screwed up and your customers are calling you for that, its a great opportunity to let them talk to a live person who would be able to convey more humanly (and emotionally too) that you are aware of the issue and are trying your best to fix it. Customers wouldn't mind screw ups so much if they are assured that they are being worked on and will be fixed soon. Humanizing your business will create empathy towards your business in the hearts of your customer. It will only create more loyal customers. Imagine how ecstatic your customers would feel because they got a chance to talk to a live person straight away, when they were anticipating pressing numbers for different menu options or clearing their throat for preparing to speak to a voice recognition software.
When it comes to putting your customer service on steroids, following comes to my mind:
1. Have a front line of customer service representatives (and lots of them) just for triaging the call. This would give the impression to the customer that they had a chance to talk to a a live person right away. After this initial welcome and triaging of the call by a real human, it would make it less painful to wait on hold. Also since the call would be triaged by a human, it would be more routed correctly to related second-level of representative.
2. To make #1 even better, instead of putting customer on hold after triaging the call (by a real human), get a callback number from the customer and tell them you will call back in certain amount of time. This would free up the customer who would gladly accept the incoming call later from your customer service department.
Do the above options really cost companies too much when weighed in the loyal customers it would bring in. Would it really cost companies too much when weighed in the fact that happy customers will evangelize their business bringing in even more new customers. Is squeezing cost on customer service really a good idea? Instead, humanize your business and provide more humans on other side of the phone when your customers call in. All your customers want is to talk to a human instead of pressing number for endless menu options and repeatedly saying something which your voice recognition prompts them to say.
Wednesday, July 11, 2007
Amazon.com: Wish it had 'Wish Price' for items in 'Wish List'
For every product, there is a customer at a given price. 80GB iPod may retail at $333. Definitely, there will be customers living on cutting edge and are willing to pay that price. However, there will be many more potential buyers for the same iPod at say $250, and even more buyers at $200. Increase in sales volume can help bring down the price. Also, with consumer electronics product, price also decreases with time, at which point buyers who have waited to buy at lower prices will jump in. Currently, a large subset of consumers are willing to wait out for prices to fall over a period of time at which point it becomes affordable for them.
Instead of price being a function of time, price can still be shrinked by increasing volume. Increasing volume means aggregating more buyers to buy a particular product. Which better place to aggregate buyers than Amazon.com. Similar to 'Wish List', Amazon can introduce 'Wish Price' where users can specify their willingness to buy a particular product at a given price. 'Wish price' is the price users 'wish' the price was at which they are willing to buy the product.
Amazon can perfectly orchestrate such buyer aggregation (demand aggregation). It already has wish list of millions of Amazon users. All they have to do is add another 'Wish Price' dimension for items listed in customer's 'Wish List'. Once, Amazon is aware of this Wish Price, it can very well orchestrate the demand to subsidize the price. This way, Amazon would have shrunk the time by aggregating more demand, leading to lower prices.
Instead of price being a function of time, price can still be shrinked by increasing volume. Increasing volume means aggregating more buyers to buy a particular product. Which better place to aggregate buyers than Amazon.com. Similar to 'Wish List', Amazon can introduce 'Wish Price' where users can specify their willingness to buy a particular product at a given price. 'Wish price' is the price users 'wish' the price was at which they are willing to buy the product.
Amazon can perfectly orchestrate such buyer aggregation (demand aggregation). It already has wish list of millions of Amazon users. All they have to do is add another 'Wish Price' dimension for items listed in customer's 'Wish List'. Once, Amazon is aware of this Wish Price, it can very well orchestrate the demand to subsidize the price. This way, Amazon would have shrunk the time by aggregating more demand, leading to lower prices.
Subscribe to:
Posts (Atom)