Critical Input Error

Is there such thing as degree of incorrectness when it comes to user-supplied data? As in, you forgot your email address...we kinda need that. Is that a critical error? Is it an every day occurrence that we can expect as user interface developers? Perhaps, we need to design into the experience, and into the data ultimately consumed by the software, the fact that we'll get it wrong. Often. But how do you deal with the paradox of missing data? You can only provide so many friendly messages and so much hand-holding before your software languishes due to data starvation.

If the input is critical to the functioning of the software, than not getting it from the user is a critical input error. However, allow me to frame it in a way that doesn't seem so dramatic. I hear something in any technology vernacular prefixed with "critical" and I immediately picture people running chaotic figure-eights, red sirens blaring, infrastructure crumbling, etc. The way I look at critical data is less an action movie sequence and more a modest goal of the software developer. You cannot be greedy with data. You cannot claim that all data you would like to collect from your users is critical and you simply cannot live without it. Well, you can claim that all you like, as a matter of fact. You'll run out of users quickly though. That isn't how users are instructed to use software. They don't have a coach that sits them down and explains to them that a team of good people, most of which had good intentions, decided to build this software for you. All they ask in return is that you give the software the data it needs in the exact format it is expecting. That isn't too much to ask, now is it?

As we're designing input for users, we have to think about this coach. Think of him wearing the hat, the whistle, holding the clipboard. He is pointing out where the user needs to navigate, drop of some information, and from there, where they need to go next. The coach is good because he is efficient. He doesn't bother explaining the trivial things that the user is more than capable of figuring out on their own. Instead, the coach is constantly thinking about what needs to happen next during this session with the software. The coach's job is to get the user to the finish line.

There is no such coach.

Instead, the user is their own coach — guiding themselves through the screens, dropping off the items in the appropriate slots, and moving on. For users to coach themselves, we have to help. We have to, at the very least, provide hints at the critical path. We do not want to stop the user from moving onto the next screen because they didn't offer their middle initial. And besides, what would you rather have your application collect? Potentially everything the user knows about themselves, should they happen to be in a spill-your-guts type of mood? Or ignore, completely, anything that discourages accuracy in the critical path? It's up to you, but when the critical data isn't there, the application is at fault. You're putting it out in the wild, and the outside world is going to function as it will — the application needs to capture what matters.

If only there were a well-proven, well-defined method to go about designing interfaces that capture the appropriate information from it's users. A manual for ensuring that the user is only thinking about the critical data the software actually needs. That doesn't exist, unfortunately, because human behavior isn't predictable. Maybe more so if we were designing for one individual, but I suspect that hardly ever happens and even then would be difficult to get right.

So do we tackle this problem from a constraint point of view — limit what the user can actually give to the software as input. We see this all the time today in the form of combo boxes, or selectors. These widgets allow the user to make a selection from a list. If the item isn't there, then the user is out of luck. But at least the software knows what to expect. Not only do we, the software developers, know that there won't be unexpected surprises in these fields, but the users knows that their choices are limited too. We're presenting the limited input options as a friendly constraint — here you go, pick one. As to how realistically this constraint protects the program from unintended input is questionable if not outright artificial. If you're looking at collecting user input from the critical path perspective, and I would recommend doing so, you can still end up with no input. The constraints these types of selectors impose could in fact be too constraining, frustrating or discouraging the user to a point of turning away. It's because hints and friendly suggestions are missing from the experience.

We could, in theory, design an interface that is nothing but selectors. Every conceivable input is one thing or another, but not another. Just imagine, there is a finite set of possible input values across the entire system, no matter how many users are thrown at it. The problem I see here is that for any given domain, this isn't what we're after. This doesn't accurately capture what the user wants to do, or what information they're trying to provide, but simply cannot do so. The better alternative, assuming such a thing were feasible, would be to allow the user to specify what they're trying to give us. That doesn't imply that we need to act on it, but it does give the user a sense of attentiveness. We could try to figure out what they're trying to tell us, and we have to do that anyway, even with fixed ranges of input values. There is no such thing as misinterpreting what the user meant, right?

Let's accept the fact that our software often doesn't know, nor do we the developers at design time, understand how the user perceives our interface, and what information we're actually prompting for. We should lift unnecessary constraints, at least from the presentation level, and ask the user if that's really what they'd like to do. I like it when programs ask me questions about my input.