After several years of writing on this blog, I realized last week that I rarely write about the exact field I work in full-time, every day: User Interface and Interaction Design. This will be my first post about a design challenge I had this spring and summer: Designing a Web Interface for 10-Key Users.

Background

For a lot of designers, the real challenges are not in designing a cool teaser page or a food fetish website. The bread-and-butter for us comes in redesigning outdated user interfaces (UI) for corporate users. For the past two years in my career, I’ve worked on customizing web portals, document management systems, patient and practice management systems, and now, insurance claims processing consoles.

My current project entails customizing our out of the box patient and practice management system for 1000+ daily users, and then designing and building an entirely new insurance claims processing console for roughly 25 users at the client’s headquarters. For one specific interface, the requirements dictate that:

• The user must enter 12 pieces of data per line (up to 6 lines), but be able to view over 25 pieces of data for each line.
• The user must be able to use the 10-Key pad to enter these values

We know that the user processes about 100 documents per day, and, like any re-engineering project, we shouldn’t increase this time; optimally we should reduce this time.

Finally, their current interface is a desktop application, where they enter all this data into a grid with massive horizontal scrolling, no fixed left header, and a color palette of grey, black and white.

Methodology

Step 1: Do Some Research

The first topics to research are data-entry forms and 10-Key user behaviors. 10-Key refers to the user’s ability to rapidly enter numerical data using the keypad on the right of the keyboard.  When you do a search online, 10-Key brings up a lot of 10-Key tests, but not a lot of information on how these users behave.  If a simple search doesn’t bring up what you need, head to Google Scholar and try to locate academic research.  I found:

“From Information Visualization to Direct Manipulation using ILOG Discovery” by Thomas Baudel

In this paper, the author’s Visual Framework (directly pulled from the paper) is the biggest take away:

1. Partitioning a data set in groups and subgroups
2. Sorting the groups and the individual objects
3. Assigning graphic primitives to groups, subgroups or individual objects
4. Decorating the graphic primitives (assigning color and other graphical attributes)

I had two ways of creating groups and subgroups:

• First Way:  Data the User Entered, Static Data the System Presents, Data the System Calculates off of the Static Data
• Second Way: Data by Groups, where each group has a piece of data entered by the user compared to static data, which the system uses to calculate a third data.

Step 2: Design Iteration 1

Based on this information, I did a preliminary design based on the “First Way” grouping strategy.  This let the user view static data and then select an option to enter the additional data by line.  The interaction became “Click, View Modal Pop Up, Enter Data, Close Modal Pop Up, See Calculated Data”.  While the Modal Pop-up was positioned so that the user could see the static data while entering the new data, the piece of feedback I got from the client was “That’s too many steps when you’re processing 1-6 lines per document, over 100 documents per day.”

Step 3: Iterate

The worst characteristic of a designer is stubbornness; you have to be able to process feedback and iterate.  The goal now was to reduce the amount of steps, while still being able to view all of this data in one screen for each line-item. If I didn’t already state this, when you are confined to 950px in width, 20+ pieces of data per line-item forces horizontal scrolling. To me, horizontal scrolling is the bane of my existence as a designer. I had to do it once before, and it made me feel really uncomfortable.  I was open to redesigning the screen, but at this point, I was still hostile to horizontal scrolling.  I think it’s a huge no-no, and apparently these people agree with me, and these people too, who say “But requiring a large percentage of your site visitors to scroll in two directions to see your content is rude.”

I decided to continue my research into 10-Key user behavior and found a few more helpful tips (from Databasics):

• Don’t force users to scroll (Thank you!)
• Go easy on the fonts (Duh?) and colors.
• Abandon defaults
• Check Your Tab Order
• Be Consistent

The last two are the most important for 10-Key users because they use the keypad to tab through the form, and often, they do not look up at the screen until they are finished - so consistency is very important; they memorize the field order very quickly.

I then found a cached-version of “Web UI Design for Data Entry-Oriented Users“, where the writer created a very relate-able persona (..of sorts) for this type of user.  These users gained “operational efficiencies” in the mainframe, DOS era which the mouse-navigable screens of today cannot afford.  The author points out the following:

• Maximizing the amount of data that can be entered between trips to the server.
• Lean, fast web-side code that serves up light, text-based pages.
• Use of client-side code (e.g. JavaScript) to push as much business logic out to the client and limit round trips to the server as much as possible.
• Get the tab order right for keyboard-based navigation from field to field.
• Take advantage of keyboard shortcut (“accelerator key”) functionality made available by browsers.
• Make efficient use of screen real estate.

My Final Design

I iterated about 4 times on this design before we settled on a design that worked for the client and the user, and one that I could feel proud of (and willing to share here).  My original groupings didn’t work until I realized that the data could be partitioned further into the following:

• Group 1:  Static Data that never changed, and was never compared to data that is entered.
• Group 2: Static Data that never changed, and was compared to data that is entered.
• Group 3: Data that is entered by line-item
• Group 4: Data that is calculated as the difference between Group 2 & Group 3.
• Group 5: Data that is entered, and applies to all line-items

My final Design

This allowed me to partition the page into widgets that were all viewable at the same time, and reduce the number of data that had to be showed on the same line, inline.  While I could make this gain, I still had to cave in to the horizontal scroll.  If you’re going to use horizontal scrolling, make sure you use a fixed header and fixed left column, so that the user always knows where they are in the grid (if they do look up from the document and 10-key pad).  You may not like it as a designer, and you’re developers don’t like it in implementation, but your user will be satisfied.

Looking at the design, the user enters data into the form, and when they select “Finish”, basic information about that form is posted into the upper right widget.  The user can later navigate back to what they entered by selecting the link(s) posted there.  The upper left widget is purely informational, and contains links to related pages in the system.

Final Take-Aways

I found another article, which didn’t add much in substance, but one commenter did say something along the lines of “The reason you cannot find screen shots and examples of good web-based data entry design is because there’s not much out there for anyone to brag about”.  This is the primary reason why I am posting my stripped-down wireframe here.

There are so many advantages to building a web-based application for a new client when it comes to design. You can use more colors and provide better visual cues; if you’re innovative, you can use some jQuery to provide audio cues on form validation too. But, there are serious draw backs in web-based interfaces for data-entry, including designing for multiple browsers, sticking to a particular screen resolution and width (max: 950px now is what I believe the average is), and affording rapid data-entry.

I hope that you have found something here to help you on your journey to conquering this particularly difficult design challenge.

References:

• “Databasics III: Data entry design”
• “Web UI Design for Data Entry-Oriented Users”
• “From Information Visualization to Direct Manipulation using ILOG Discovery” by Thomas Baudel
• My Del.icio.us bookmarks on data entry

Any feedback is always welcome!