On designer humility

The latest much ado about nothing on the Internet: Blogger Joshua Blankenship has written a pot-calling-the-kettle-black diatribe against Dustin Curtis's apparent lack of humility in criticizing American Airlines. He seems to think that Dustin should be a little more humble in his criticisms of such a large, immovable corporation whose complexity seemingly exceeds that of a very good designer.

I call bullshit.

A humble designer is one who affects no change indeed. Designers should be less humble. When engineers or business guys or management or *anyone* makes a product lousier, they should get up and shout, and raise hell. Designers should NOT 'know their place.' Because if the powers that be keep their power, then we will continue to live in a barely working cesspool of compromises and bad experiences.

Apple wins because the guy who cares the most about user experience happens to run the show. And last I checked, humble wasn’t really a word you could use to describe him.

"There's not a detail there that doesn't need to be there." -- Ive on the new iMac.

Two quick design fixes lala.com can do to increase stickiness, conversion, and retention

Lala.com is a music sharing site that's been around for maybe a year or so. They've built some great traffic and have a product I use every day now. I first heard about it actually from Posterous users who kept asking for the ability to embed Lala.com in their blog posts. It's US-only for now (sorry, International friends) but at least now I don't have to pine away for a re-activation of my Spotify account.

As a product, it's great. But there is always room for improvement. Here are a few basic design changes that I think could give a big ROI.

1) Incentivize long-lasting value by switching the Play and the Add to Queue button

When I first saw lala.com, I thought it was yet another in a line of many music services. I, like every new visitor to every site, had my mouse hovering over the back button. Luckily I stayed around long enough to discover its value. They have pretty great song libraries that have everything from hits to the obscure parts of the catalog. And they allow you to play the whole song through once for free, which is very impressive.

They've expertly engineered the site to be playable at all times even during browsing. This means you can actually just browse around the site without ever stopping your music player. (It's something that our friends at YC-backed thesixtyone.com do really well too.) But the main call to action on most songs and albums isn't to take advantage of this ability to create playlists.

Instead, it's a play button that causes it to play now. Many users may not even realize they can queue long playlists of songs. Instead, a 'queue' button is next to it, but as all designers realize with time -- if it's a secondary action, nobody uses it.

The fix: Make the queue button default, and show a tooltip or flyout that teaches the user that they've added something to their playlist. Heck, make an ongoing sidebar to the right to reinforce the playlist concept. A single song play may only last 3 minutes, but if you can get people to create playlists of music, then you've a) achieved incredible lock-in and b) proven that you're valuable. You've beaten the back button, at that point.

When you're new, focus on being as simple as possible. But when you're in a crowded space, you have to focus on showing the user how you are different and better. Lala is interesting because of a voluminous on-demand catalog of music that can be your new music player playlist. So focus on that.

2) Once you prove to them you're valuable, make it easy for the user pay you and buy into the system.

Lala has a concept of song credits, and when you sign up, you get a prominent item in the menubar that lists how many song credits you have. You can listen to any song in their system for free once, but if you want to play the full length song again, it costs 10 cents to 'buy the web song' and stream the full length song forever. Like Spotify, without the monthly fee.

I didn't need all 25 song credits to realize this was a valuable service. Yet clicking on Song Credits always shows the same text wizard above. It wasn't until I used up all 25 credits that I was shown the UI I was expecting:

It's OK and even desirable to have great explanatory text around how your site works-- but don't hide functionality that is the critical path to the user who wants to buy into your system.

--

Building user experiences is just a repeating conversation you have with thousands of users every day. A faux pas here or there will not necessarily doom you, but it costs you some percentage of future customers in the end. For a service that hopes to be viral and organic, a few percentage points in conversion can result in significant deviations in outcome and success. A first impression is make or break, whether in person or on the web. Make yours count.

You should follow me on twitter here.

Microsoft Courier: Wow, someone is paying attention in Redmond

The Joy of Minimalism: I removed something from my bike that I didn't need, and cycling got more awesome

For Christmas last year, my little brother built me a single speed / fixed gear bike. He was kind enough to add both front and rear brakes, so I could get up to speed with riding it without, uh, dying. I started riding single speed -- it felt like I always had the wrong gear. Too slow, too fast. I was bored.

Then I started riding fixed-gear. Its true what they say: You feel more in touch with the road and the bike. But I still had front and rear brakes -- and I used them quite a lot, even though I didn't need to. I still hadn't broken with my non-fixie habits.

Today, I removed the rear brake. I took off the whole mechanism -- cable, calipers, everything. (I kept the front brake just to be safe.) The bike looks a LOT cleaner. But that's not interesting. What matters: It changed my entire cycling experience. I'm right handed, and the rear brake handle was on the right side of the handlebar -- so now that it was gone, the urge to brake went away. I regulated my speed according to my surroundings. I didn't brake. I way more free to just roll naturally, as I had one less knob or control to worry about. It was liberating.

When it comes to software and products of all kinds -- think about what removing a rear brake might do. There are so many needless dialogs, radio buttons, menus, alerts, gradients, drop shadows, mouseovers, text, icons, lines, boxes, and so on. Its absurd. Every single element in a UI exerts some cognitive load -- some weight on the brain. Its slowing you down. You're trying to get to a destination, and all the inessential UI is just screaming for more of your precious brain power.

Get rid of the things you don't need. Keep the things you do. Yes, you can add to the experience by subtracting.

You can't separate visual design from interaction design.

Coca-Cola: If it doesn't add anything, take it away.

The iPhone killer of the future needs vertical integration. (Why Android is doomed.)

Practicing product minimalism

On my first day of work at Microsoft as a PM six years ago, I sat down with my first manager for our first one-on-one and at the end she asked, Are there any questions? I said yes -- one last one: "When do we decide to remove features?"

She was flustered. It was not a question she or probably any PMs were used to answering.

I clarified: "Well, features aren't always right. Sometimes they're done wrong, or they don't really fit what the user really wants. Do we ever remove features?"

She remained dumbfounded at the question, and feeling like a n00b, I decided not to press further. In time, I realized why she was flustered. As a program manager, you spent so much time trying to get features in that it seems nuts to want to remove them. We made huge spreadsheets of feature lists, prioritized by P1, P2, P0 and sometimes P-1. Yes, negative 1. Because it gets sorted higher, right?

Features got removed in other ways though. If nobody really used them, they were obviously chopped out and memorialized as a bullet point in the release notes. But that wasn't really my question. Those are the easy ones to chop.

A product gets bloated not because the obviously bad features stick around. They're bloated because there are features that are barely OK in there. They're not complete. They aren't done correctly. Maybe the UI is wrong, or the internal states aren't thought out well enough, or don't match what the user expects. And there are egos attached, too. A poor PM's ego, at the least,and maybe a dev and a tester's self worth too. An entire feature team might have emotional stakes in that feature.

So you can't chop it. And you don't have time to fix it, so it festers. You can never remove features. You have to fix them, painfully, over time.

This can be avoided. Go deep on the things that matter. Do less with less. Be minimal in scope and maximal in completeness. If you're a startup, don't hire. Make it happen with who you've got. Don't get a PM to sit in meetings or create meetings. Only hire do-ers / creators. Do more yourself. If you're a big company, give a skunk-works-sized team a whole shit-ton of power (and really mean it).

Be less. Do less. And you'll somehow end up with more.

You should follow me on twitter here.

Filmmaking advice writ large: Tarantino's advice at ComicCon applies to all creative endeavor