Wednesday, 15 February 2012

The Future of Beta... Iota.

Beta release.  It has been talked about over the last few years almost exclusively in relation to software.  A company designs a piece of software, sends out a ‘release candidate’, then later, releases a patch to finalize the product.  Or in the more modern case, they just never release the final product.  Only never ending patches, upgrades and versions.  This does offer them the ability to not have to have accountability for a faulty, unfinished product… “It’s a Beta.  It’s not finished yet.” or, “We are doing on going ‘in the wild testing’” all of which are well used terms.
We do find that there are two main kinds of Beta releases.  The first, has a set of features, which get subsequent upgrades with new features added and/or patches for the existing features.  The second, that has all the features included, but has certain features which have their abilities turned on at a later time.  We tend to see this type more often as a ‘trial version’ or ‘limited functionality trial’.   This you see in a basic version of Apple Quicktime, where ‘Pro’ upgrade is needed to access certain abilities.  Sometimes, these features are just hidden completely from the interface but if you could run them, they would work just fine.  This was the case with the ‘hidden’ flight simulator in Google Earth.  It was fully there, but you couldn’t access it’s functionality from the drop downs.
This Beta release business model has managed to quickly move from the confines of pure software to that grey area between software and hardware.  That place where the software which is Beta is responsible for the actual functionality of your hardware.  The drivers.  Firmware updates which increase, or expand, hardware’s features.  We see this all the time in computer hardware.  Mostly in processors, or graphic cards.  Through your computers BIOS you can overclock your CPU, make the hardware run faster.  You do tend to see it more overtly in graphic cards where the supplier actually releases an OC video card, or over clocked version.  In the hardware, there is nothing different between the OC video card and the regular version except that the instruction set tells it to run faster.
Now it is interesting to think what happens when we transpose this to mechanical products.  When we start to purposely under perform our offerings in order that we can boost performance later with a simple BIOS style upgrade.  I’m not talking about playing it safe and leaving room for wear and tear, or out of specification misuse from a safety stand point.  I’m talking about designing and building a product where we make it to perform at 110% but only allow it to perform at 90%, and then upgrade it to 100% later.  This psychologically goes to make the customer feel like they are getting something for free.  Makes them feel like the company is giving their old purchase a new lease on life.
Imagine if you buy a new car that has the actual ability to get 4L/100km and do 0~100km in 5.1 seconds with 250HP.   The thing is, they tell you that it only gets 5L/100km and does 0~100 in 6.1 seconds with 200HP.  So here you are with a detuned car and no clue that this is the case.  Now what if the company manufacturing the car releases a patch, or an upgrade that improves your vehicles fuel consumption and acceleration?  Well if you paid for the technology up front but didn’t know the real capabilities, then there is no cost to the manufacturer only a benefit of customer satisfaction.
This could become an interesting trend with lots of new questions to be asked.
Is it ethical for a company to do this?  What would be the backlash should one be found out?  Would it adversely effect a company’s brand image?  Do we as designers and strategists start to design overall solutions to this line of thinking?  Or, do we stand fast and oppose it should it be raised by other departments as a business model?  On one hand we could just play the Beta card.  “It was detuned to fit within ‘at the time engineering and testing parameters’, but after further testing, we found we could safely change the parameters within the current hardware configuration”.  On the other hand, as designers, we aim to make things usable and therefore beautiful, so retarding usefulness detracts from the beauty of our art.

No comments:

Post a Comment