This question I'm going to break into two parts, the back story, and the real question.

The Back Story
I work for a consulting firm, and we've developed a piece of software that allows a company to manage their real estate. They rent out around 1,000 apartments and houses, and the software tracks what's rented by whom, who owes what and what for, it tracks the properties and rental units owned, and maintenance reports. It also manages the billing.

So it is a fairly complex system.

The company we created it for makes a point of paying minimum wage for their jobs and hires only females and does not require computer literacy. They also won't waste money on training new hires because they usually only last a few months.
Therefore, the software was commissioned to have a "fisher-price" interface, and it should be as simple as McDonald's interface is. The only problem is, McDonald's probably spent millions designing theirs, and McDonald's has a more simplistic business model, and they train their users.

Despite all this, I feel I have built a fairly intuitive interface, and I've had some guys in the office do user tests for me. The results are good, I've fixed a few things that I wouldn't have seen because of my closeness to the software, but overall, the achieved all or nearly all the tasks in the user test without training.

However, there is one user in particular at this company that cannot figure out how to use the system. Two months ago she changed around 50 tenant's lease dates. I corrected that in the database and all was well for a little while. Last month we got reports that the system was reassigning people to new living quarters, but it was her changing them. So I put a lock on that, so you can't change the tenants living quarters without clicking a big "Unlock" image button. That seemed to fix the issue. Then two weeks ago we got a report that the system (always the system's fault) was renaming properties. It turned out the user thought she could search from the Property Name textbox (labeled "Property Name", there is a button with a magnifying glass that says "Search" far away from it). So now the form to manipulate properties is locked in the same way tenant's is. Yesterday, the system was once again changing lease dates, and the logs showed it was the same user. They want me to lock down the lease date the way I have property name and tenant living quarters, but I think it has gone too far.

If I make the change they request, they will continue to blame the software (and the consulting firm) and not take responsibility for their lack of training and skill in their users. It also wouldn't actually solve anything, until every input field was required to be unlocked before it could be edited. They won't pay for documentation such as a user guide or help files to be created, which is the only way I am seeing that it can be fixed.

The Problem
An untrained user is continually entering bad data in nonsensical locations (such as phone number in the license plate field). She deletes or changes critical system data that she normally has to edit. The customer has requested I add an additional click to editing the data, but I feel that won't solve the problem, just make it move to another field.

What can I do to prevent this bad input that is not significantly different from good data?

  • 15
    I'm not following why employing only female staff leads to a requirement for a 'fisher price interface'. Perhaps a positive step forwards would be to educate your client!
    – Splog
    Commented Nov 3, 2010 at 15:39
  • 3
    I think the fisher price interface more comes from the "paying minimum wage", "does not require computer literacy" and "won't waste money on training" parts. Commented Nov 4, 2010 at 19:07
  • 2
    Agreed with Splog, gender of users is irrelevent. Commented Nov 4, 2010 at 21:27
  • 6
    I was making the point with the gender not that the gender is an issue, but rather that the hiring practices at the client's office aren't based on skill.
    – Malfist
    Commented Nov 5, 2010 at 13:11
  • 2
    Sounds like the 'bad user' has presented some valuable design opportunities.
    – Jay
    Commented Jul 18, 2012 at 12:05

8 Answers 8


It turned out the user thought she could search from the Property Name textbox

This is a very common problem actually. It's not obvious to your users that they are changing the record. You a mixing display of data and modification of data - not very "Fisher Pricey".

"Search" should return a read-only list or record.
Only when clicking "Modify this record", the fields should be editable - and the edit should be modal: don't allow any other commands but "Save Changes" or "Cancel".

It's hard to give recommendations without knowing the app and the actual business procedures, but here's what I'd throw in roughly:

  • A start page to select an action (e.g. "Search Tenant", "Search Location", "Quit this fracking job")
  • For each action, a single page, e.g. one search page
  • If the search returns multiple results, list them on the search page (read only!), so the user can refine the search, correct spelling etc.
  • Clicking a result, or executing a search with a single result gets you to e.g. the "Tenant Details" page. Still read only. On this page you can
    • return to menu
    • hire / fire / move /edit tenant
    • ...
  • acessing other search results from this page (e.g. a list on the side, a drop down list, a "Prev/Next" button pair...)
  • Again, every action, e.g. "Move Tenant" has its own page

Although this might seem counter-intuitive, this user may be a blessing in disguise. One "bad" user can give you more information on a site than 10 "good" users. Especially if you are trying to design for the lowest common denominator. If the goal of the system is to create a way for untrained people to work with it, you have to take into allowance for this user.

For instance, locking the logs sounds like an interesting idea that would help prevent inexperienced users from making errors.

This goes back to good interface design principles. Mainly, the "interface is complete when the user says it is."

Her problem when trying to "search from the Property Name textbox (labeled "Property Name", there is a button with a magnifying glass that says "Search" far away from it)" may be a usability issue right there. Based on your description, it seems reasonable that she could make an error.

Have you tried talking to the person that making these errors? I suggest sitting down with her and actually watch her work with the system. It seems that she might be able to give you some insight as how she uses the program. It is always better to see what they are doing because people don't tell the whole story (they may feel embarrassed, tell you what you want to hear, or simply forget).

The information you get from actually seeing her in action will dictate what steps you need to take. Is the wording confusing? Does she get distracted at the workplace? Does she multi-task and make errors? Is the "fisher-price" interface clash too much with her expectations? All of these can be answered by observation and careful questioning.

IF, at the end of the day, training is needed then make a business proposal and include ROI information. You have to convince them that it is in their best interest to pay for training. BUT training usually is not the solution for an interface problem. By working within the expectations of users and building on their existing knowledge, you don't need extensive training. Think: Gmail, Word, Outlook. You probably don't read the user manual for those.

  • By "Far Away" I mean on the toolbar at the top of the form where all the buttons that perform actions are, whereas the textbox for Property Name is where all the data entry controls are.
    – Malfist
    Commented Nov 3, 2010 at 15:07
  • The forms have to distinct areas, actions and navigation are on the top, data entry is on the bottom. The only action on the bottom is the close button.
    – Malfist
    Commented Nov 3, 2010 at 15:11
  • 1
    You see, the proximity you set on the page doesn't really matter if the user isn't getting it. Also, there are pages that break the rule of search bar in the top right.
    – Kevin G
    Commented Nov 3, 2010 at 16:30
  • 5
    Basically, look at it as this: The user always acts in a way that is logical to them. If they are making mistakes, then there is a disconnect between the her and your product. You have to bridge that gap. Again, watching what she does (or doesn't do) will give you invaluable insight. Also, ask her to "think-aloud" so you can see her thought process.
    – Kevin G
    Commented Nov 3, 2010 at 16:32
  • I completely agree. One user can give large amounts of insight. The Property name is a good example. Maybe change the field to "Edit Property Name."
    – surfasb
    Commented Oct 11, 2011 at 13:58

One thing is unclear from your question. After she made an incorrect change, is she aware that she has made an incorrect change?

  • If not, it suggests that the software lacks some necessary feedback to the user.
  • If she is, then the real problem is why she does not correct the error that she has introduced even though she is aware of it. If she simply lacks responsibility, improving the software is not very relevant. But if she wants to correct it and does not know how, there should be something which the software can help. One thing might be to provide the user with the ability to undo last changes.
  • 1
    The lack of feedback could be an issue.
    – surfasb
    Commented Oct 11, 2011 at 14:00
  • Start logging all critical actions.
  • Reports all changes to a boss. You need facts to resolve all issues.
  • Restrict access to other critical parts of application: show one window to this user and nothing more :).
  • Start shadowing to investigate user's activity.
  • Deny any changes to previous saved data (for example, that were changed 1 day ago).
  • Try to add additional checks (phone number format, number input, string length and so on) to the problem inputs.
  • Start edit data in the separated form, all grids are ReadOnly!
  • ..
  • Recommend to fire: I don't know, if she is not a boss' relative ;)
  • Hire these people as testers to run your business! :)
  • All actions are logged, because we've had things like this in the past. The user has to have access to that part of the system because she normally edits it. However, even if I restricted the data entry, I feel that she would just find another field to enter bad data in. As for getting her fired, another would take her place, that would probably be just as bad (They have about 3 people using the program at once, usually there's always one bad apple who does something really stupid about once a month).
    – Malfist
    Commented Nov 3, 2010 at 14:43
  • 1
    @Malfist Deny any changes to previous saved data (for example, that were changed 1 day ago). Try to add additional checks (phone number format, number input, string length and so on) to the problem inputs. (i have updated my answer)
    – igor
    Commented Nov 3, 2010 at 14:54
  • But that's the thing, the specific problem this time is that she was changing the dates for the lease contract. I.E., the data was valid syntactically, but logically (in a way I don't know how to test for) doesn't make sense.
    – Malfist
    Commented Nov 3, 2010 at 15:21
  • The previous saved data is stored, kinda, in the log. Actually implementing a loss-less revisioning system for this is actually a really good idea, but may take a while to implement.
    – Malfist
    Commented Nov 3, 2010 at 15:23
  • "but logically (in a way I don't know how to test for)" That specific issue is due to a lack of requirements to create business logic around.
    – DA01
    Commented Nov 3, 2010 at 22:13
  • Provide a confirmation dialog.
  • Provide tooltips explaining what each field does.
  • Provide submission buttons that indicate their action, "Edit" not "Submit".
  • Provide administrative logs.
  • Provide an administrative approval process.
  • Provide an undo command.
  • Provide a lower level of access for normal use, i.e. default by view only.

The following might also be conditionally appropriate.

  • Restrict the user to lower level access.
  • Provide restrictions on the user's capabilities, such as number of overall edits during a time period, or editing records based on specific criteria.
  • Confirmation dialog gets ignored. Tooltips are present. Edit/Submit doesn't go well with a desktop app, administractive logs are present, administrative approval process, wouldn't fix the problem because that's not the issue, undo command is avaliable, read-only by default would not work because the purpose of the user is to edit and enter new data, only during billing do they just look up data. I can't restrict the number of edits the can do because that would be counter to the software's purpose.
    – Malfist
    Commented Nov 5, 2010 at 13:16
  • Could you elaborate on your point on Edit vs. Submit? And the administrative approval would be addressing your problem, that being an employee who changes the wrong data and an administrator who is blaming it on the system. If the administrator is forced to view the changes and who makes them before (or even after they go into effect) at least the blame should be properly placed. Commented Nov 5, 2010 at 14:31
  • 1
    Also, read only be default is the expected function for many users as @peterchen has also described, even in an app primarily used for editing. If there is a field for editing, the whole page should be only for editing, labeled clearly as such and reachable only by explicitly going to edit a record. When the user marks their changes as final, everything should indicate that changes are being made. Words like "submit", "ok" or "continue" should be avoided for intention such as "edit", "change", or "save". Commented Nov 5, 2010 at 14:40
  • "Deny any changes to previous saved data (for example, that were changed 1 day ago)." Wouldn't that preventing "Oops, I made a mistake, I'll just go back and change it"? or "You moved once, you can't do that again".
    – Lenne
    Commented Dec 4, 2018 at 9:07
  • @Lenne It would prevent an edit if they didn't realize the mistake until the next day, but you could have an administrator fix those problems if they are infrequent. Commented Dec 4, 2018 at 20:10

"was commissioned to have a "fisher-price" interface"

I purchased the Fisher Price digital camera for my kids several xmases ago. The software it came with would make my list of truly awful interfaces.

Anyways...you know what the issue is. Either your company needs a better way to communicate that to the customer, or they need to consider finding a new customer.

OR...your customer needs to invest a lot of time and money for you to build much more complex business rules. Of course, that'd probably cost more than if they'd just invest in a bit of training.


One other thought...how about a 'wiki-esque' undo interface? Don't actually change ANY data in the system but instead version each and every record. Then develop an 'undo' or 'rollback' interface. That way the business owner can deal with fixing all the mistakes her staff is making.


In addition to some of the answers already given :

  1. In the screen where fields can be edited, make clear that a field has a changed value. If the first name “Nicolas” has been changed to “Peter”, give this field an orange background. And put a pencil next to it, with a caption that says “You have written a new value for this field, but you have not saved it yet.” And, if the user writes back the original value “Nicolas”, drop the orange background and the pencil.
  2. Near the Save button, add a sentence that says : “You have written new values for the first name, last name and phone number of this tenant. Click Save if you want to record these changes.”
  3. After the user has clicked Save, put this sentence at the top of the screen : “You have changed the first name, last name and phone number for the tenant T01789456.” With an Undo button.

Access control

It seems this user is changing fields which are outside of the scope of her duties. (If these parts of the interface were related to her duties, then I think she would know what they do, and not misuse them,)

One way to prevent this would be to restrict the user to modify only those parts of the data that they are responsible for.

Don't show the user parts of the interface that are not relevant to her duties. Don't give her access to modify data which is not relevant to her duties. Easier for her to get her work done, safer for the data.

This could be done by assigning a role to each user, or giving each user a set of access permissions. (The former may be preferable for a large user bases. The latter may be preferable when each individual needs a unique set of access permissions.)

Once the user becomes familiar with the system, it might be possible to open up access to other parts of the interface, according to need.

  • Of course this can not apply to those fields which are part of the user's normal duties. But simplification of the interface might still help by making the app less confusing for the user. Commented Nov 28, 2018 at 3:02
  • I do agree with the other answers which recommend making it clearer when an edit is being made, requiring confirmation for edits, displaying what has changed when an edit is submitted, and (failing all else) an undo mechanism. Commented Nov 28, 2018 at 3:02
  • I also like the idea of sitting with the user and understand her workflow, so the interface can be designed to meet her needs. Commented Nov 28, 2018 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.