Pogue’s Best of 2010

In case you missed it, David Pogue of the New York Times wrote up his Best Tech Ideas of the Year last December. It’s a delightfully stunning list of consumer innovations. Take for example the camera button on Windows Phone 7:

Microsoft Windows Phone 7 is a rival to the iPhone and Android phones, but with a genuinely fresh, smart design. One example: You can use the phone’s camera even when the phone itself is turned off. Just hold down the shutter button to turn on only the camera “side.” You spend less time fussing, waiting and missing photo ops.

And this gem from Chase Bank:

Any customer of Chase Bank (and some customers of USAA, which had the idea first) can deposit a check just by taking a picture of it with an iPhone or Android phone. That’s right: sign the back, use the app to photograph the front and back, type the amount, and tap send.

Things just keep getting better.

Chrome Drops the Bomb on Video

In a surprise move, Google announced that it would no longer support the ubiquitous H.264 video codec in their browser, Chrome.

Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

The user community is not happy and everyone is up in arms about the contentious decision, including some very funny satire by Microsoft’s Tim Sneath. Whether or not it’s a clever business decision or integrity-driven decision making, it’s not often that you see products pull features that everyone finds useful.

Everything Jeff Bezos Knows

Here’s a fun video that Amazon.com founder, Jeff Bezos, put together during the time they joined forces with Zappos.com in 2009. He talks about building products with a strong customer focus and his experience in creating thriving business cultures.

via Robin Zaragoza

Creating Customers In a Traffic Jam

Where there’s a need, there’s a solution people are willing to pay for…

BEIJING – “With more Chinese people getting behind the wheel every day, traffic jams are a major headache in most cities but the gridlock has become an opportunity for some entrepreneurs who are offering an escape route – for a price.  Drivers who get stuck in traffic in some cities can now get on their mobile phones and call for a substitute to take their cars to their destinations while the frustrated drivers are whisked away on the back of a motorcycle.”

via Carpe Diem

Profiting from Bad Design

When I was shopping around for a pocket camera last year, I wanted something with advanced features but small enough to carry around at all times. The Canon s90 seemed to fit the bill perfectly and I was pretty happy with the product. The specs looked great on paper, but in the hand, there was a major ergonomic issue that came to light. The Canon s90 uses a dial control on the back of the camera as a general purpose mechanism for navigation and settings changes. It’s a simple way to move around menus and options, but it’s so easy to move you find yourself inadvertently making changes all the time.

I wasn’t the only one that found the control dial a little annoying. Here are some choice review comments about the s90:

• “[The rear Control Dial...is so loose that] it’s a major liability when shooting with the Canon S90, because you have to check your settings all the time.” Imaging Resource
• “…the rear wheel is much too easy to move. If I’m simply trying to engage the flash, or bring up a menu (these buttons are located in the middle of the wheel), I’ve found myself accidentally changing some aspect of my shot on numerous occasions. It’s kind of annoying! gdgt
• “…Canon’s trademark spinning rear controller can be as frustrating as ever.” cnet.uk

Ouch.

In response to consumer complaints about the control wheel, Canon initially said “it’s a feature, not a bug” even though the vast majority of users were feeling the ill-effects. I don’t doubt that Canon has enough resources to spend on good industrial design, but this smells like one of those features that probably went all the way through acceptance testing because the design team didn’t use the product like a normal user. The backlash was pretty loud.

Ultimately Canon ended up producing a newer model camera. And kudos to them for addressing user gripes in their updated s95. A fascinating part about the whole discussion around the control dial is that an entire cottage industry grew around the s90′s usability problems. One company, Lensmate, produced a few add-ons that would improve the usability of the product, including the infamous control dial issue.

Hopefully the products that you have in the works don’t get far enough into the development cycle without catching these sorts of design problems. But sometimes they slip through cracks and that’s when keeping your ear to the ground, listening carefully to the user community and quickly responding can help turn those gripes into something users love.

Never Say ‘Submit’

Here’s a quickie but a goodie. Don’t label your buttons with ‘Submit’ – replace it with the immediate task that the user is engaged in. Try “Create Account” or “Send Message” instead. Quick, easy and better for the user.

Read more from UX Movement “Why Your Form Buttons Should Never Say Submit”

Feature Tip: Beware of Side-Effect Rules

If you are a product manager, you probably spend a fair amount of time writing specifications for all the great new ideas that you want to see built into your product. There are hundreds, even thousands of questions that need to be considered during feature development. One thing I want to highlight in this post is to be careful with features that affect other parts of the system in non-obvious ways.

For example, the investment management firm, T. Rowe Price, has a feature that allows online users to make IRA conversions with their funds. I’ve been a long time user and the newly updated UI is extremely well done. The conversion wizard steps the user through the process in a clear way, but I noticed some fine print at the bottom of one of the steps:

What’s happening here is that the process of going through the IRA conversion feature will turn off another feature that the user had setup in the past – specifically, it turns off automatic transactions into the account you want to convert. This is what I call a “side-effect” requirement – doing one action causes a ripple effect across other parts of the system that are not immediately obvious. T. Rowe Price could have decided to allow the automatic transactions to continue, but I can see how this may have caused a different set of problems. I suspect the logic behind this decision went something like this – users that want to convert the IRA most likely don’t want to continue to contribute to it, so we’ll turn off automatic transactions by default and prevent any unnecessary funds from being withdrawn. There’s no clear cut answer, but the product manager had to make a decision on how to reconcile a potential problem.

Once the business rules are set, the question goes to the UX designer on how to notify the user of the side-effects, and this is the tricky part. Here, they’ve chosen to put a simple message that explains the situation. Another option would have been to slow down the user with a message prompt to force them to take a look. The message could also have required a confirmation (i.e. checkbox to continue) to make sure the user understood what was going to happen. My guess is that the implications of this side-effect were decided to be not-so-bad and a message would suffice.

It’s important to be aware of these intra-system interactions so that the user doesn’t get blindsided by not knowing why some things happened. Even as the product expert, it’s not difficult to forget a rule, especially ones that interact across disparate parts of a complex system. If the experts can forget, a normal user will almost always forget.

Some tips when you come across side-effect rules:

• Try to avoid them to begin with. There’s more art to this than science because it involves being creative about how to design the interactions between different parts. In my experience, I’ve found that you can usually design them away or find that they really aren’t necessary. It’s always better to avoid potential confusion but sometimes it’s unavoidable, so aim to minimize the impact.
• Consider the scale of the side-effect. Understanding the scope of the side-effect will help you determine how heavy-handed you need to be in UI.
• Document it. Rules should obviously be spec’ed out but adding notes about use-cases or justifications will help your team make informed design decisions about that feature in the future.