Understanding User Interaction in Web Development

Web development is one area where understanding user interaction is critical. In order to ensure your audience can perform the necessary tasks it is essential to design an interface that is intuitive, requiring little thinking on the part of the user. Some think that this can be resolved with documentation and training but this is a grave misconception for a couple of reasons:

  • No one reads the documentation until they can’t do something; then they look for the solution in the manual.
  • In order for the training to be effective, the process needs to make sense to the user. The user interface is critical in establishing a process that follows a well thought out intuitive process that requires little thought to complete.

During user acceptance training for the YaleSites D7 upgrade, I was training a group to create basic pages. What we thought would be an easy Drupal out-of-the-box method turned out to be quite cumbersome, even with written instructions and an instructor (me) in the room. It was a major red flag that sent us back to find a solution. Training and documentation can and should support a web application, but it is not the solution. It should be used to support a thoughtful and well planned process that results in an intuitive user interface.  

Has anyone else encountered a similar issue where documentation and training was not enough to make a system user friendly?


Yes, I see it in my own approach.  Our users have discovered what most of us design-types already know (and game designers have known for years) – Guessing is much easier than reading documentation.  Just like a video game – the penalty of an incorrect guess is pretty painless and the overall process is much easier than reading boring how-to instructions. 

I've found in my own experience incorporation of descriptive, human readable error messages, tool tips, and other various tools which bring relevant documentation to the foreground to be more useful to end users. By doing so they are saved the trouble of having to know what they are doing well enough to parse a manual, and gives the benefit of being guided through the interface and business process they are trying to interact with. It still isn't an excuse for an unintuitive user interface, but sometimes the business processes we design for also aren't intuitive, and thus don't lend themselves to being wrangled as simply as an iOS app.

It’s a difficult balancing act because, as you mentioned, people tend to take a “path of least resistance” approach to task completion. Engagement is challenging; if documentation alone isn’t enough, we can schedule training, but if no one shows up to the training, what then? The Classes*v2 team encounters this paradoxical problem with some degree of frequency. Rather than spend more of their own time trying to figure something out, users will often vote with their feet (and their wallet) when a de facto solution doesn’t meet their needs.