Developing websites for data entry

Andrew picture Andrew · Feb 8, 2010 · Viewed 7.9k times · Source

We are in the process of developing a website to replace an old green screen data entry application. The problem is that our users are accustomed to FLYING through the screens (i.e. blind typing ... they never need to look at the screen or their fingers). They are very nervous about moving to the web, and I was hoping to assuage this nervousness by showing them some examples of sites that handle data entry well.

Any suggestions?

Update

To clarify the "flying through screens" comment, here is the typical use:

  • CSR logs in, has stack of customer bills sitting beside her
  • User clicks E and enters custom name from top of bill
  • User enters billing/invoice information from bill, this is stretched across 5 screens but user never needs to look up from bill
  • All typing is "blind" (since they don't look at keyboard or screen) ... they are averaging over 50wpm throughout data entry (which is a VERY fast average) ... and experience no waiting
  • There are many keyboard shortcuts along the way, i.e. for dates, user lookups, item lookups, etc. User has no need to look up from the screen when typing these
  • Once done, user clicks P to preview and views invoice/statement on the screen to verify totals and items
  • Error rates are below 1%, extremely good for manual data entry

Answer

NotMe picture NotMe · Mar 5, 2010

Unfortunately, fast data entry != web app.

If you must do this, then

  • keep javascript to an absolute minimum. We're after entry speed after all and who knows which browser they will be running. If you decide to put something in there to automatically take them to the next field, make sure the green screens were already doing this AND that you mimic that logic exactly.
  • Make sure the tab order of your elements are exactly what the green screens had Otherwise they'll hate it no matter what you do or how much "more efficient" you think it will make them.
  • Make sure the pages have exactly the same fields as before.
  • Basically, don't even think about reorganizing anything right now. The change from terminal to web is already going to be upsetting. However, if everything works EXACTLY like it did before then it will be minor grumbling instead of outright revolt.
  • Skip any graphics. Use simple css for styling / coloring things. Any graphics will slow down page loads, sometimes just a little.

Just to iterate, keep it simple, do exactly what was there before, minimize both page size and page artifacts (css, js, images, etc), do NOT introduce anything else that is new. Change Management can be a difficult thing and no matter what you do bear in mind that you are changing their work, even by just a little. People who are attracted to data entry jobs never like change and will grumble. The only question will be in how much.

After it's deployed and starting to be used, wait a month or two before you start listening to feedback (other than outright bugs. Fix those immediately). This will give them time to get used to it and start making non-emotional suggestions.

Grow some thick skin. At some point a VP or high level manager is going to be campaigning to go back to the old way of doing things. That's fine and should be expected, they don't like change either even if they were the ones who asked for it.

Next, don't expect the data entry team to even look at your app until it's deployed. Sure having a couple people from their team look at it every now and then (even test it) sounds like a good idea. However, they will think they have "better things to do" and won't provide any usable feedback until they are forced to use it because they have no other option. Expect this.

Finally, make sure you have exec level support BEFORE starting down this path. At some point they are going to come face to face with data entry managers who are unhappy. It helps if they believe going back isn't even an option.