unity-design team mailing list archive

[Martín Soto <donsoto@xxxxxxxxx>]

2010/5/13 Diego Moya <turingt@xxxxxxxxx>

> 2010/5/13 Martín Soto:
> > Or you implement the automation properly so that it reliably delivers the
> right result.
>
> The "right" result as defined by who? The designer or the user?
>

By the designer, of course. It is his task to determine how the product
should behave.

 My fridge has a thermostat control to set the desired temperature and it's
> from the best brand in my country.


This is obviously not what I'm talking about. A temperature setting knob is
sensible. A button that overrides the thermostat and lets you start and stop
the freezing compressor by hand, isn't.


> If I'm going to buy a lot of
> food this afternoon and I need the fridge to be extra-cool in advance
> to keep the unbroken cold chain, how is the fridge supposed to
> automatically know that in advance? (Hint: my freezer also has a
> manual Extra-Freeze button that overrides the thermostat wheel and
> keeps constant cooling for a day).
>

It overrides the temperature *wheel* by temporarily setting the desired
temperature to the minimum available. It's doesn't deactivate the thermostat
letting you turn the compressor on and off at will. Automation is still
working, even when you press that wonderbutton.


> I agree with the "all over the place" part, but IMO you MUST have an
> override (a "manual safety switch") for all complex functions that try
> to automate user goals


The keyword here is "user goal". To go back to the actual topic of this
(sub)thread, we are speaking about automating the volume setting for the
notification sounds, nothing else, nothing more. I contend that setting this
volume is not a user goal. On the other hand, being able to hear the
notifications appears to be much closer to whatever the user goal is. This
way, automating the actual volume setting so that the notifications can
always be heard seems like a proper design goal.


> Of course calculations for physical processes [a thermostat to keep a
> temperature] don't need to be overridden (they have a precise
> definition, and either they're correct or there's a bug).


Sound loudness can also be measured and calculations can be made to set the
volume of a sound in such a way that it can be heard on top of another one.
This is the point here.


> [OK, there are some automations that don't need to be exposed
> directly. The water dirtiness detection in my fuzzy Japanese washing
> machine, I don't want to manually override. But then, there is a "my
> clothes are extra-dirty" button too.]
>

The number of hidden automations in our daily lives boggles the mind! If
they all had an override mechanism, our world would be full with red buttons
behind Plexiglas covers. I'm glad this isn't the case, by the way.

So you're suggesting the proper design is, "I've thought of everything
> you can do in advance, everything else is impossible. If you want to
> do something I didn't think of, then look for some other product "?
> ;-)
>

Now we´re starting to understand each other! Although you're expressing it
in a weaselly sort of way, this is indeed the main idea. I'd rather put it
like: "I'll do my best to identify your needs in a particular, narrow area,
and come up with a product that addresses them properly. Afterwards, you're
free to decide if you want to use it or not." This is not about imposing
anything on anyone, it's about designers taking responsibility for their
products. As counterintuitive as it may be, understanding and addressing
user's needs is the designer's task, not the user's task.

Picking a narrower scope makes your design more manageable, but it
> doesn't address the need for manual overrides in the features that
> made the cut. Even if you could predict all possible situations in
> your given scope, that won't prevent you from defining the wrong scope
> in some subtle way that will only be apparent when your users are
> manipulating the software.
>

In this case, you look at people using your software (or a prototype of it)
identify the problem, and fix the design accordingly. And if they really
have special needs, they should use special software. No need for override
buttons here.


> So no, even though I'm a big fan of user-centered design I don't buy
> the "I know exactly what's best for you" (for a narrow definition of
> "you"). You can still design flexible products that degrade gracefully
> for users outside their predicted scope.
>

Interestingly enough, user-centered design is a lot about "I know exactly
what's best for you", although not in the arrogant way you're trying to make
it sound. It's about working hard to understand what people really require
in order to perform a particular task (this is often not what they think
they require!) and about providing exactly that to them.

In this sense, the idea of a product that "degrades gracefully for users
outside the predicted scope" is sort of contradictory. In order for the
product to behave gracefully, you must understand how it's going to be used,
but if the use lies outside your intended scope, how are you supposed to
understand it? Thus, "degrading gracefully" actually means expanding your
scope to cover a larger set of use cases, which can easily take you to the
point where you're not able to address any of those cases properly with a
single, manageable design.

Martín