In Minimize Data Requirements, I talked a bit about allowing users to save incomplete data because there’s no reason to insist that all data must be provided before any of it is accepted.

While that may be a good negative reason (”there’s no reason not to”), there are also positive reasons for allowing this:

It makes your users’ lives easier.

Are you perfectly organized at all times? I know I’m not.

Requiring that saved data must be complete and valid (or at least valid-looking) at all times demands perfect organization from your users. It makes them collect all of the information you want up front and have it all available at the same time when they enter it. Removing that requirement means that they can enter as much as they know right now, then find the rest and come back later to finish.

It provides a record of user actions which were started, but not completed.

Suppose you have an online store for which users go through a series of three pages in the course of placing an order. Do you persistently store the partial data at each stage of the process or do you just keep it in the active session and write it all to the database at once when the final form is complete?

If you’re smart, you’ll make a permanent record of it at each stage. This information about what items a user started the purchase process for, but didn’t actually buy, can provide valuable insight into buying habits. If you’re using a recommendation engine (”people who bought X also liked Y”), then information about what users almost bought is almost as valuable as information about what they actually bought.

More importantly, though, this incomplete transaction data can highlight issues with your site’s effectiveness. If 90% of your users are starting a transaction, but abandoning it after the second step, then perhaps you should take a hard look at the third step (and, while you’re at it, make sure that the server is completing step two in a timely fashion) to determine why they’re not continuing at that point.

Incomplete or invalid data can show what mistakes your users are making.

Users will make mistakes and they will submit invalid data. That’s as inevitable as death and taxes.

Most software ignores invalid submissions, beyond throwing it back at the user along with an error message.

If yours saves it anyhow, though, then these invalid submissions give you a window into your users’ experience that will show you what mistakes they’re making. Once you know what mistakes are being made, you can attempt to determine the cause of the mistakes and make it easier for the users to get it right the first time instead of just scolding them for doing it wrong.

Like the data I’ve been talking about, I’m sure that this post is also incomplete. What other benefits or drawbacks are there to saving partial or incorrect data instead of rejecting it?

There’s a long-standing tendency for software to enforce completeness and consistency in stored data. It has never truly been necessary in the real world and it has become something of a monster with the rise of the internet as websites seem to be constantly outdoing each other to collect every conceivable piece of information about anything of interest (usually, but not always, their users) and make every item “required”, refusing to accept any data until all data is provided.

This is the wrong approach. As application designers and developers, we should be minimizing the effort we require from our users, not adding to it.

I recently encountered a blog post on Rethinking the Comment Form which, among other things, suggested that there’s no reason for a blog comment form to require - or even request, really - an email address unless the user requests to be notified of additional comments. This is a step in the right direction and provides my first principle for minimizing requirements:

If you will never use the information, don’t request it.

In most cases, that can be expanded slightly to “if you will never use the information for the user’s benefit“. If your only use for the information is to sell it to spammers or “marketing partners”, that doesn’t count.

The second principle expands slightly on the first:

If you won’t use the information immediately, don’t require it.

The first was pretty conventional, at least if you’re not talking to marketers. The second is a bit bigger of a step. It means that, if you’re not going to be sending someone postal mail today, then it’s perfectly OK for them to enter an address with no ZIP code. Or a phone number with no area code.

Yes, yes, I know… “What about data integrity?!?”

Which is a good question. What about data integrity? If you’re not going to use the information yet, then why does it matter? Sure, you definitely do need to get that ZIP code before sending them a letter, but, until you have a letter to send? So what if you don’t have it?

This then leads to:

Even if you do need the information, accept its omission.

Let the user leave it blank. Really. You can remind them each time they log in about important information that needs to be completed, but there is no excuse for refusing to let users enter partial information now and then come back and finish it up later.

The only potential exceptions are a username and either a password or an email address (so you can send them a password). This is sufficient to allow them to return and provide whatever other information may be needed at a later time.

Of course, if you use the email address as their username, then that leaves exactly one piece of required information. You can’t get much more minimal than that.

Do you have any other suggestions for good ways to minimize the load on your users of providing information?