Category: UI

Breaking Habits

Posted by on February 24, 2010

I just sat down with my wife and took her through Google docs. She wasn’t too happy about it. I tried to find some old copy of Office I could plonk on her new computer, but when that search was fruitless, Google docs triumphed over forking out more cash for (yet another) copy of Office.

On the first introduction to Google docs, there was a lot of kicking and screaming - what do you mean it can’t do that? How do you do this? That’s just stupid, why doesn’t it work like Excel? I knew this pain was coming, but I persevered because I knew that everything she wanted to accomplish could be done in Google, for free, and live permanently online (which was a bonus as the day before she accidentally deleted her entire My Documents folder - yes, she works in tech).

Sure enough, after a few weeks of working through and learning the new software, she is very content with her move online.

It interesting seeing this process first-hand, especially if you develop UIs (as I do now and then). A function that accomplishes an existing task in a different (but more efficient) way is normally loathed by the user. Especially if the efficiencies are ‘under the user radar’ - by that I mean small enough to not be individually noticed, yet in aggregate, meaningful.

When this happens you are trying to break a habit. Which is hard. Habits drive a considerable amount of our behavior because they are short-cuts we don’t need to think about. When you are forced to change a habit, you weigh the effort in changing against the perceived usefulness of the new approach. If the effort seems too much, you see a lot of kicking and screaming.

This is why you have to be careful with user feedback. Users want everything familiar, not necessarily better - because they don’t want to have to change their habits.

Sometimes you need to push through this barrier to a better place. Sometimes. It’s a fine line between functionality that improves the experience but breaks a habit, and functionality that’s simply different and annoying to users.

Either way, I suggest you try not to test too much on your wife.

Don’t click it!!

Posted by on August 18, 2008

I came across a fun site today that demonstrates just how much we rely on the ubiquitousness of the click to navigate the online world.

www.dontclick.it

It’s actually a piece of art submitted as part of a Masters Degree in Communications by a German student, Alex Frank.

It is both an incredibly annoying yet interesting experience all at once.

It’s like having no electricity in a black-out - you don’t realize how much you depend on something until you lose it.

Musings on UI Design

Posted by on August 4, 2008

One of the things I have become increasingly interested in over the last year is UI (User Interface) design. As we develop our software product, how it looks and feels to the end user becomes an extremely important part of the process.

And as we are developing it using the latest Microsoft technology, it was interesting to read this interview with Jensen Harris - one of the lead designers for the new Office Ribbon UI in Office 2007. Here is a link to Jensen’s blog post on the topic.

The actual presentation Jensen gave is a good watch. It’s impressive to see all the data Microsoft collects go to use in the design process (what does it tell you about work habits in the 21st century when the most used function in Outlook is ‘delete’ - 14x greater than the next most used function, ‘reply/send’?).

Having read and listened to the talk, here are my musings on the process:

1. There is no way - no trickery of layout, no fancy use of color palettes, no sophisticated code - that can really reduce the complexity of 250 separate functions in MS Word. The developers and designers are on a collision course with diminishing returns on simplicity. At some point, if a program becomes large enough, it becomes complicated.

2. The Ribbon UI - where all commands area accessed via a tab interface at the top of the page (see here) - is a useful innovation for the ‘average’ user. This seems to be partly the reason it was developed - to help more people use and utilize more functions. However, it’s not necessarily an improvement for the ‘power user’. It lets you master more functions, but doesn’t allow significant depth of mastery - the kind of depth that allows you to completely customize your UI experience.

3. The most significant UI design conundrum is designing for both the ‘average’ and ‘power’ user.

4. Don’t be afraid to give the user 2 or even 3 ways to access the same function. They will figure out the way that suits them the best. Everyone is different.

5. Don’t give the user 2 or 3 ways to access EVERY function - they will come for your head. The art in UI design, like all good creative endeavors, is to know when to stop.

6. Get out of the way. Don’t let the UI dominate the experience. Great UI’s are like hazard lights on a car. You should never notice them until you need them. And they provide a useful function.

I don’t think the Ribbon UI meets all of these challenges. It still seems bloated. But then, going back to point 1, you can’t design away complexity. You can only design for it.