Dealing with Effective Dates in an Administrative Application

Question

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.

1. The user has to constantly tell us the effective date of a change. This is cumbersome and annoying to the user.

2. 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.

3. 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.

Edit

To be a little clearer.

1. 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.
2. 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.
3. 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.
4. 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.

Answer 1

Could you create a vertical tab interface, with each tab representing an effective date? Click on a tab to see the data as of that effective date. (Think Apple's Time Machine without the fancy animation.)

To make a change, the user would start with entering an effective date. That would create and select a new tab, a copy of of the one that preceded it, with editable fields. So it's clear what effective date is being edited, and it's also possible to click through the tabs and view the policy at other points in time.

With the model suggested here, a policy would never "end" (though there's still an end date in the DB); it would just be superseded by the next effective date.

Unfortunately that means the policy never ends after the last effective date. You might make the last tab a marker signaling the end of the policy. So instead of "deleting," users would simply change the effective date of the end tab. (You might still have a "delete" button -- it would change the end tab's effective date to today).

Answer 2

It's hard to get around asking the user for an effective date for each change if they have to give a specific effective date for each change. There are some opportunities, though. Do some research into how people are using your software and see if you can figure out some patterns. For example, perhaps users are managing accounts, and accounts are always mutated on the last day of the month. If that's the case, you could stop asking users about specific dates for those mutations and instead just fill it in for them (by choosing a default option, or hiding the control - user test to see what works best). You could also check whether there are periodical dates throughout the year, or each month, on which certain things happen, and perhaps offer those as templates. For instance, "Performance Review Day" or "Last Fridday of every month". Ultimately, you need to identify patterns to see how you can optimise the workflow and reduce input on the user side.

Edit: undeleted and got rid of most of the answer where I didn't know what was going on