> > I'm working on project that I think is somewhat unique, and > unfortunately, I can only describe it in very general terms. > > It's a data entry system for items that contain rather large amounts of > data. There are about 20 categories of data associated with each item. > Each category will contain roughly 5 to 10 pieces of actual information > (numbers, dates, short strings, etc), and many of the categories will > be used several times for each item. So the user will end up entering > several hundred values for each item. These values, by the way are not > simply being copied from somewhere else, they must be interpreted from > other sources and will actually require a bit of thought. > > Users are probably going to be entering a fairly small number of items, > maybe 10 to 50, and then possibly not use the product again for several > months, or possibly over a year. So, the emphasis here will be on > creating an easily learnable system rather than one that's necessarily > easy for experts to use, because we don't really expect anybody to > become an expert. > > The quick summary would be: a system for inputting massive amounts of > non-obvious data that will be used heavily for a couple days at a time > and then ignored for months or years. > > Does anybody know of any examples of similar systems or any sort of > design guidelines that might be applicable?
- large volumes of information
- each user only enters a small number of items
- user has to think carefully about each item
- infrequent use, so learnability is crucial
It sounds very similar to a tax return to me, a topic dear to my heart (and
which I've worked on in great detail).
It's not easy and you'll need to do lots of usability testing, but I guess
you knew that already.
Here are some things that may help you.
- It's likely that the data items are not created equally. Some are likely
to be (relatively) common, some less so, some very rare. You can tailor the
guidance accordingly, using a layered approach so that common items are
explained right there on the form, less common ones in a second level of
help, and the really rare ones are somewhat hidden away.
- Spend a lot of time working on where the answers come from. Observe users
working out the answers to the questions. That should give you some good
- Consider item-by-item wizards that help them derive the answers for
- look for 'if, then' rules so that you can prompt users to enter things
that are required because they put in other things
- If data gets copied from any type of source item, provide pictures of the
sources showing which box to copy to where. You can also annotate these e.g.
"use this data here but not this here"
- It's possible that some collections of items are similar to previous ones
that have been put in. Consider facilities to say 'copy from another item'
and then edit it.
- Think about patterns and examples. Any chance that some items often occur
together? What about 'show me' help or other hints?
- Make sure that you have great save and resume features. Ensure that users
can jump in and out of any part of the process.
- It seems very unlikely that it will be sufficiently linear to allow a
standard process indicator. Consider using what we've called a 'summary
menu' in our book*
, i.e. an overview page that lets users jump into any page of the data set
and complete as much as they can, then save that page and return to an
updated menu page showing the status of every page.
If you'd like to, contact me offline. I'm happy to sign a non-disclosure and
then provide more specific ideas.