3

We have a legacy system with some reports that are old and badly implemented (both from code & UX perspective). There are some newer reports that gives user very similar info, but it's not an exact replacement. There's layout changes, the way info is accessed is different.

We now want to phase out the older reports. Should we notify users ahead of time that we will be removing the reports? Say by putting in little "retiring" flags (like "new" flags) next to the report name with tooltip suggestions for trying out the new reports?

This is common enough in development with code libraries informing people of deprecated functions. I'm not sure there's much precedence when it comes to UI/user features. I'm a bit concern of lost aversion in which people complaint about something they've never used in the first place.

Are there any best practices dealing with feature removal?

Thanks in advance!

nightning
  • 8,571
  • 28
  • 48
  • 1
    Users hate to lose a feature and are slow to adapt. Users are not going to get the term deprecated. "This report has been replaced by X. This is the final release of the software that will include this report." ? – paparazzo Aug 15 '14 at 21:29

1 Answers1

4

Is there scope to change the older report, bit like what Amazon does with older products, by putting something like "There is a newer version of this report, click here to view it. Please note this report will no longer be available after dd/mm/yy"

The last part of that sentence may not be appropriate if you are keeping the reports available for legacy reasons.

DarrylGodden
  • 6,316
  • 14
  • 35
  • Not directly on the report, but there is dev resources available to tweak the point where you launch the report. Not sure we can be as specific as the exact date because we have a rolling release process, but it's a good suggestion to put in a ball park date range. – nightning Aug 15 '14 at 16:10