unity-design team mailing list archive

[Diego Moya <turingt@xxxxxxxxx>]

2010/4/30 Martín Soto :
> The fact that human brains posses such a high plasticity, however, is no
> excuse for us not getting our act together. Whenever you change a UI, you
> will break someone's habituation to that UI.

Not if you support both interactions, the old and the new. In many
cases this is easier to do than it seems - just keep the old features
as deprecated, instead of removing them.


> Unfortunately, habituation is a
> very complex issue: For example, people can be very creative while working
> around a program's limitations, and this often involves using the program in
> ways that were never taken into account by its original designers.

You say that as if it was a bad thing.

So, you're not going to support those users that create their own
workflows? There will be only One True Way of using the system?

You can design for simplicity, or you can design for flexibility. You
can even do both at once, which I recognize is much harder to do. In
any case, you must make very clear which one is the house manual of
style. "We don't support that kind of users" is a valid reason to
close a wishlist bug as wontfix, but only if you have a clear
description of the supported users. This way people will know whether
they fit in the target group and when to back off from a discussion
about the system design.


> This means that, given a large enough user base, even changes that appear
> completely innocuous will likely end up irritating at least some users.

Maybe, maybe not. That depends on how do you handle those changes. If
you push changes down through their throats, surely you'll irritate
them. Managing change means that you don't just "do things" without
concern of how they will be received, only because someone will
receive it badly. If you care about it, you'll reduce the number of
users that get irritated.

Explain the changes upfront and try to shield users from the negative
effects of changes as much as possible. You can:
- release new designs only when they are complete (no more "we're
moving the window buttons so that in the future you'll get something
awesome instead!")
- release incomplete new designs as optional and opt-in, so it won't
affect your less daring or willing users - only the early adopters.

Benevolent dictatorship ("I do this way because it's what I think is
good for the project") is a traditional management style in open
software, but try to use it as a last resort if you don't want its
side effects - people complaining about the dictated decisions.


> Braking people's habituation will always cause problem, but absolutely necessary if you want to make progress.
Is it progress when you're making people inconvenienced? You should
take great care to distinguish progress from "change for the sake of
change". And when in doubt, refrain from it.

(Of course this won't matter if you keep those inconvenienced out from
the project scope).