Who Gets To Be Lazy? Users or Designers?

Jared Spool

March 8th, 2006

In response to my post, To Dash or Not To Dash, Dave Boggs commented:

There are times when its appropriate ask the user for the information again, even though the ‘site’ or ‘system’ may have it. An example would be in cases of database/information maintenance. When done correctly, asking a user to put in information the ‘system’ or ‘site’ has already is a great way to maintain and update user records.

I have to heartily disagree. In the best scenario, you get exactly the same information back that you already had.

In any other scenario, you get different information. But, different ≠ updated. If the new information contains a typo, you could be replacing good information with bad.

There has to be better ways to update information than repeatedly asking users to type the same information.

5 Responses to “Who Gets To Be Lazy? Users or Designers?”

  1. Jay Zipursky Says:

    Pithy comment for the day: The modifier “When done correctly” really covers the bases. The solution clearly only asks for the minimum information only when convenient for the user and catches typos or other errors.

    :)

  2. Chris Collingridge Says:

    I agree with Jared too. Why are you asking the user for information you already know? If you’re concerned that the information you have for them is wrong, what leads you to be concerned about this particular user? If you can’t tell whether any of your users’ information is correct, I reckon you probably have quite a big a problem.

    If you can tell which is correct and which is not correct, can you perform the correction without user involvement. If not, then maybe you can ask the user to confirm some information . .

    I’ve read this message back, and even I barely understand it. In summary: don’t ask things you already know the answer to.

  3. Kenneth Papa Says:

    If your goal is to solicit updates to a user profile from a user during the course of each session, perhaps a good solution would be to present data entry fields in a conspicuous place which are prefilled with the information that is presently held in the system. Perhaps a little ‘update’ button in close proximity?

  4. Kenneth Papa Says:

    Ok, now that I’ve actually read the original post that the reply was written for, I see this in a different light. We’re not talking about a garden variety user profile field which may or may not change over time, but a field which could be used for authentication.

    If forcing the user to re-enter a field of this sort is a necessary part of an authentication scheme, I completely agree that a conciencious (and properly funded) developer should absolutely take responsibility to provide the user with a data-entry field that accepts data in the form that it is given in other areas of the site. Of course, that kind of attention to detail too often falls between the cracks since so many developers don’t have a realistic means of coordinating those things.

    On the other hand, if forcing the user to find and re-enter this type of information is not absolutely necessary it should be avoided at all costs (unless of course your manager makes you do it in the interest of ‘saving time’ on the project schedule).

  5. Kenneth Papa Says:

    Who gets to be lazy? Realistically it’s often more of a question of ‘at what stage’ do you get to be lazy. Shortcuts taken at one stage can and will often come back to haunt you later on. That’s why its so much fun to take over a project midstream behind someone who is a real artist at quickly getting credit for doing well on early stages of a project by shifting all of the hard work to the latter stages. For instance, a badly designed and/or implemented feature can quickly get you through that line-item on the schedule, but eventually someone has to create the help and training media, train users, answer their help-desk calls, figure out that the problems they are experiencing are really an indirect result of their failing to understand how to properly use the badly designed feature, communicate that to them etc. God forbid that a decision be made very late in the game to go back and redo that feature. So… following our before-mentioned artist who shaved 3 days off of the schedule during his ‘watch’ and has now been promoted on to a higher office, you, the users and who knows who else have had 2 man months of work injected into what was an already unrealistic schedule.

Add a Comment