When flexible becomes broken.
I've recently learned or relearned a lesson.
We've produced an application using our best knowledge of UI, human behaviour, domain knowledge and all the rest of it. The application is flexible, the user can take many routes through the process but unless they pursue those different cues they won't necessarily be obvious.
In other words the users were intended to be able to use the application in the way best suited them, without restricting them too much.
The target users were mostly inexperienced in using computers but had used some order entry systems.
Although it achieved some of UI goals, it didn't frighten them, it recorded reliably what they did and apart from a few glitches didn't dump them on their bottoms; it failed in one regard.
The users almost all made the assumption that the system knew more than they did and assumed that because a contact form had a particular name on it, if it was the wrong name they could simply edit it and it would create that contact, not change it and change it for all the places that contact was used.
The system would know what they intended to do because in all its behaviour that's what seemed to be happening to them. By making it so flexible we conned the users.
Part of this con is because they'd been exposed to rigid systems in the past, systems that only let you do things the way they wanted.
So now, we've had to tighten down the hatches, restrict not the flexibility so much as to give even more cues to the user, restrict them from editing when they're searching and so on.
Simon Lucy
Friday, May 28, 2004
I don't think it's a question of flexibility, but one of ambiguity.
You should have a speciific edit form, whiich should look different from the read only form you use for searching. You can have an edit button on the search form.
Flexibility is about making it possible for users to do things right; not making it easy for them to do things wrong.
Stephen Jones
Friday, May 28, 2004
Simon,
Not quite following you.
Were they trying to copy contact forms by loading an existing one and changing the name, as they would a word document?
Ged Byrne
Friday, May 28, 2004
The search dialog is different to the regular form, and you have to explictly click the edit button to enable edits on the Contact form.
The fault really was that if the search failed, even though they were told it had failed, the subsequent form was positioned on the last contact they had ever dealt with.
There were two possible solutions, presenting a blank Contact form, or disallowing edits at that point. I chose the latter.
Simon Lucy
Friday, May 28, 2004
Ged,
I think that was part of what they thought. But also there was a feeling that it was the 'wrong name' and so should be edited.
Simon Lucy
Friday, May 28, 2004
Just so I understand, they were executing edit-user() when they thought they were executing search-for-user()?
I would like to seriously dev on the Mac sometime. Its fascist approach really seems to make usable software for end-users. (Though I'm not sure about so-called "power users.") Plus it provides a really nice frame for one's programs. People probably can't make good paintings, knowing they'll ship with a fraying $2 cardboard frame.
Tayssir John Gabbour
Friday, May 28, 2004
"There were two possible solutions, presenting a blank Contact form, or disallowing edits at that point"
Why not send them back to the Search screen? I'd be confused too if I searched for something to edit, and the search resulted in what appears to be a match that I'm not allowed to edit. That's not what I asked the system to do for me.
Tom H
Friday, May 28, 2004
They do go back to the search dialog, till they cancel or close it.
Simon Lucy
Friday, May 28, 2004
The process that most often screwed up was connecting a contact to an order, most likely the delivery contact.
Originally, the entire process was separate steps, click on the contact control, launch a contact form, they could search, navigate, edit, append etc. This liberality confused them and they didn't like the number of steps to find and connect someone. So the process was shortcut to launch the search before the Contact form and so on.
In any event the confusion in their mind was because they didn't realise that a Contact was more than just a name and that changing it there changed it so far as everywhere else was concerned.
There's one point that probably needs making clear which explains why contacts are so free form. The deliver to contact could be anyone on the planet, it might be a regular person for that customer or it might be someone entirely new. Its a retail business.
Before they'd never really seriously stored who was getting an order, now its recognised as being important.
Simon Lucy
Friday, May 28, 2004
Why couldn't you just check the contact after an edit. If the contact information changes then pop a dialog asking if they'd like to create a new contact or save to the old contact?
If that is the only thing wrong with your application it seems pretty good!
NathanJ
Friday, May 28, 2004
Yes, that was a reasonable thing to do and if might be how we have it behave in future. Actually making it not editable was a way of proving to the users what had been going on.
Now they know and it can be highlighted in future training iwe might change the behaviour. The only thing that makes me wary about questioning dialogs like that is often the user becomes confused, or hits the wrong button and then its broken anyway.
What I'd really like to do is have some kind of nearness algorithm where we can detect if the name changes radically or just slightly, and then if its a radical change pop up something informative, since sometimes people do radically change their names.
I might look at doing a character diff on it.
Of course there are other bugs, this was just the major one.
Simon Lucy
Saturday, May 29, 2004
Recent Topics
Fog Creek Home
|