However, we're noticing a number of these companies are jumping head first into a train wreck - spending top dollar to hire designers and build a UX team, but making frustratingly little progress.

There are a whole host of reasons why this happens, but we've found the root cause tends to have something to do with having the wrong skills, or someone too junior, on the job. More specifically, it tends to be one of the following 3 reasons:

Psychological Factors
There's a basic human psychology that connects how users purchase or download your application with how they feel about its usefulness. The industry is rightfully focused on making the product usable once downloaded, but those who recognize usability starts before the app is downloaded are one step ahead.

But recently, Uri Neren, founder of The World Database of Innovation initiative, wrote an article announcing the complete opposite: the number one key to innovation is not the blue sky approach, but an approach involving constraint, scarcity, and closed world thinking. 

Neren works in collaboration with several universities to profile the world's innovation leaders and commonalities amongst successful innovators. What they've found is that there are a number of repeatable methodologies for coming up with innovative solutions. The one thing they all have in common - they deliberately impose “subtraction”, constraint”, and “closed world” techniques on product development teams to spur new ideas. 

Having worked at Macadamian for 8 years in software product creation, I realize that a lot of the successful innovations we’ve helped organizations develop have actually been consistent with this idea of constraint.

What’s the difference between usable and useful?

Useful – a useful app makes your life, or a task in your life, easier. For example, most mobile banking apps are useful – they let you check your bank balance on the go, or transfer money from account to account while waiting for a flight as you remember that you wrote a big check that might bounce. 

Usable – a usable app is one in which you don’t want to smash your smartphone into bite-sized pieces after using it. 

You can be:

• useful, and not usable (seemingly, every Craigslist-browsing iPhone app I’ve tried so far falls in this category), 

or 

• usable and not useful (the ThatsWhatSheSaid app is a good example - easy to use but utterly useless, unless your use-case is clearing the seat beside you on public transit).

Ultimately, an app that is both useful and usable will be a hit.

But for every monumental success like Angry Birds, there are thousands of apps that fail. iTunes alone boasts 330,000 mobile apps, and this number is in the millions when you consider other app stores, direct downloads, and mobile web applications.

At Macadamian, we’re constantly developing new mobile products for our customers, and over the course of the year we’ve distilled 5 key elements that make the difference between a mobile product that becomes part of your customer’s daily lifestyle, and a product that is lost in the shuffle, “collecting dust”.

I’m going to give you a sneak peak into each key element today, and in the next 5 releases of the Critical Path, we’ll tackle each one in depth.

The Talent Code is a remarkable book that every manager, coach, and leader should read. Performance coach Nikki Neumerof, who works with executives and sports stars to help them reach breakthrough levels of performance, recommended it to me.  The book breaks down the brain science behind how talent develops - how people become truly exceptional at something, whether it be tennis, playing the viola, or business.

There are a number of factors that either encourage or stifle innovation – your company’s tolerance for failure, the time you invest in invention and innovation, and the type of people you hire. These alone will not bring repeatable success; you need systematic ways of getting closer to your customer and capturing the insights that result. The User Centered Design process can help you do that. It gives you the tools and a repeatable process to uncover customer needs, and innovate both in the “what” – new capabilities and new feature sets, and the “how” – simplifying someone’s workflow. ]]> Thu, 28 Oct 2010 13:34:08 -0400 http://www.macadamian.com/insight/critical_path_detail/can_beta_testing_and_product_analytics_replace_usability_testing/ http://www.macadamian.com/insight/critical_path_detail/can_beta_testing_and_product_analytics_replace_usability_testing/#When:22:18:53Z Back in the day (i.e, the late 90s), when Nirvana, plaid jackets, and desktop software were all the rage, most of us built software using a waterfall process. Before we released to gold master, we usually did a Beta release. Beta, depending who you worked for, meant either "pretty much ready for release" or "feature complete but buggy as hell". Beta testers were typically fans of the product, and technically savvy.

Fast forward to 2010. Most software teams are now working in an agile model, and we're releasing products on the Web and mobile. Our products are in a continual state of release where we're making continuous improvements and releasing bug fixes and new features monthly. Some products, like GMail, have been in Beta for over a year as they continually refine the product. We can also A/B test, where we can release two different versions of the software to two different audiences, and test which gets the best conversions or the best customer feedback. We have analytics that can give us instant feedback on who is using what part of the product when, and we have more usage data than we can possibly digest.

With the ability to get rapid feedback from thousands of users and iterate overnight, and with so much data on product usage, do we still need usability testing? Aren't we getting all the customer feedback we need?

Yes and no.

How do you get past the arguing, make a decision, and get on with the project? We find that the following three simple rules will help you get past 90% of the design review roadblocks and get back to work. 

So, let’s say you’re creating a very technical product, like a network management system or an IDE, where the user is very technical, just like you. Or let’s say you are the product manager for a healthcare product, and it so happens you are a doctor by trade, so the user is just like you.  You should have a pretty good idea of how to design the product, right? In fact, it should be a piece of cake to design a usable product.

Wrong.