In an earlier post I started to talk about the intrinsic value of usability for software products — the satisfaction and value that customers perceive about the product they bought and how it might map to and made the statement that usability should be viewed as important as any other aspect of the product development lifecycle and gave a few statistics to begin the support of my argument.  Now I want to delve into some specific examples of how excellent software usability principles can provide significant positive impact to achieving a company’s business objectives:

How Usability Impacts a Software Company’s Costs

• Reduced Engineering Costs: From a software company’s perspective this is the first, and often only consideration on usability.  The statistics are there to show that the majority of defects and re-work costs — up to 80% — come from omissions and mis-interpretations of requirements and related errors in design. To mitigate the disconnect, many companies have utilized visualization tools like iRise to help translate the intent of product managers and clarify requirements to software development teams, vastly reducing the number of defects that are injected into the code, which result in more re-work, development and test cycles.  This is especially useful in geographically distributed development organizations where communication and collaboration can be a challenge.  However, visualization is not the same as usability engineering.  It’s merely creates a representation of how one person believes the user interface should look like but does nothing to remove design or navigation flaws which w0uld still need to be fixed later on.  But usability engineering + visualization can make a real impact on the performance of the R&D organization.
• Fewer Support Incidents: For every problem that poor usability creates, resources have to be expended to resolve it and soothe the feelings of the customer and make them feel happy again with their purchase.  Now most companies put a lot of effort into coming up with ways to reduce their cost of delivering support services, using FAQs, self-service options and community-driven support.  But that addresses the symptoms, not the cause. The real, sustainable way to reduce support costs is to reduce the number of incoming service incidents.  Improving the usability of the product, making it easy to find, access and use features can go a long way in achieving that goal.

How Usability Positively Reinforces Your Customer Decision to Purchase

• Faster User Adoption, Improved User Productivity and Lower Training Costs: When companies buy software products they buy the promise that they’ll be able to do great things.  All the demos they’ve seen make it look easy to use.  Especially with enterprise software, they’re promised that their employees will be more efficient and their business will run more smoothly and profitably as a result.  But we know from our own experiences that when the vendor leaves, the implementation rarely looks like the demo.  Sometimes it’s because features aren’t turned on or configured properly, but more often than not it’s because the new software operates differently than the way employees have been performing the business process/task at hand.  There can be a significant learning curve, or worse a requirement that the customer changes their business process to fit the software rather than adapt the software to the process.  And the problem is often that there is a general lack of intuitiveness of how to use the product.  I look at my 5 year-old daughter when she uses my wife’s iPhone.  She picks it up and starts using it.  No training, no pouring through a user guide (although she can read at almost a second grade level…yes I’m a proud papa).  Menu-based navigation often leads users struggling to figure out where a certain function is hidden and almost often lacks contextual guides which automatically puts the next or adjacent activities within easy reach.  If more research and care was put into how users work, training budgets would be slashed dramatically, employees would move up the productivity curve faster, and companies would be able extract the value they thought they purchased more rapidly.
• Advocacy and Loyalty.  Building off the last point, happy customers happily, and often without prompting advocate for products that they enjoy using.  Look at how passionate Mac/iPhone owners are about their products.  Even when they bemoan AT&T, iPhone owners still proclaim the greatness of the device itself.  So in a world where people buy products increasingly based on peer recommendations and social platforms like Twitter give a voice to happy customers and connect them easily with prospective buyers.  They are your best and cheapest advertising.  Moreover, happy customers are fiercely loyal and have a selling cost of close to zero.  And in today’s software industry, where maintenance revenues are 4x new license sales, client retention is KPI #1.

Do you think your company invest enough in usability?  If you’re a product manager, how much of your budget and effort do you allocate to this topic?  Let me know.

The other day I responded to a tweet from James Urquhart that prompted an interesting discussion:

“Does a successful virtualization strategy take away from the ROI of cloud computing?” <- Interesting. Not enough to avoid cloud, me thinks.“

What that made me start to think about was the underlying value proposition and ROI of cloud computing and the juxtoposition of operational and financial goals.

Under Urquhart’s perspective, a company that has deployed a successful VM has a lower Cloud strategy ROI than a company that has not deployed VM.  This may be true from a raw number perspective because the company with the VM strategy is already getting much more benefit from their existing infrastructure.  But they may still fight problems with scalability, depending on the projected use of their application, which might push them towards the cloud.

But it brought me to a very practical question that few are talking about: “How can companies maximize the value from their existing IT infrastructure when planning a cloud strategy?” If the Cloud is all about ROI, how should companies factor in their existing investments?

Now most public cloud advocates talk about the Cloud as if there is no existing infrastructure.  All you hear is No CapEx, Lower OpEx, Unlimited Scalability, Superior Performance.  Yet most of the people they’re trying to sell to have hundreds of thousands, if not millions of dollars in infrastructure investments.  For those companies the ROI of the Cloud is a much more difficult proposition because it leaves them with dead assets.  Yes, they can try to re-purpose those assets to run other systems, but that would require some detailed analysis and planning of their entire infrastructure needs, look closely at when to retire servers or other equipment and build a phased plan to enter the Cloud.  Quite frankly that kind of analysis is probably long overdue anyways.  But in today’s economic environment – which is improving, yet still a long way from boom times – people are trying to figure out how to squeeze more value from what they already have, not how to abandon it more quickly.

And for those who are thinking about evaluating a private cloud strategy (although a cloud on your own infrastructure in my view is not a cloud), they may be able to get more value out of virtualization and other strategies, but they lose the operational efficiencies and instant scalability to match spikes in demand that the Cloud has to offer.  It’s an alternative to the public cloud, but in many cases still doesn’t solve the business problem that moving to the Cloud is supposed to address.  As an aside @krishnan wrote a good post on his own changing views regarding the debate between public and private clouds and helped spark a few ideas for this post.

So it leads me to this.  If “Cash for Clunkers” worked for the car industry (at least to the tune of 690K vehicles), why not bring the concept to the Cloud?  Why not “cash for Infrastructure”? When you think about it, it’s a virtual rush to acquire clients.  While there may not be true lock-in, it’s certainly a hassle to move operations from Cloud to Cloud, so it’s time to lock-up customers.  So why wouldn’t deep-pocked companies like Amazon, Google or Microsoft offer some sort of upfront cash for a company’s existing computing infrastructure assets to lock in a customer now?  Of course companies on the next tier like OpSource, Rackspace or GoGrid probably don’t have the resources to offer it, so they’re at a disadvantage.

Does anyone have the “onions” to make this offer?  I’m sure there are a lot of companies who’d be willing to take them up on it.  If any of the above companies run with my idea, I only want 0.5% of the assets they acquire in compensation

UPDATE: @lmacvittie had a great suggestion on Twitter to improve the idea. It doesn’t have to be cash. Even credits for cloud usage would be a good incentive. Maybe now guys like OpSource and Rackspace have a way to play.

Maybe it’s because I’m not a true gearhead, but for all the talk about new architectures and business models (which I myself engage in and am excited about) the usability often gets shuttered to the sidelines when talking about enterprise software.  And for the life of me I can’t figure out why.  You can argue (and I will) that a usability should get at least as much attention as the QA function, but in reality, most R&D organizations spend orders of magnitude more on testing than usability.

Let’s start with a few statistics around usability:

• Usability engineering has demonstrated reductions in the product-development cycle by over 33-50% (Bosert).
• 63% of all software projects overrun their budgetary estimates, with the top 4 reasons all related to unforeseen usability problems (Lederer and Prassad).
• The percentage of software code that is devoted to the interface has been rising over the years, with an average of 47-60% of the code devoted to the interface (MacIntyre et al.).
• Ricoh found that 95% of the respondents to a survey never used three key features deliberately added to the product to make it more appealing. Customers either didn’t know these features existed, didn’t know how to use them, or didn’t understand them (Nussbaum and Neff).
• 80% of maintenance is due to unmet or unforeseen user requirements; only 20% is due to bugs or reliability problems (Martin and McClure; Pressman)
• A user-centered approach raised customer satisfaction with 40% (Gartner)

Perhaps usability gets downplayed because it’s all about soft and squishy feelings rather than detailed specifications, counter to the predisposition of most engineers.  Usability is centered on psychology and physiology of the user.  The goal is to make products that are more satisfying to use, easier to use, more efficient to use.  But in order to achieve this you must first improve your understanding of the users’ needs: what are their actual goals, challenges and limitations with the existing alternatives?  Are there any unique or unexpected ways in which they use the product?

And there are many examples of how usabilty helps attract and win customers inside and outside of the software industry. Think about how you choose products in your daily life.  Cars, appliances, snowblowers (yes it’s almost that season).  I just went through the process of buying a car and looked at a dozen different vehicles.  It’s amazing the difference between the way each carmaker goes about creating their interior environment and which conveniences they leave in or keep out.  How the layout makes you feel when you sit in the car and turn it on have as much if not more to do with your perception of the car then when you put your foot on the pedal.  Acura and Honda make very nice cars, but time and again the reviewers pilloried them for one of the most confusing center stacks in the business.  And for any of you who bought a BMW when their iDrive system first came out, did you buy a new BMW when the time came?

In the software industry Apple is the most obvious example.  Usability is the basis for the aura that Apple has created around it’s brand and a large part of why Apple customers are happy customers.  The iPod met tremendous success in large part to the simplicity of the wheel interface and now the iPhone/iPod Touch has reset the standard with touchscreens and cover flow technology.  Even when Apple runs advertising, the attributes they tout are rarely features (other than ground-breaking concepts like ‘cut and paste’), but more on the experience and connection that customers have with the product.  I mean, don’t you want to be as happy as Mac customers?  Moreover, Apple has been able to get premium pricing for their products — with inferior raw specs (e.g. small hard drives) — because they are intuitive, easy to use and they work.

TweetDeck I think is another great example of superior user-centered design.  It saw quick adoption and perhaps even quicker ripping-off of it’s UI.  Some may say imitation is the sincerest for of flattery, but I think it’s the best indication of intellectual laziness.

And what I wish more software companies would understand is that it’s not just about a pretty interface. Most of the UI projects we’ve seen at my company, Symphony Services, are driven by clients who want to update their UI, but the focus is on simply modernizing the look of their application, not necessarily in making and significant changes to what they have today.  Buzzwords like RIA and Flex abound in these conversations, but it’s all treated in a cursory fashion and does nothing to change the current user experience. The use of RIA’s may look nice and help in the marketing and launch of new versions of the product, but in the end it’s all lipstick on the pig and won’t move the needle.

In my next post I’ll dig into a few of the ways that a great UI can impact a software companies business and improve customer satisfaction.

Dani Shomron had an interesting blog post over the weekend discussing some reasons ‘Why Traditional [On Premise] ISVs Will Fail on SaaS’.  In the post, where he compares traditional ISV’s to dinosaurs, he makes an excellent point that it often comes down to a DNA issue.  ISVs “have a product view, not a service view. Their emphasis is on features not serviceability.”  I think it’s a very valid observation.  Clearly there are significant philosophical and organizational changes that are required when an company shifts from an On Premise to an On Demand model.

But there are a couple of key points that I think Dani misses on.

First, the mastodon in the room to borrow a phrase, is that most ISVs have an overwhelming desire to protect  current revenue streams (i.e. the status quo).  They don’t have the real committment to or belief in SaaS, but offer it as an afterthought, if at all.  And often it’s done under the auspices of opening new market segments (e.g. SAP’s contention that their Business ByDesign SaaS offering is an alternative for small to medium businesses that can’t afford their core product) or as a defensive measure.  With that perspective the organizational changes that Dani talks about will never be achieved.  But that’s OK because the wholesale move to SaaS is not the desired outcome.

In Dani’s example of a company that made the committment to shift to an On Demand model, he highlights the fact that the Board brought in a new CEO and changed almost the entire executive staff — save the VP, Engineering.  I don’t doubt that these moves were criticial to success in that situation.  Now I understand that perhaps there’s a feeling that you need to keep the technical talent that knows the product.  But this is a decision that I think can really kill the transition from OP to OD.  Dani was 100% right about need to to have a “service” view versus a “product” view and understanding the need for “serviceability”.  But this leads me to my second point.

As I had written before, one of the critical philosophical  changes that engineering organizations must make is to move from a purely software engineering mindset to a systems engineering mindset.  It’s so important that the engineering teams architect and design an On Demand system with data and application availability, reliability, security in mind and understand how changes in the application can affect operations.  If the engineering team gets that wrong all the other organizational changes will be for naught.

Time and again as we work with ISVs to evaluate On Premise to On Demand product transition strategies, we see that the evaluation of the current product’s ability to support an On Demand model is under-estimated, resulting in unrealistic expectations.  Therefore, making sure that the engineering organization has the underlying On Demand DNA is extremely critical to a smooth transition.

Well many software and Internet companies have had their heads between their legs the last 8-10 months as credit markets tightened, the recession worsened and the future became more cloudy.  Well there’s signs that there’s a light at the end of the tunnel and it’s not an oncoming train.

TechCrunch’s Sarah Lacey talked about a coming IPO boom, noting that IPO registrations are up, but it isn’t only for the uber-platforms like social networking giants Facebook and LinkedIN, but a broader rally that includes smaller companies like OpenTable.

In talking to clients and prospects we’re also seeing a thaw in the market and companies are gaining confidence and visibility into the future, bringing projects back on line that have been on hold for a while.  Are you seeing the same positive signs at your company?