If I told you to look at code in the above photo and tell me what it does, only a few of you could.
If I told you that to do your job, you had to read and understand it, unless you were one of those few, it would likely raise your stress.
But much of the software that businesses put out for internal use is as confusing as the code above. Why do we in IT department do that to our fellow employees?
Point-of-Need (PON) help is an idea that can help without redesigning a total new user interface.
Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.
Organizations will put much more effort into making customer facing software more usable but won’t put much effort for all the employees that use internal software.
There are sometimes good reasons. Purchased software typically has lousy help systems. Employees are using the software all day, every day, and they learn the quirks and it doesn’t slow them down anymore. We don’t have the time or money to put better help in place. Well, maybe they aren’t good reasons — let’s call them understandable.
Help Systems (including online documentation) can be useful for training, but they are not very good for that moment when the user goes “Huh?” or “Now what?”. They are also not helpful for the systems that employees only occasionally use. And very few keep training materials handy for more than a few days, putting them up on a shelf or casting them into the electronic sea on their computer.
Sometimes there is help in the applications but even those have problems. Help for a pull-down status field might say “Select the status.” Factually correct and completely useless. Or they jump to the larger help system instead of display the small needed snippet of information. Worse, they just open the documentation and give the user a search box.
In-house developed software, however, can be different. Implementing a PON system can be easy to implement across all your apps. A small API library or web service that uses a unique identifier to pull a snippet of HTML from a database, along with a simple app to maintain those two fields, is all you need.
It is the content of the help database that is important. Thinking back to the status pull-down mentioned above, a simple display telling the employee what the valid statuses are and, more importantly, what each of the statuses mean, and when to use them, will be more, would be more, um, helpful.
The key is to explain the field or screen in the organization’s terms, not software terms.
The problem isn’t (usually) that the employee doesn’t know how to enter the information. The problem is that while entering data or trying to retrieve data, the meaning of the data in the fields isn’t clear. By putting business explanations into the help system and making them available at the moment the user is confused (their point of need), you can make a help system that is truly useful. It is helpful for new employees and for employees that use the software occasionally.
No solution is perfect, and this one is no different. If you don’t keep the field help up to date, you can provide incorrect help which can be worse that no help in some cases. To reduce this risk, only add it to fields that require deeper knowledge. Not every field needs a full description.
Point-of-Need help can be a useful method to reduce errors and confusion in your internal applications. Give it some thought…
Photo from Pexel