Slashdot Mirror
The Curse of Knowledge Bogs Down Innovation
Secret of Raising Smart Kids writes ""I have a DVD remote control with 52 buttons on it, and every one of them is there because some engineer along the line knew how to use that button and believed I would want to use it, too," says David Heath, co-author of "Made to Stick: Why Some Ideas Survive and Others Die." The "curse of knowledge," is the paradox that as our knowledge and expertise increase, our creativity and ability to innovate tend to taper off because the walls of the box we think inside of thicken along with our experience. An article in the NY Times proposes a solution to the curse: bring outsiders with no experience onto teams to keep creativity and innovation on track. When experts have to slow down and go back to basics to bring an outsider up to speed, "it forces them to look at their world differently and, as a result, they come up with new solutions to old problems." Another solution is to force yourself to become a beginner again like making yourself shoot basketball left-handed."
The worst part is that all these 52 buttons probably have a "shift" function, so there are in fact 104 buttons! And what's with the labels? Does anyone really understand (without looking in the guide) what "DTY", "AND" and "NOR" do mean?
It is a basic principle of ergonomics. It is also very true. I see users (and myself) frustrated all the time with stupid or confusing designs. Buttons that don't make sense, user interfaces with too many choices, missing features, badly categorized menus, poorly written or absent documentation, etc. A current trend in electronics is to "dumb down" the device to make it "friendly", by chopping out useful features. That is a mistake! You can have all the features, just organize them well! Resist the urge to make them all visible at once! If necessary, add "user level" modes like "basic" and "advanced".
Every now and then I end up with something so well designed and thought-out it is amazing. At first one doesn't even notice the great- it just "works" and you get done what you need, effortlessly. All the features you need are there, easy to find, well documented. Makes you want to scream at some manufacturers "Hey, look at this product. THIS is how to do it." (I know, you want an example.... OK, the TiVo fits into that category for me.)
It is difficult for people to pretend to be other people- to have different skill sets, capabilities, thought processes.
I didn't read TFA but it seems naive to believe that there are such "teams of experts" designing remote controls and whatnot. Here's the thing: Consumers don't think about usability at all when they buy, and as a simple consequence of that no time or effort is spent on it.
I was talking to a friend who has just spent thousands on a very nice looking oven/hobb. To my dismay (but not my surprise) it still has the hobb controls in a straight line, not in any way related to the layout of the hobb rings themselves, meaning that she will still make mistakes turning the wrong ring off or up, burning food and so on, and she'll constantly have to look at the tiny diagrams by each control to try to work out which hobb ring it corresponds to.
Meanwhile the light switches in her new half-million-pound house are grouped together randomly so you have to experiment by switching lights on and off at random until you hit the right switch.
Her fridge has a temperature control that goes from '-' to '+'. Is that "more heat" or "more refrigeration"?
Oh, and all the power sockets in the house are at floor level, not convenient waist or hand height. Her DVD/TV remote probably has 50 unused buttons on it (I didn't look).
These are #1 usability problem with hobbs, light switches, fridges, power points, etc.; there are books written about it, yet you can't buy an oven, light switch, or new house which doesn't have these problems.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
In reality, those 52 buttons are there because some engineer thought someone might need a few of them, and someone else might need a few different ones, and so on.
:)
But I like your explanation better.
One doesn't need to look at the manual. Use the button and see what happens.
Usability testing is something every well-intentioned planner puts on the schedule at the start of a project. But, unless the project manager knows to take opportunities as they come,and can tolerate some sidelong glances about spending money on frivolous things when the project has delays and resource shortages to make up in implementation, it is often cut down or eliminated.
A problem with abbreviated usability testing is that bad test design creeps in because it is cheaper: Why ask if a focus group delivers meaningful results when it surely delivers the appearance of having made an effort. This kind of bad testing can even crowd out inexpensive "bench top" testing: Are the controls sized and spaced correctly? Are the colors and typography right for readability? Why care about that if the focus group testers don't.
Mistakes in designing-in and implementing better usability don't come from lack of effort, but from lack of direction or lack of leadership that can weigh the value of getting it right. If the results of usability testing don't yield more than superficial issues with cheap fixes that don't challenge project priorities, odds are you have traveled the same road as most mediocre products.
Something like the DVD remote's buttons are a pathology that is easy to trace: The product manager, who has no design inputs when he writes the competitive analysis, lists the union of all competitors' features - usually expressed by their surface manifestation in buttons. When did you ever read a bug report that says: "The market requirements, functional spec, and design spec, are all wrong because they never questioned the number of buttons."
Unless you have a group of people determined to break out of that trap, good design can only be accidental. The system is rigged against it. Throwing in a consultant who questions assumptions is a way of adding more rolls of the dice that could, by chance, break out of that trap, but it is not a solution. The only path to a reliable solution is to change the process.
I wrote parts of this stuff
Eject? It's the one button I don't want to see on a remote.
I have a glass door in front of my components. I don't want to accidentally eject into the closed door, so I intentionally left the eject functons for the CD and DVD players off when I set up my Harmony remote.
And think about it: When you eject a disc, you're going to want to be right there in front of the device to remove the disc and/or put in a new one. Why do you need the remote for this?
But, I wanted socialized health insurance!
The point in the NYT article was much more profound that just user interfaces. I spent my entire career in engineering software battling the tendency of engineers to build ever thicker walls around their thinking boxes as their careers advanced.
Most difficult were engineers who learned clever tricks to conserving memory in their programming. As Moore's progressed, those skills devalued, then became worthless, and finally became negative in value. I had one engineer at late as 1987 who would spend two days effort to save three bytes of memory in his program. Engineers are trained to build on experience, and they expect their experiences to add to their value synergistically as the years pass. The idea that past experience could have negative value was a threat to their personal credos and their career strategy.
It got so bad in my company that I once advocated hiring programmers at age 13, taking them out of school and exploiting them until age 23. At 23 we would force them to retire and finance them to finish high school and college, then move on to some other career. Needless to say, I didn't get very far with that policy.
What should we expect? The whole profession of engineering is based on the concept of incrementally adding to and improving on past experience, from the Romans up to today. Every time a bridge collapses or some other engineering disaster occurs, the public demands that we learn lessons and never ever commit that error again. After 2,000 years of that, how much innovation can you expect?
Contrast that with what is happening at Google. According to reports, Google employees dink around with their own ideas. Sometimes they show up for work on Monday with a bit of prototype code, then they circulate it around the company looking for reactions. The winners survive and the losers disappear without any bridges collapsing or innocent people being killed. That's what so great about software -- it is so easy to prototype. To fully exploit it, you need people who don't know what they can't do.
There was a great book called Computer Wars made the same point about innovation and corporations rather than individuals. The book's point was that if and when the time comes to change the base business model and technology upon which the company was founded, that the founders feel threatened and the company fails. The battle fields re littered with the corpses of countless companies that fell victim to that trap. Now think of Google again. If and when the day comes that the Internet is no longer the big thing, will Google be flexible enough to reinvent itself or will it just die?
How about yourself? if someday the sun came up and the Internet was no longer important, could you reinvent yourself? Can you even imagine that possibility? Probably not -- your thinking box won't allow for such possibilities.
Top-level 'human interfaces'. Groups of buttons/symbols/layouts that do ubiquitous things (play/record/cancel media, fix environmental settings/heating/aircon, setup timeswitches, make a call, extract money from the wall... what else? It does already happen in some sectors, but there's too much incentive to 'do it in a (patentable) original way' or 'do it with a minimum number of mysteriously multifunction buttons'. We want a uniform (extensible) physical 'user layer'. If there were voluntary 'Standards' which mfgrs could cite to reassure consumers that their kit would be easy to use, people might pay attention. (I won't get into onscreen PC issues, but software folk could also note). When I had things to do with this area, the dictum was - you don't have to design for disability: that's part of the definition of good design.
I have a keyboard with 101 buttons on it, and every one of them is there because some engineer along the line knew how to use that button and believed I would want to use it, too...
I have a MacBook, with the Apple remote. How do I jump to chapter 13 of a track? I hit "forward" 12 times. Why? Because some usability guru thought simplicity was more important than functions I use daily.
Personally, I would rather have the power to perform complex task simply (and let the non-power user ignore the 48+ buttons they never use) than not have the ability to perform the tasks easily because someone took out the button.
I'd rather have someone respond than be modded up.
I'm tired of hearing engineers blamed as being uncreative, uncooperative, stubborn, "need to think out of the box" people. It's a generalization based upon limited knowledge and fear of those people.
The axiom is true of every other field or profession I can think of. Do you think politicians are thinking outside the box these days? Or are they sticking with what worked in the 1920s? How about natural scientists? Einstein went to his grave refusing to believe in quantum entanglement calling it "spooky action at a distance". Marketing people? Have you seen a really different car ad in the past three decades? Accountants? Bound by limitations of math. Their numbers just have to add up and like bridges falling down if you do something shaky you get Enron type accounting.
Oh! you meant children and artists are creative. First, children. They draw on paper and come up with crazy new ideas. Well except that the things they draw can't be built due to physics of materials and usually they're crazy ideas can't be built because they aren't practical enough to be profitable or affordable. They don't have an understanding of constraints and constraints must be factored into any product. Second, artists. Come now... really look at the works of Jackson Pollock. Are his later pieces really that much more outside of his box than his first splatters of paint? I went to a gallery exhibit once and one artist painted nothing but cloud scenes over country sides and the other made nothing but abstract, headless sculptures of narrow shouldered big assed women. No artists do not think outside of their boxes any more than engineers do.
The reality is that the world, people and the universe impose constraints on any projects. As any person gets older they learn what works to keep them alive and what does not and it is very effective. It has been very effective for ten of thousands of years. Do not eat the pretty frogs no matter how hungry you are. "Out side of the box" dictates: "consider that this frog is different." NO! do NOT eat the pretty frogs... period. You are much better off thinking inside of the box.
Engineers are some of the most creative people I have ever met. They are given a goal, often with no direction of how to get there and they must reach that goal while always satisfying very tight constraints. This type of creativity is very hard. It's easy on canvas with paint but a canvas picture of an engine doesn't have to be manufacturable, it doesn't have to be profitable, it doesn't have to produce a certain minimum horsepower, it doesn't have to spin at a certain maximum revolution without seizing the bearings, it doesn't have to be made out of a certain material yet be strong enough and weigh less than a certain amount, it doesn't have to fit in a limited size cavity or connect to other components in a functional way. Yet engineered products have to have enough creativity in them to accomplish all of that and more.
Software engineering is no different. If lines of code are considered like bolts, screws and components; all of which provide some functionality. Then there are as many individual pieces in any application you use today, be it games, Word, Mozilla, than there are in a space shuttle or strokes of a brush by Monet.
The real disappointment is that the art and creativity that engineers produce is rarely recognized or appreciated. And it should be. It is so creative, in fact, that most people don't even know it's there or could understand it even if it was explained to them.
Engineers have their own wu and it is very, very strong.
I will never live for sake of another man, nor ask another man to live for mine.
If you like this stuff then you'll like this academic article:
March, J. G. 1991, 'Exploration, and exploitation of organizational learning', Organization Science 2(1), 71-87.
As I understand it March argues that new participants are required to learn new ways of doing things (just as the FTA does). March goes further though and argues that some kinds of organizations (often unconsciously) force 'rapid socialization' on new participants, bringing them in line with the groupthink quickly. He argues for a balanced socialization period, in which the organization can actually learn from the novel perspective (although not so long that the organization doesn't get back to exploiting its knowledge).
There's lots of good literature citing this article too.
What bothers me is the way everyone here takes the article so literally and so narrowly. They use a remote as an example, but it doesn't just apply to user interfaces. For example code re-use which is generally a good thing, as far a productivity goes, but is actually a double edged sword.
:)
Frameworks a good example of what I mean. While a framework helps us to get things done, most will no longer think of their own solution to the problem, relying on someone else's solution. This mean a new novel solution to the same problem (that may be useful in other ways) is never found because we all use the same solution. In business, using a framework is often imperative since time is money (and it uses the 'if it ain't broke, don't fix it' principle). However, we need to remember sometimes about the trade off. Not writing new code for a similar problem means that there is absolutely no chance of discovering something new.
Now... think about where this applies in other situations... including outside of programming.
-- I ignore anonymous replies to my comments and postings.
Kind of, but not really. I might even go so far as to say that this kind of crypto-libertarian approach to user interface design is the opposite of good design. It sounds good in theory to say that you aren't going to impose on your users, but that in itself is an imposition, because it assumes that the users know what makes sense for them, and punishes those who don't. In most cases, that is a very large majority of your users, and you end up confusing and frustrating them by presenting them with choices that they don't know how to make. The general rule of thumb for usability is don't make the user think, although I will say that it is quite important for the interface to reflect (or at least acknowledge) the user's mental model.
Particularly when it comes to software, most people use computers so that they have to do less, unlike a power user who wants to do more. Some of the best user interfaces are opinionated -- they are biased toward a particular way of doing things that the product designers think is most effective or useful, instead of being a swiss army knife that attempts to do everything. What users are buying is the designers' expertise and knowledge to make choices so they don't have to kind of like how you visit sites like Slashdot because the editors have opinions about what news is interesting.
This raises the question of whether you could do UI/interaction/industrial design using a Digg-style wisdom of the crowds methodology. I would say that you can't, because although people are pretty good at self-reporting whether something is interesting/funny/news-worthy to them, they are notoriously bad at self-reporting how they use interfaces. This is pretty evident when you get customer emails suggesting features that also suggest a UI design ("Please put a dropdown here, a button to the left of that, and a red box underneath that says..."). These proposed designs often violate every usability heuristic in the book, and if we actually implemented the UI in that way, it would test very badly with almost all users, including the user that proposed. Other techniques like eye-tracking headsets could be used this way, but its difficult to do that on a widescale.
"It's Dot Com!"
Many people, particularly older people, have tremendous problems with "context aware" buttons. They simply can't handle the thought of modes. Even for people quite comfortable with the concept, it can introduce additional errors and delays in the interface. Having one button do one thing is actually one of the easiest interfaces for people to learn and master.
52 buttons sure does sound like a lot, probably even a bit much, but switching to multifunction buttons isn't automatically an improvement for either a novice or an expert. Humans are incredibly good at learning cause and effect based on observation. Our brains appear to be wired that way; we assume it makes good sense for survival, etc etc etc. Modes screw with the system by throwing in additional factors that we might not notice and take into account; I pushed this button and it did this thing last time, but this time it does something else, it's no longer a simple cause->effect relationship that is easily observed and learned. The observing must take into account that it's no longer just the button, but also the button before it, or else some other aspect of the system state like a display that I need to read. This requires either more instruction to teach or more practice (and time) to learn. Then, once learned, it needs to be executed right - and users can get confused if they end up pushing the right button while in the wrong mode without realizing it. And even in the best case, it makes me do more to get the same effect, leading to a slower interface. Take it to a logical extreme - you only _need_ two buttons, a 'switch to next function' and an 'execute', but you would go crazy if that is all your remote control had. Clearly less buttons + modes isn't automatically the answer.
Sorry about the rant, just hate to see people automatically assume that buttons can be doubled or tripled up, it leads to stuff that my mom can't figure out and that I don't enjoy using. Ever watched a DVD with the PS2 controller? It sucks trying to figure out which button does what when.
is competition good, or is duplication of effort bad?