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."
No, his DVD remote has 52 buttons on it because people will really sit down and learn all of those ff/rew/2x/4x/slo-mo/repeat/A-B/loop functions in order to more efficiently find and view the naughty bits of movies.
ccalam - acoustic versions of new songs.
I thought it was fairly standard when doing usability trials to include a wide range of users, with a wide range of abilities. What's good for the n00b might not be right for a poweruser.
As to self handicapping, we were encouraged do that at judo practice when we were kids - when practicing against a smaller or less experienced opponent, you don't use your best techniques. This cuts both ways, he gets a fair go and you improve your weak areas.
Finally, the reason it has 52 buttons is probably because a competitor's had 51.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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've done it with my business (computer consulting) in the past and it can work. Of course, it can also go horribly wrong - it depends entirely on the person and the situation. You can't parachute someone with no skills at all into an intense consulting situation but I've hired people with some minimal IT experience and it has made my business better because of it. Even if they do not immediately contribute to the bottom line they can make the business stronger.
In my case, hiring the best "generalist" IT consultants has consistently led me towards a company full of gifted but undisciplined (including me) staff. I have hired a couple of very disciplined but marginal IT people in the recent past as their adherence to ordering and overall work flow have made the company stronger. In such a situation you usually have to give them a lot of support and keep the other staff from grousing too loudly about it but it can work.
I expect it is a pretty old trick really.
I thought having 'non technical' people review products was common practice ( unless you are from china ). I have always done that. Including their input in the beginning and throughout the life of development is also standard.
---- Booth was a patriot ----
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
More the lack of knowledge, or at least the application of it.
Some causes:
– unnecessary time pressure at 'lower levels' due to lack of planning capabilities at 'higher levels'
– general focus on speed (seen as reduction of cost) rather than quality
– expulsion of elderly above 35 from processes, thereby loosing on 'corporate knowledge'
– focus on specialised training, view of general education as a burden and a waste of time
CC.
TaijiQuan (Huang, 5 loosenings)
so I'll try doing something else with my left hand instead.
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
With two remote controls, one could be made easy with most used features (power control, menu buttons, play/stop/pause/ff/fr and the setup button) and the other one with plenty of buttons for brainy people that use all the features made available to them.
Wouldn't that be the best of the two worlds?
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.
Creativity and knowledge go hand in hand. Expanding knowledge provides new tools to be creative. Creativity may be restricted by the properties of the outside reality, but not by knowledge. Even intelligence doesn't matter, unless something coherent needs to be created :)
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.