When dealing with Insurance based information, we often need to implement the use of Effective Dates on most of our data. There are numerous reasons for this that I won't get into, needless to say that portion of the design cannot be altered.
The problem I often run into, is when I need to create an administrative interface for this data for our business users. Usually at the top of whatever screen they're on, the user selects an effective date. This effective date drives what data is presented to them for editing purposes. (i.e. that data is effective for that time period)
Now whenever the user makes a change, we ask them for the effective date of this change. Then we make a database change depending on what the user did.
If they deleted a record, we actually just mark the record's end date as
the effective date of the change.
If they update a record, we end date the old record, and create a new
record with the new effective date.
If they add a record...well we add a record.
Here are the problems I'm running into with a good UI/User Experience.
The user has to constantly tell us the effective date of a change. This is cumbersome and annoying to the user.
The user cannot see the changes on their screen unless they make the change effective immediately. This is due to the effective date being picked at the top of the screen. In addition, they almost never make a change effective immediately.
Lastly, since we're not actually making the changes they expect, we can't just show them the data in tabular format, because it wouldn't make very much sense to them. They'd think a piece of data is in there once, but they'd see it 25 times because of 25 changes.
I was hoping I could get some feed back for what kind of changes you'd make to a UI in order to help with a problem like this. I'm not sure if it's a problem that people have to deal with often, but in the insurance industry we have to deal with it very often. The technology doesn't matter, Thick Client, Web App, etc.
To be a little clearer.
- The application I'm referring to, is the administrative application that handles the modification of the backend data. The actual application itself, is already in place and running using said back end data.
- When referring to effective dates. When the actual application requests data, it passes in an effective date in order to find out what records are "Effective" that date. There is a corresponding "End Date" which is either null or populated. In a database of 20 tables, probably at least 10 will have effective dates on their records.
- When I say we're not doing what they expect. What I mean is, they say "Delete this record" and we actually end date it. They say "Update this record" and we actually end date it, and create a new one.
- Every entry requires an effective date. If it's a new record, the application still needs to know when it goes into effect, and the reasoning could be simply because that's when the business wants it, or because that's when a certain law goes into effect. There's no way to guess it.
It's true I can simply post confirmation/status messages to the user once an action has been completed, but what I've been trying to do is implement a user interface that makes this process a little smoother, more informative, and more intuitive to the end user. So while they may not know every little detail of what is actually happening on the back end, they'll feel confident that it's doing what they need.