And you are here why?

Say you’re building something completely new and different, which can leave users feeling anxious and/or confused. How do you introduce it to the user, and get the user actually, well, using it? It’s a good question, and particularly relevant in our current world, where we are constantly being bombarded with information, with the volume and content thereof being ever-increasing. Mind you, the fact that we spend our days hunched over a computer and/or a phone doesn’t help at all — if anything it only emphasizes the sheer amount of cognitive load that we all live with on a day to day basis. In this environment, the last thing you want is to add anything to this cognitive load. As product developers, succeeding in this world involves either outcompeting the others, or making life easier for your users. Assuming that you  aren’t  in the business of being evil (please please don’t be evil!), your approach towards UX should focus on ensuring that the users  know  t...

A friend (call her Alice) shows up at our local pub everyday at 6pm and has a glass of Albariño. It’s like clockwork, to the point where the bartender (Bob) pours a glass out around 5:58, so that it’s ready for Alice when she shows up. The fun part here is that every now and then, Bob pours out something  different —  say, a Vermentino, or a Pigato, or some such — and Alice is quite OK with this. The reasoning being • The “fuzziness” around a routine : Alice likes a little variety. Not too much, but every now and then, mixing up the wines gives her a little jolt of satisfaction. Doing the same thing over and over may be efficient, but it can also remove some of the color from life. Deviation from the mundane can make life just a little bit more happy. • The lack of self-knowledge that we all have : Alice used to think that she only liked Sauvignon Blanc, till she accidentally had an Albariño, and now she’s hooked. Sometimes you need to be thrown a curve-ball to waken you to ...

/via http://turnoff.us/geek/welcome-to-hell/ I mean, I get it. You’ve got a complex application with a whole bunch of retained state that you don’t want to blow away if the user hits the back button. Except…you don’t. Really. In most (all?) cases, disabling the back button is a sign that • you haven’t thought the problem through, and/or • you didn’t have the time to implement it correctly and/or • you couldn’t figure out how to implement it correctly. And yes, I’ve heard the “ the application is way too complex ” argument too. Over and over again at that. The back-button needed to be disabled because • User information — name/address/… — was being collected on sequential pages, with the back-button blowing away information that was already entered (no it wouldn’t) • Shopping carts would get out of sync (no they wouldn’t) • Submitted information would get re-submitted (no it wouldn’t) and so on.  In every single case , we figured out that the application may indeed ...