Ease-of-Use Should Not Mean Neuter-the-Software

🧑‍🎨 Creator(s)
🗓️ Publish Date
September 25, 2006
📚 Publisher(s)
🍿 Media Type(s)

🗃️ Archival copy:


Is our heart in the right place but our execution flawed when we neuter a product in the name of newbie-friendliness? In the push to make programs "so simple even your [mom/kid/dog] could use it", there are a lot of dumb products out there. Or rather, dumbed-down products. It's like we're throwing the power baby out with the poor UI bathwater. But if we want passionate users, ease-of-use should NOT be the Big Design Goal. Good usability is the enabler for what we (users) really want--more superpowers.

We want to do things. Cooler things. Advanced things. More creative things. We don't want to be better at using the tool, we want to be better at doing whatever it is the tool supports! Usually when we talk about this it's-not-about-being-better-at-the-tool thing, we're coming from the perspective of what and how we teach our users. This post, however, is about the software, product, web site, service, itself.

Take a look at this chart, and ask yourself how you'd describe the two boxes with question marks. We know the bottom right quadrant is awesome, and in the top left, there be dragons. But what of the top right? What of the bottom left? Think about it for a moment before you continue (or before you, as most of you will do, skip to the next graphic ; )


It's great that so many are putting the "user" back in "user interface", but using a brain-dead-simple tool does NOT necessarily mean an "I Rule!" experience. Maybe we need to spend more time thinking about providing superpowers and a little less time on simplifying. The last thing we want is to build the Tic-Tac-Toe equivalent of software, when the user ultimately wants to play Chess. (Note: I said "when" the user wants to play Chess. Sometimes the ultra-beginner-only product is exactly what's needed, and might be extremely successful, but it does mean that users will outgrow it before they ever become passionate. This post is about the products that do NOT want to be newbie-only.)

Without challenge, there can be no growth and no flow state. And wherever you find real passion, you always find challenges. Alan Kay once said something like, "We do a great job of helping people practice being beginners. We help them get really good at being beginners. What we need are ways to help people start at an intermediate level so they can start doing something rewarding right away."

Of course usability is absolutely crucial, and it's a prereq for pretty much everything. A UI that gets in the way of the thing the user is trying to do is a deal-killer (or at least a flow-killer). But there's a difference between "Good UI" and "Ease-of-use"! If I'm doing something complex, by choice, then focusing on making it easier might not be the right move. Assuming the power is there, the main goal should be to keep the UI the hell out of the way of what I'm trying to do. You may not have made it technically an easier product to use, but you've made it a product that supports more time in flow, doing the thing I want to do (which is NOT "use the software", but rather "edit video" or "write a letter" or "mix audio").

Perhaps I need a qualifier for the word "easy", because while the thing I'm doing with the tool may be quite difficult, it's true that I want the how-I-communicate-with-the-program to be as easy as possible. I do want it to be extremely easy to figure out how to tell the software what to do, but I do NOT want the software to pat me on the head and say, "don't worry your little head... I'll take care of it all for you with this nicey-wicey wizard and this fuzzy-wuzzy dialog box and all the helpful things I can do for you like capitalize words (since you're too stupid and lazy to do it yourself)" . And I do NOT want the software to simply strip out all the functionality that's too complex to simplify. So I guess there's at least two different forms of easy: easy-as-in-natural-usability and easy-as-in-dumbed-down.


But what about Featuritis?

"Featuritis" comes from adding horizontal (broad) capabilities, rather than adding vertical (deep) capabilities. Rather than add 25 new ways to do the same shallow things, add 5 new advanced capabilities. I don't want to do more things, I want to be more advanced.

Photoshop, for example, would be adding horizontal features if they added new painting tools, or yet more ways to configure your tool bars, etc. But adding new capability to their color correction and RAW tools, for example, would be adding vertical features. One leads to featuritis, the other leads to more powerful users.

Featuritis is not so much about feature quantity... it's about feature shallowness. By all means, please give me more features. But they must be the right features, and to figure out "right", we have to know our users, we have to narrow down the domain in which they use our products (e.g. is Photoshop about photography or digital painting?) and make some assumptions about their goals, motivation, and background.

1) Adding power through different products or product editions

When we add features, they should be the next natural things an advanced user wants to do, but the new superpowers don't necessarily need to be in the same product... Apple provides a dumbed-down (but still wonderful) free music making tool in Garageband. It's extremely easy to get started (which is great), and ridiculously simple to use, but even a non-musician who really gets into Garageband starts to bump into Garageband's limitations pretty quickly. And as if by magic, Apple's non-free product Logic Express just coincidentally happens to have the features you find yourself wanting after you've started to max out Garageband. (And the same thing repeats when you bump into Logic Express limitations, there's always the much more expensive full-featured Logic. Apple uses the same thing 3-tier/first-one-is-free-crack-model with their video editing tools as well).

2) Adding power through user-created extensions

Many excellent, successful products take the approach of, "Sure, we could keep piling more and more features on after listening to all the requests, but each added feature would just annoy everyone except the one person who asked for that particular feature... so instead, we'll let YOU add new features."

IBM once had an Expert System tool called TIRS, and when users wanted to do more, rather than continuing to add to their API, they opened up the system so that you could embed your own C functions in a rule. Allowing plug-ins, extensions, macros, third-party modules, etc. is (sometimes) a great way to add far more vertical/deep power than you could ever come up with when YOU are both the developer and, well, the decider of what should be there.

3) Adding power through "advanced modes"

Yeah, yeah, yeah I know that this is controversial, and I have virtually no credibility in developing a product with different user modes, but... it can work.

4) Adding power through a willingness to sacrifice newbies

We can't be all things to all people. The cliche of "catering to the lowest common denominator" is one we all consider negative, yet we still do it. It can be a form of greediness! If we can only do one thing well, then we have to choose carefully. And if can't find a clear way to add advanced capability while hiding the complexity from the newbie, then some of us must choose to leave the newbies to someone else. (Yes, there are a million implicit qualifiers, conditions, disclaimers, exceptions, etc.)

Being the one who nails it for the newbies is a very successful strategy for a lot of products and services. But again, once those newbies leave the nest, they have to look elsewhere. And the better we are at inspiring enthusiasm and loyalty in beginners, the more they want to continue with us ("I trusted you this far, and you really came through... now help me get to the next level").

5) Adding power by truly knowing (and not underestimating) your users

Recently someone showed me a very early alpha of a start-up web app he's working on. The target audience is "regular people" (i.e. not programmers or other hard-core geeks). I was horrified when he showed me what amounted to a command-line style of input. Command-line?! But then he reminded me that most people who aren't right in front of their computers write things down. Most adults are not just comfortable but experts at writing on paper. When I write someone's phone number on a piece of paper, I don't have a separate little piece of paper for [first name] [last name] [area code] [phone] [cellphone] and on and on. I just write the damn thing down as a string of characters. So... why not allow (or even encourage) users to simply type things in rather than forcing them to go through complex wizards and dialog boxes.

This particular example is fraught with UI landmines including the problem of users needing to memorize the exact order and syntax they have to type things in. And yes, that could render the whole thing virtually unusable. But if the software had some very intelligent, clever parsing and could just look at the text and figure it out (or at least make a high-probability smart guess), then you've got a way to enable a ton of power without having to add endless dialog boxes and windows and choices and other get-in-the-way features.

The point is, that while it looked DRASTICALLY counter-intuitive to me to have "regular users" essentially work in a command-line interface (fortunately it looked and felt like a simple text edit window as opposed to, say, a DOS prompt), when the guy showing it to me framed it as, "Writing things as text is the most natural thing there is" I felt my brain shift a little. And then I began to consider all the software that babies us, insults us, and ultimately gets in our way... something Jason talked about when he delivered Opening Remarks at SXSW (classic example: "I can capitalize words mySELF thank you very much...").