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.


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.

  • 1
    I think it would help if you added some mockups or storyboards to show us what the user is seeing. This description (even after editing) is very generic and abstract. :)
    – Rahul
    Sep 1, 2010 at 19:47

2 Answers 2


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

  • Great idea! But that only solves one of the effective dates... what about when a change should take effect? Or am I confused?
    – Rahul
    Sep 1, 2010 at 19:56
  • Deleted my post and +1 this one. Mine was a horrible confusing mess. Yours actually suggests something useful!
    – Rahul
    Sep 1, 2010 at 20:09
  • I only understand there to be one type of "effective date." Say there are three tabs marked [Sep 1, 2010] and [Jan 1, 2011], and [Jul 1, 2011]*. The first would be effective from today through the end of the year. The second tab would be effective the first half of next year. The third tab would be the end tab. Maybe it would be a different color, and when selected, have a statement like "This policy ends effective July 1, 2011." Sep 1, 2010 at 20:15
  • Thanks @Rahul! You had some good ideas too. Certainly, the part about easing the burden of entering dates deserves to be resurrected. Sep 1, 2010 at 20:23
  • 2
    @Patrick Wow... That concept is fantastic. I've seen a lot of different ways to approach this problem, and that has got to be by far the most out of the box solution I've seen. With the right notifications against that vertical strip of dates, the user experience would be great! I think I'm going to do a prototype of it tomorrow. Sep 1, 2010 at 21:42

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

  • Added additional info to my question to hopefully address some of your points. Let me know if I've explained it enough. I'm working on one application right now specifically, so I can be more specific. This problem exists throughout the enterprise though, so I was being generic intentionally. Sep 1, 2010 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.