Hacker News new | past | comments | ask | show | jobs | submit login
Quit quirks when working with others (sivers.org)
163 points by cardmagic on July 7, 2010 | hide | past | favorite | 27 comments



This article is really about two things - expectations and communication - and Derek makes an interesting tangential point about personal quirks without actually addressing either of those issues.

Users expect things to be a certain way. In most business situations, that's advantageous - when expectations become standard across your user base it allows you to build upon those expectations. (Rapidly thought-up example: most users now expect underlined text on a website to be a hyperlink, which allows authors to link to external sources without specifying 'click here' all the time.)

But what if you want to be cutting edge, or do something that isn't expected? Then you need to communicate how you have changed expectations. When Derek checked into that hotel, they should have explained how the lights and taps worked (probably had written instructions for both in the room as well, although that's not much use in the dark).

Apple have been very successful inventing their own quirks. Some of that success is leveraging our expectations - it's why we call their devices 'intuitive'. Some of it is communication - see how many Apple ads (even still photographs) demonstrate the touch pad being used, to communicate to dedicated mouse-users that their expectations may go astray. And Apple aren't perfect - I had to Google how to turn off my wife's iPod because it wasn't in the instructions and didn't meet my expectations of an off switch.

A business coach I worked with once summed up business as: Business = People | People = Expectations | Expectations = Communication, so

Business equals Communication.

It's a useful framework when building any product for consumption by others.


> I had to Google how to turn off my wife's iPod because it wasn't in the instructions and didn't meet my expectations of an off switch.

A beautiful example! I don't know what her model is, but the iPod Shuffle 2G has the (to me) astonishing feature that the 'Off' part of the 'On/Off' slider doesn't actually mean 'Off', despite being so labelled; it means 'Reset' (forget what you've played, and where you were in the current song). The correct way to accomplish 'Off' is 'Pause' followed by 'now wait a while' --which I consider an extremely clumsy move on Apple's part (not the behaviour, which is fine once you discover it, but how un-, and even counter-, intuitive it is).


> The correct way to accomplish 'Off' is 'Pause' followed by 'now wait a while' --which I consider an extremely clumsy move on Apple's part (not the behaviour, which is fine once you discover it, but how un-, and even counter-, intuitive it is).

But that wouldn't be "off", that would be "hibernate". Which is what you want most of the time.

Off would be a complete power off, and it makes sense that the device's state is not saved to NAND (because most people won't ever need that). The configuration wasn't changed was it?

It's the same with e.g. an iPhone, a quick tap of the power button shuts down the screen, a long tap completely shuts off the device. Most people never ever need to completely shut it off.


> But that wouldn't be "off", that would be "hibernate". Which is what you want most of the time.

I agree, and, indeed, I think the behaviour, once discovered, is perfectly sensible; I'm just talking about the initial discovery experience.

The manual (at http://manuals.info.apple.com/en/ipod_shuffle_features_guide...) does not use the terminology you mention; instead, it refers at the top of the chart on p. 4 to 'Turn[ing] iPod off', then at the bottom of the same chart to 'Reset[ting] iPod' (both by pushing the slider to 'Off'!); and it does not mention 'Hibernation' (or equivalent terminology), or the fact that it should replace complete power down, at all.


> I agree, and, indeed, I think the behaviour, once discovered, is perfectly sensible; I'm just talking about the initial discovery experience.

The initial discovery experience, for most people, is that you don't do anything and you iPod "magically" does the right thing in return.


> The initial discovery experience, for most people, is that you don't do anything and you iPod "magically" does the right thing in return.

I think that, at this point, we're getting into anecdotal evidence; I don't have any idea what most people's iPod experience is, but certainly it's not natural to me to conclude my experience with an electronic device simply by walking away from it—I want to turn it off. (The fact that computers are an exception perhaps explains why a younger generation might be more inclined to the 'just walk away' approach. EDIT: OK, and cell phones. But I still think that I have more devices in my life that I turn off than devices that I don't. :-) )

My main evidence that this is not the only obvious approach is that it is different to the behaviour of the iPod Shuffle 1G, which one did (or at least could) put into hibernation by sliding the main switch to 'Off'. It was this change between generations that particularly confused me.


I had to Youtube how to put a sim card in my iphone : d


"But what if you want to be cutting edge, or do something that isn't expected? Then you need to communicate how you have changed expectations."

If it's a change worth making, you shouldn't have to communicate it.

Your users shouldn't say, how does this work? They should say, this is how it should have worked all along.


> If it's a change worth making, you shouldn't have to communicate it. > > Your users shouldn't say, how does this work? They should say, this is how it should have worked all along.

I think that this is extremely limiting. I am a moderately skilled vim user, just 'power'ful enough that I have a range of vim-specific tricks up my sleeve, and am frustrated when other editors (seem to) make the same tricks difficult to achieve. However, no one will accuse vim's feature set of being easily discoverable.

By your criterion, it seems that this sort of behaviour, which is hard to learn but powerful once learnt, can be ruled out; and this seems to confine us to a sort of playground where we can perform certain tasks very, very naturally, but are then confined once we need more.

In short, I would change your slogan (which I think is very catchy!) to the less euphonious "Your users should eventually say, 'this is how it should have worked all along'."


Within the context of the discussion, vi is horrible.

What benefit does vi provide for a user that will only ever use it once? Why should he bother learning it if he's not going to use it but one time?

However, vi is good when you plan to use it often. The skills learned will benefit you years to come. It's worth a learning curve.

Both these ideas were noted in the article, and from my take, expanded upon by the above commenters.


The folks coming down on Derek might do well to read Donald Norman's book, The Design of Everyday Things, which speaks directly to this issue. It's important to remember that the purpose of design is not simply to dazzle the beholder, or make people think, but to make useful things usable. It's easy for designers to forget this, especially the avant-garde sort who fall in love with their own creative spirit, tend to win the accolades for their "radical" ideas. In fact, Norman's book introduced me to one of my favorite design epithets:

"It probably won an award."


Couldn't agree more. I've recently had a similar experience with the windows of the flat I live in. They are big double-glazed windows, very nice, that are made of a single pane of glass with a horizontal axis so you can rotate it to open the window.

There is, of course, a latch, to make sure the window doesn't open past a dangerous point (we're on the 7th floor of a 20-floor building). The clever designer who designed these windows managed to hide the latch in such a way that it doesn't look like an ugly safety latch. Result? When cleaning the windows some time ago, one of the windows rotated all the way around and then latched itself. We couldn't figure out what was going on (the latch pin is entirely concealed) and so while trying to close it again, broke the pin, which required us to call in some window fixing people whose only option was to actually saw through the pin to close the window, because the pin was so inaccessible.

We also got them to install some simple latches. Those are clearly visible, and involve a little bar of metal with notches that you can hook onto the window to latch it. Clear, obvious, and I can guarantee you that no one will ever break one of those latches while trying to close the window.

Kudos to the designer who managed to screw up the usability of a window, though.


<Sarcasm> That's nothing compared to Microsoft who have been on a crusade to screw up the usability of all the windows in the world!


People are VERY conservative when it comes to interfaces. Remember those old Westerns, where the guy in the Hotel washes up in a basin? Two pitchers: hot and cold.

Along comes running hot and cold running water! Two faucets replace two pitchers. Still washing in the basin - fill it with some hot, some cold.

Now somebody clever invents the single faucet- one handle to mix hot and cold! Cool! Quickly get just the temp you want. Fill the basin, wash and shave.

But wait - kids are just washing under the flowing water. Those darn kids! But it DOES save water.

Everybody is doing that now - so filling the basin becomes an anachronism. In fact the basin is just to catch the water - its a drain. A dirty drain. Who would wash their face with drain water? Ug.

So we go from pitchers and basin, to running water with adjustable temp going down a drain. Total elapsed time: 100 years, 3 or 4 generations.

Nothing in that process was rocket science. Could have happened the 1st day. Its PEOPLE that are the inertia, darn those people and their expectations.


Not sure I agree with the premise of this article.

You can always make the case that, on the contrary, you may want to go to a hotel to experience something that you haven't experienced before.

If the design is somehow more functional or otherwise makes the room look very beautiful, I'd be more than happy to stay at a place like this.

If necessary, they can always put little notes explaining how some of the main tasks get done.

I agree that the fact that people stay in a hotel for only at most a couple of days puts more constraints on how accustomed people can get to another interface. My own programming "quirks" have developed for a reason. So why does the author then use this example to justify his point about teamwork when the metaphor breaks? Or is he implying that you will only work with a team for such short time that no one will reap any benefits from getting used to ideas that make things faster in the long run?


> If the design is somehow more functional, ...

The problem is that the design barely functioned at all. The light switch was hard to discover, and used gestures even harder to discover. How different would it be if the "smooth panel" was a backlit LCD touchscreen with a softly-glowing "O -> |" on it? Especially if it were placed where it was visible the instant the door was opened? Alternatively, if it reacted to any motion instead of specific gestures.

I guess the lesson I take from it is that _visual_ design is only a single component of the overall design or interaction design, and focusing only on the visuals without thinking about anything else is not likely to generate a usable solution.


How do you know visuals were the only criteria? A flat panel is a hell of a lot easier to clean than a regular light switch.


Yeah, interesting article, weird conclusion.

The comparison of hotels to website design is pretty apt. A hotel is often just a place to sleep, and not the point of the trip (resorts are an exception), so even if it makes the room prettier, in the end it doesn't justify straying from standard expectations. Same with most websites, people generally aren't interacting with one given site continuously for 8 hours a day, so they don't have time nor inclination to get used to some quirks.

But for web development frameworks? Lots of people do work on web dev for 8 hours a day, so if some nonstandard framework trades a couple days of learning curve that results in productivity gains measured in months, it's totally worth it. E.g., Rails and Django fell out of such things, and they had to start somewhere.


He does mention that things that make you more productive in the long run really should be exempt.

I think the moral is that your quirks may not be welcome for other people, even if you think they are the best way to do things. Unless they add continuous and lasting value it's best to just leave them out when working with other people.


Yeah, but it seems like you rarely want to be radical when it comes to consumer focused web UX design, whereas when it comes to development itself, it could be justified a lot more often, because people are really dealing with tools for hours a day. So bringing up a dev example just seems weird.


I'll say this: I think some people want an interesting experience, regardless of whether it is intuitive or expected or within their comfort zone. But some others just want a nice, safe, clean, comfortable, quiet, home-like, relaxing experience. Those folks do not want surprises. Maybe they are visiting that city for work, they are away from family and the comforts of home and this hotel room may be the closet thing they'll have to a home base temporarily in lieu of that. They do not want excitement or exotica --- not from the hotel room anyway.

For most people, if they want to see something unusual or exotic they could visit a museum, visit a foriegn country and experience local culture, and heck, nowadays, there's lots of exotica just a click away on the web. In other words, I know I risk coming across a "2 girls 1 cup" experience when strolling randomly through the web (I'm looking at you 4chan), but I don't want that sort of surprise out of a hotel room, thank you very much.


I think the problem with areas like architecture and industrial design is, there is no clear performance metric for what is considered "good design" - or at the least, what designers consider good isn't completely aligned with what users consider good.

The switch designer in this case was overly focused on aesthetics and his own cleverness, rather than on making a "good" switch. The fact that you'd need directions on how to use it makes it a horrible switch. It fails its most primitive task, which is to be identified as a switch. Secondly, you can't tell how it works just by looking at it. And to ignore the iconography of something utilitarian like a switch, is a bit self-indulgent. Here, design gets in the way.

This is a problem with design education, which turns people into cake decorators rather than problem solvers. The entire science of how-things-work is ignored and worse still, not even considered as a source of inspiration. Instead, you get perversions similar to that of the post-modern literary crit world. Designers talking amongst designers, giving each other awards, and curating some new form of design-incomprehensible to outsiders.

And this leads to the false dichotomy between form and function. Almost like art vs. engineering. You get students who study design, who have no interest in how things work. And you get engineering students who don't understand that products are experienced in layers - you have first impressions and expectations, recognition of what it does/how to use it, perceiving of quality (would an iPod feel cheaper if it was lighter?), durability, etc. and that process must be managed/controled via design.

I sometimes think studying bridges is a better way to learn about design than studying architecture. You can't ever ignore the fact it has very real constraints. And yet, there are tons and tons of beautiful bridges. Every component must be functional AND aesthetic. A designer is the engineer and the engineer is the designer. You get a very "fat-free" structure. Different bridges have different experiences. And they never get in the way of you driving across them either.

James Dyson gave an awesome talk about this at MIT, called "The Art of Engineering". I definitely recommend watching it if you see engineering and art as one: http://mitworld.mit.edu/video/362/


This is probably my least favorite post by Derek, whereas the others I've generally really enjoyed. It started very "get off my lawn-ish".

Standards are inherently good when working with others, but style is unavoidable. Ultimately everyone has to adapt and I believe this is one facet where company culture gets defined.


> Ultimately everyone has to adapt and I believe this is one facet where company culture gets defined.

This seems to me to be precisely what he's saying --that, previously, he has tried rigidly to maintain his style, but now will keep an eye to adapting when appropriate. Perhaps I missed your (or his) point?

EDIT: Actually, it's reasonably likely that I am missing your point, because I always do bring my quirks to the job, and so couldn't help taking this as a personal admonition, which probably blinds me to a bigger picture.


However, there's a difference between style (different process) and impediment (broken process). The giant, flashing warning sign that the hotel is ignoring: "Ah, sorry. We get that question every time."


At some point the light switch and the faucet controls will have to go. But we can't get to that stage if people have trouble with a side swipe or other twist and tweak.

I agree that it's brain dead to have a major site like Dell always changing their website interface, just to keep things "fresh" or make it seem like some layer in management actually did something every 3 months. The concept of a mouse and menu choices however goes back to the Xerox photocopier developments, and have yet to be shed. For example a better input scheme could be using keyboard input for navigation but only if the prevailing rule is to be smart about it. Consistency is important but secondary!


In newer hotels in Germany, the rooms DO have light switches, but the lights only work while the room key card is inserted in a slot by the door. There certainly is some logic to that, but it badly confused me first time I was confronted with this arrangement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: