Working In Uncertainty

Controlling Jargon:
New products should not always need new jargon words to describe them.

(First published September 1989 in Software Management, a magazine for ‘DP, MIS, & IT Managers’. Almost certainly this article was my first publication of any kind.)

In most organisations, chances are you'll find that many staff don't fully understand the new system that your department has just installed. This situation leads to confusion and arguments. A major factor in this non-understanding is often because the designers of the new system were unable to control the jargon. The benefits of successfully controlling jargon will be enjoyed daily: better communication with end-users, clearer modelling of the user's business, more reliable statement of requirements, tighter specifications, software that's easier to use, plus more effective user manuals and training. The challenge for software managers is to be aware of jargon, to make others aware of it, and to keep jargon standardised and used only among those who know what it means.

Jargon starts with users. Most businesses have their own specialised vocabulary and users often express their requirements using it, without realising what they're doing. That's a problem for analysts, particularly early in discussions.

As soon as the user or client uses a word that you suspect to be jargon, ask what it means. Don't let conversations drift on, hoping to pick up the jargon as you go along. Make the user aware of the jargon that's being used by taking great care to understand it exactly. Slow down the conversation and aim for total clarity.

As discussions continue, you may have to invent new terminology for new ideas and systems the user is interested in introducing. Whenever a new term is needed, get the users' agreement to use that term during all subsequent discussions.

Designer's jargon

As files and programs are designed, there's usually an explosion of terminology. Here's a selection from a small project I was recently asked to clarify: band, rateband, rateband table, weight band, weight break, weight price, price, tariff, unit price, weight increment, weight band framework, prices file, destination, AOD, POD, special deal, discount percentage, discount level, revenue discount, consignment discount, and SCI.

The system's specification must include careful definitions of all terminology invented. Once again the new jargon should be put into the project glossary and new terms explained and typed in bold when first used.

Everyone in the project team should learn the exact meaning of each term. Anyone who uses a term incorrectly should be corrected. Most importantly, anyone who makes up new terms when there is already jargon for what he or she is trying to say, should be asked to use the established jargon. Anyone who makes up jargon for something that can be said just as easily and precisely in plain English should be asked to use the plain English alternative at all times.

Inconsistent terminology on the screens of programs can be devastating for users. Regardless of mice, colour, WIMPs, and all the rest, if one screen says 'User ID' and another uses 'User Name' but both mean the same thing, users will be baffled and unhappy. All programs, and all parts of a program, should use the same terminology. As far as possible, it should be the terminology of the users. This is one reason why it's useful to adopt users' jargon in your project whenever you can, instead of making up new terms unnecessarily. If the same function is offered in more than one program it should be selected by the same word. This means that menu options should be worked out very carefully to be consistent with the project glossary and with each other.

It is up to the Project Manager to ensure that this is being done; programmers rarely give it enough thought.

Manuals

In manuals and training, a simple rule must be applied rigorously: never use a piece of jargon until you've defined it, unless the reader will know the jargon before reading the manual. This rule applies especially to the contents page. The titles of all sections should only contain jargon that the reader will know before reading. It should be obvious that breaking this rule will cause confusion in the reader's mind, but time and time again the rule is broken in software manuals.

Terminology can be defined using concise, formal statements of meaning, or, on rare occasions, by using it in a context where its meaning is obvious. Simple examples should often be used to reinforce statements of meaning, but never instead of them. The most potent combination is a statement of meaning supported by three examples.

There are some dangerous habits that often send jargon spinning out of control. If you explain something to someone using the standard jargon and they don't understand, the temptation is to say the same thing in different words. That makes you try non-standard jargon. It is better to use exactly the same words, but more slowly, and perhaps using shorter sentences or a simpler example. A useful rule is: if they don't understand, say less, not more. Using computer jargon to impress or intimidate users doesn't work and doesn't help.

The act of making up useful, necessary jargon can get you into the habit of making up terminology. Once in the swing of it you can easily create jargon you don't need. If you add jargon to a project glossary, the effort involved makes you think carefully before accepting a new piece of jargon.

I know of no software that helps software managers control jargon during development projects. However, it would be easy to computerise project glossaries and to write programs to check manuals and training materials for jargon used out of sequence. Help systems could be written that ensure jargon is always introduced in sequence. A preliminary test would establish a set of terms the user already knew. Then each term presented would be chosen so that its definition only used terms in that set or terms previously presented.

Conclusion

Uncontrolled terminology in software development projects is a common problem few people are aware of. The simple steps described above can bring jargon under control and improve every stage of software development. I know of no other approach that offers so many benefits for so little money and effort.

By Matthew Leitch, LBMS plc, Product Marketing Manager

(Article written while working for MF Systems Limited.)

Made in England