← Back to team overview

unity-design team mailing list archive

Re: Reducing Resistance to Change

 

2010/4/30 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.
>

In many cases, though, it sounds easier to do than it really is. You leave
the old features around and people will stumble upon them at the worst
possible of times. Old, poorly designed features often also get in the way
of a clean and straightforward design. But this is something we should
discuss on a case-by-case basis, rather than at this generic level.

> 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.
>

It's not good or bad, that's just the way it is.

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?
>

I simply doubt that, in the long term, it is viable to support every single
conceivable way of using a particular UI. People end up standardizing in a
single way of doing things, and this makes sense, because otherwise the cost
and complexity would become unbearable over time.


>
> 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.


Maybe so much harder that it becomes impossible in practice. But once again,
we should discuss this on a case-by-case basis.


> 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.
>

I agree with you here. As others have already pointed out, having some
personas, for example, would be very valuable for Ayatana.

[...]
> 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.
>

Given the sheer size of the Ubuntu community, any design that attempts to
satisfy everyone is very likely to be a design that ends up not satisfying
anyone. The design team is making relatively bold decisions, and this is
probably good because it will likely result in a design that is satisfactory
to a significant number of Ubuntu users. A significant portion is not
everyone, however, so this also means that some people will end up
dissatisfied with the results. It is not surprising that at least some of
these people complain loudly, but I can't really see a way around that.

> 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.
>

If a large number of people are served by the changes, it is probably OK if
some people are inconvenienced. Particularly, in this case the changes don't
make it impossible for the inconvenienced people to use the new system, they
just break their habituation, but habituation can be rebuilt by using the
new system for some time, so this is not catastrophic. Of course, telling
exactly how many people will be served by the changes and how many will be
annoyed by them is very difficult, and designers can make mistakes in this
regard as well, but I don't think anyone here is trying to annoy people just
for the sake of it.

Martín

References