If in my project someone buys a membership for 1 month, how long should that "month" be?
Always 30 days, no matter the month of the year (e.g 23/2/2016 => 25/3/2016)
The same day number of the next month (e.g 10/5/2016 => 10/6/2016)
Or another?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this communityIf in my project someone buys a membership for 1 month, how long should that "month" be?
Always 30 days, no matter the month of the year (e.g 23/2/2016 => 25/3/2016)
The same day number of the next month (e.g 10/5/2016 => 10/6/2016)
Or another?
This is really simple: if user is charged on day 5 of the month, he should be charged on day 5 next month. Most users plan in anticipation and they know that every fifth day of the month they will be charged for a service. Otherwise, see what would happen
January 5
February 4
March 5
April 4
May 4
June 3
July 3
August 2
September 1
October 1
**October 31** (2 charges on the same month!!!!??????)
November 30
**December 30 = 1 year**
As you may see, your user was paying the fifth day of each month. 10 months later, he pays at the end even though, in his view, he didn't even reach that month. By the end of December, he has paid for a year even tho a year would be on January 5th.
While this may not be a great deal, for some people it is. You'll be seen as trying to take advantage of a customer, or as too greedy/cheap to do what EVERYBODY ELSE does (let alone the confusion you'll be causing).
In short: if 99.99999999999999% of people is doing it... you can't go wrong
EDIT: Another common alternative to make dates consistent: charge the proportional rate for the remaining of the month, then start charging a full rate at the beginning of the month. This way, users will always know the date is the first day of the month, and companies have less accounting work.
An alternative to this alternative is to have a few dates (or date ranges) for users to choose. This is quite common for banks and financial institutions, allowing clients not to have all charges at the beginning of the month.
But even within these alternatives, there's a common factor: date always stays the same month to month
You don't need to over think this. Unless there are regulatory constraints it can be whatever you want it to be and your users will take it as corporate policy. (By the way is there existing corporate policy relating to the definition of a month in other areas? If so leverage those decisions.)
If you want to be thorough, and have the time and resources, you could chart what your competitors do. You could also run tests on your users. Pick one and then make the wording consistent. for instance "Enjoy your 30 day membership with XYZ Corporation"
According to Dr. Math there are 30.42 days in an average month so you'd be "safe" rounding down to 30. :-) That aside, 30 days seems like a fair and intuitive number to use for most people. From a practical standpoint it's usually easier for a programmer to deal with too. Of course, whoever inserts the data into a datastore would be wise to use a reliable calendar library to take into account leap years and the +- one day difference found from month to month!