wouldn't take the chaos relationship any further than what I said - small
changes can have major affects. As for user expectation, here's a real
engineers were designing a small text-based, command language UI for
managing the recovery CD for a computer system. The objective was to allow the
user to just reinstall the operating system without reformatting the target
drive but with the option to reformat the entire drive. The UI looked perfect
to me - made sense, was straightforward and was simple. My expectations
were that the user would just follow along naturally and would be successful.
I was so sure of it that I came close to recommending that we skip the
usability testing and save some money. But that wasn't the professional thing
During usability testing, 3 out of 4 users failed and ended up
reformatting the entire drive. The problem was that my expectations were
unrealistic. I was familiar with the need for a CD to take a few seconds to
spin up - seemed like waiting just a bit was perfectly natural and I expected
the users to do that. They were unfamiliar with the use of the CD and expected
it to be immediately accessible just like a floppy drive would be. When they
got the DOS response of not being able to read the CD, they immediately went
back and took the other option thinking they had done something wrong.
moral of the story is that you can't rely on your expectations of what users
will do. Your expectations may be right 90% of the time but, just as you
wouldn't trust a computer that was right 90% of the time, you don't want to
rely on your expectations of what people will do unless there is no other
option. It makes sense to study users to understand possible design options
and then to test your design to see how right you are.
experience with UI changes is user expectation. If the user expects to click
a button, change the button to a field, they will click on the field until
they unlearn to click. If users are used to doing something when they
see a red block on the screen, change that color to blue, they will wait to
see red until they unlearn to wait. Even if you tell users which changes are
made and where, users still has to unlearn and relearn on their
I've also found that users navigate an interface in a very
specific way in sync with their "physical navigation". Minor changes in
UI will affect navigation both on the screen and in the "physical
environment". Things are used in ways never intended for reasons previously
I've found it much faster to make a change, see what happens, than to
figure out all of that navigation stuff..
Also, this mention of chaos. Is it being used to mean
"unpredictability", or is it being used in the scientific
science, if usability is chaotic, then there are patterns in the changes in
(order in chaos).
Any models come to mind?
did chaos experiments with analog computers and motors. Not sure if that
stuff is mappable to software though.
Tom Landauer has suggested that usability is Chaotic, small changes
can have major affects. I have seen this myself with some UIs although,
for most, small, non-functional changes have had minimal or no
But it really takes usability testing to verify the affect a change
has on a user. The problem is that, for users, changes to a GUI are
not pixel changes but changes in the gestalt of the UI and how it affects
users' perceptions and cognition. We normally can make a good guess as to
what affect a change will have but we can also be surprised on
anyone know of any research done on users reactions to changes in the
looking for things such as
whats the time taken to re-learn a subtle change/medium change/
you change the UI to improve the usability - how long before the
customer is comfortable in the new system.
you improve the usability - is the user happier with the better UI once
they have learned it - or does the cost of learning outweigh the
benefits of change
course, Im sure these questions have a variety of answers depending on
pointers to work done most appreciated,