Poor Prediction of Customer Needs

In designing customer experience - perhaps in the discipline of design itself - a careful balance must be struck between making no assumptions about the needs or interests of users and leaving them to fend for themselves and being to excessive in the same assumptions and creating an experience (or product, or ought) that prevents a user from serving needs that were excluded by the designer's assumptions.

While much can be said about the former choice, of providing an inadequate level of service by failing to design to the needs of the user, my sense is that the latter is of greater concern in the current environment. The very notion of "service" is designing things in a way to be as useful as possible, and the consequence has been to make things so useful to a single and narrowly-defined set to needs as to be useless to anyone else ... and sometimes, in and of itself.

Take the example of "spelling correction" in word processing software - though it would be more accurate to call it "typing correction" as the majority of errors it seeks to address are not the result of a person not knowing how to spell a word, but of their mistyping a word they know how to spell and would likely not have munged if they had written the same passage longhand.

The first generation of word-processing software offered no help at all. It merely accepted keyboard input and appended it to a file, leaving the user to catch and correct their own typographical errors. It was better than a typewriter, in that the user could correct a mistake without having to re-type an entire page (at the risk of making other errors), but not very useful in identifying those errors in the first place.

A late generation of word processing added spell check: it would compare the words that the user typed to words in a dictionary and any word that was not stored in the "spelling" database. This was a great value to people with poor typing skills because it saved then the effort (mostly) of having to pore over a document to identify and correct typographical errors, and it did so with a high level of accuracy.

Shortly thereafter, the spelling checker began to make suggestions as to what word the user might have meant to type, to save them the trouble of going to a dictionary to find the correct spelling. And at this point, things started to go awry: the user who had typed "insufcent" for "insufficient" would get a list of words that included things such as innocent, infect, or infant. This was mildly amusing, but not entirely obstructive because the user generally knew what word he meant to type and could simply re-type it even if all the options were wrong.

Where designers went a bridge too far was in "upgrading:" the spelling checker to do this automatically. To the extent that the spell-check made accurate choices, it was a good idea. But because of the extent to which it makes bad choices, it is more of a help than a hindrance because it makes assumptions about the user's intentions and makes a correction without calling attention to what has been changed. Thus a user who far fingers the "f" and "g" keys might find that "fgive" is changed to "give' or "five" incorrectly, and without any visual signal that the change was made.

It gets worse in the mobile channel, where the mistakes made by "auto-correct" are further confounded by an "auto-complete" function that decides what word the user meant to type after only a few characters, and ignores any other keystrokes until the spacebar is tapped, preventing the user from typing what they had intended in the first place - to amusing and embarrassing effect.

Doubtless, the automatic correction of errors and completion of words were meant as features that would delight the user and reduce the amount of time that must be spent on re-reading and making corrections to content that has been input ... but it's had exactly the opposite effect. Users are having to go back to re-reading documents to catch the errors made by these "features," and the resulting documents are peppered with errors that the user would not have made on their own.

Naturally, designers and software developers are of their decisions - and rather than admit that these features were poorly conceived, they seem to be working toward improving the implementation: if it were more accurate (i.e., less bad), users wouldn't complain so much about it. Meanwhile, questions of "how do I disable" gets a lot of attention in help forums.

The solution to the problem, however, is a digression from the point: that user experiences can be over-designed, to the point that they become destructive of the values they proposed to deliver. While there is no easy solution that ill work in every case, it is at the very least a question that should be considered in the design process, and particularly in usability testing. In addition to determining whether the user can muddle through an experience, pay attention to the features they do not use, and the features that seem to frustrate rather than assist their behavior.