Internal Apps: A Different User Paradigm
Client-facing work is a complex beast. The designer must create something that can be understood quickly and will achieve the goals of the site-owner for a broad range of users. For e-commerce, this goal is typically for a potential customer to complete a purchase flow. For various online services, it's to sign up and become engaged in content (and thereby be exposed to advertising).
In this regard internal tools are more like desktop applications than websites. For a good example of this, which most of us should have some cursory familiarity, let's use Adobe Photoshop.
Adobe Photoshop is a complex image processing and creative tool that if you sat an inexperienced user down in front of would cause fear, apprehension, confusion, and perhaps some clicking. If we're lucky we might get the user to play with some of the tools.
However, give an experienced user five minutes with the novice and they'll have at least a basic understanding and could probably start making a visual mess.
Our application's users will need to be trained. We are not trying to make a tool that allows for a rare event to be handled quickly with no handholding. We're trying to improve a workflow for our co-workers or clients which will be repeated hundreds if not thousands of times a day. This requires complexity in the interface that is best handled by training our users.
How do we train?
Training can take many forms with the end users.
The first and most obvious is one-on-one training with co-workers or other, more experienced users. This happens most often without any formal planning or setup. This isn't exactly the best type of training as it typically takes away from a co-worker's time and can be distruptive to their productivity.
The second is discoverability. Discoverability is extensively defined and covered by Scott Berkun in "The Myth of Discoverability" and he makes some great points. Everything can't be discoverable. You create opinionated interfaces that reduce the free movement of the end users. But it's an important tool in the training arsenal.
What we've found to be most effective is to use the previous techniques but to build an extensive online help. Not a traditional, worthless help section that you find in most apps, but effectively a tutorial section of an application. And it's all done with screencasts.
We first rolled this out with our first Ruby on Rails app that we deployed at a small non-profit in DC in 2006. I give credit to my partner Justin Hankins who came up with the concept and created the screencasts. There were small screencasts, 60 - 90 seconds each, that cover a task or two each. Instead of fielding calls for "how do we do this" or "how do we add that" we had users that were able to train new site managers without any additional support. The amount of time that it took to create them was easily saved by us not having to respond to phone calls and emails everytime they spun up a new user.
So what does this all matter?
When we're working on a public facing app, we're dealing with a much shorter opportunity window to go from zero to engaged. We often have to make things easier for early users while simultaneously reducing power-user functionality and ease-of-use. There are some recent examples of interfaces changing as a user becomes more experienced, but these are relatively new and untested.
But our internal tools are power tools. Day in and day out, people will be using them for tasks and the more we can speed up those tasks, the more efficent and effective those people can be come at their jobs. Maybe that efficency gain will be spent with 30 more minutes at the lunch counter, or maybe it will save the company hundreds of thousands of dollars in their call center operations budget, or just maybe, the app you work on will have an impact where seconds mean the difference between someone living and dying.
Don't get locked in the wrong paradigm. Internal or advanced tool design is markedly different from social media or ecommerce. Design to the right user's expectation and make the experience a great one.