How and when to go about challenging a tried and true user behavior?

Question

There are many user behaviors that have been ingrained in us over time. Some of them good, and some of them just because, "that's the way that it has been done for years, people expect it." The problem is, in some cases you can come up with an easier or more sensible way to do something. An example:

Apple has changed the orientation of scroll bars to match that of their touch interfaces for OSX Lion. They have changed the scroll behavior from scroll down to move down the page to "pushing" the content up to scroll down the page, which is the opposite to what most of us have been doing for our entire lives of computer use. Based on some user feedback, some people resist it and some love it. Although, most that initially resist it have come to prefer it in the end. For those who absolutely cannot get past the change, Apple has allowed users to set it back to the old way if they must.

So the question is, when is it ok to challenge an accepted convention when you have something that you feel is better? Conventions should not be challenged often and in a way that is just change for the sake of change, but when is it okay to implement something new that you strongly believe will benefit users in the end? Also how would you suggest going about doing this, as most changes would be met a fair amount of initial resistance?

Answer 1

You asked 'when' and 'how'.

When

• Break conventions when you have convincing arguments for your new method being dramatically better in a heavy use area. If use is light, then the cost of learning the new method outweighs the small gain. It's nearly always power users, i.e. the heavy users, that motivates your convention breaking. You need enthusiasm from them after the initial road-bump. You need their input to get the feature perfect. If you've only casual users, don't go there.
• Break conventions if your application has an unusual pressure on it, such as dealing with an extremely large tree, then there are decent chances you've good motivating arguments for your new approach. If you've not been driven into breaking convention, you probably don't have enough justification for doing so.
• OR: Do it if it's not really a break in convention at all, but something new. Examples are new conventions following from multitouch. It's a game changer - UX changes follow from it. From the touchscreen perspective it's not a breaking of the old conventions at all. Fingers aren't mice.

How

• Assuming you already have an application that is doing it the old way that you are adapting, offer the new way as an option. (what Apple have done with reversed scrollbar). It can be a configuration option, or it can be different view choices in your app.

• If either old or new must be the default what then? Ideally design so you are not forced to make that choice. If you must choose, have faith in yourself - make the new the default.

Over time build on the new method - and only elaborate on the old method if doing so is virtually for free. This helps migrate people to the new way, and it avoids excessive work in maintaining two ways to do the same thing. You don't have to add features equally to both old and new. This kind of evolutionary change when you make a break with the past is likely. Breaking the convention may be an enabler for future functionality. For example Apple making scrollbars work in the same direction as dragging is an enabler for variable speed scrolling. A porthole-on-screen-keyboard rather than a QWERTY one may be an enabler for a smarter predictive text UX.

In Practice

The biggest problem I've had in convention breaking is discoverability - discovery that an area is active, or that an item can be dragged. Particularly so for small targets.

It's not been a huge problem. Users usually know 'I want to do something with this thing', and once they mouse over the thing and see the cursor and object change the rest follows. It's not how complex the action is that's mattered - it's discovering that it exists at all.

New UI elements need additional work for accessibility and to make automation easier - I've never had time budgeted for these aspects. That's really where the 'old ways' using more conventional UI elements have come in.

It's been well worth it. It's led to interfaces that use fewer clicks and that are more responsive.

Answer 2

I think that the only way to answer the question "when is it ok to challenge an accepted convention" is to do real user testing with real users. Get a group of people that represent your user's and give them some tasks using mock ups of the changes and see if they get it. This is also a good example where user comments and opinions would not be valuable but watching how they use the new convention would be.

It would also be important to test the method of changing the behavior to ensure that the users who have trouble with the new convention are able to change it.