Field of Science

How to Write a Key

My current job primarily involves insect identifications with any type of insect (or arachnid or terrestrial mollusc) potentially requiring an ID. Because I am not intimately familiar with every single insect species found in Australia (terribly remiss of me, I know), this means that I find myself using a lot of identification keys. The construction of an identification key can be a somewhat underrated part of the taxonomic process; a key often gets tacked on to a review without much apparent concern, but the key has the potential to be the most regularly used section of the review. Also, the skills involved in constructing a good key may not be the same as those in constructing a good taxonomy and an excellent taxonomist will not always be an excellent key-writer. As a result, the available keys out there can vary from the impressive to the appalling. So, with the typical hubris of any snotty customer, I offer a few guidelines for the construction of a successful key*. Some of these rules may clash on occasion and a little discretion may be required about whether you should follow them (except for Rule 1 which should never be broken).

*These guidelines apply primarily to the writing of a linear key where the user is guided through a series of alternatives in a predetermined order. These days, an increasing number of computer-based non-linear keys are available, such as those constructed using LUCID, where the user can choose in which order they want to look at characters. Both linear and non-linear keys have their advantages and disadvantages: a non-linear key is less likely to leave the user stranded at a single indeterminable couplet but a linear key can sometimes offer more guidance as to which characters the user needs to look at.

Rule 1: A key has one purpose, and one purpose only. That purpose, of course, being to provide an identification. A key is not a classification and the characters that are useful in determining taxonomy are not necessarily the characters that you should be emphasising in a key. For instance, your insect classification may be heavily influenced by characters of the genitalia but that doesn't mean that you should be requiring users to dissect out genitalia right from the first couplet (especially if said genitalia are only found in adult males). Conversely, a note to users: just because two species sit next to each other in a key doesn't necessarily mean that they're closely related.

Rule 2: Don't assume that your users know the organism being identified as well as you do. Indeed, the fact that they need to work through a key in the first place suggests that they probably don't. This is one of the trickiest rules to follow because you tend to forget that you didn't always know everything you know now; sometimes, it seems that the more qualified someone is to write a key, the worse is the key that they end up producing. Try to avoid jargon, and be especially careful if the group you're working on has any conventions in the use of terms that differ from their 'common-sense' meanings. For instance, one key I've used regularly distinguishes fulgoroids (a group of leafhoppers) from other Auchenorrhyncha (cicadas and leafhoppers) by whether the antennae are 'in front of' or 'below' the eyes; however, this refers to their position relative to the rest of the insect's face which is not straight up and down but may be angled backwards at up to 45°. So to anyone who doesn't know this convention (e.g. me, when I first started using the key), an antenna can easily appear 'below' the eye when it is really 'in front of' it.

Rule 3: First, eliminate the obvious... If only one of the species you're providing a key for has a bright blue head when the rest are unicolor, or only one species has a large horn when the others are unarmed, then split off that species first. Don't make the user work through twenty couplets of more difficult characters when they could have spotted the ID straight off bat.

Rule 4:...but make sure the 'obvious' is actually obvious. How a specimen has been collected and preserved may affect how it appears. Colours may be bleached, soft body parts may have their shapes distorted. So try to choose characters that are as resistent to distortion as possible.

Rule 5: Start on the outside and work your way in. Again, try to start with characters the user can find easily with a minimum of specimen manipulation. Don't make them cut anything open unless they really have to.

Rule 6: Start at the middle and work your way out. This mainly applies to arthropods, but I'm sure that other organisms have analogous situations. Insect and arachnid specimens regularly lose legs, antennae, etc. Using characters on the main body when possible reduces the risk that the user may not be able to identify the required character state.

Rule 7: Offer alternatives where possible. Another way to get around the above issue is to suggest informative characters elsewhere on the organism. 'Hind tibia spinose; antennae branched' means that if the specimen's tibiae are missing, the user may still be able to antennae.

Rule 8: Illustrations are good. The best way to explain to the user just what you mean by 'spinose' or 'well-developed' is to show them.

Rule 9: Define relative characters when possible. Remember Rule 2? If you want to separate taxa depending on whether a feature is 'small' or 'large', then say exactly what you'd regard as 'small'. Something that a mite worker regards as 'large' might not seem large to someone used to working on butterflies. On the other hand, rather than using direct measurements (which can be difficult to judge, especially with small organisms), try using comparative measures - 'wings shorter than legs', for instance.

Rule 10: Don't require multiple specimens. I've had a couple of occasions when a key asks me something like whether the male has larger eyes than the female. Not very useful when I don't have both. Especially when I don't know the animal in question well enough to tell which is the female and which is the male.

Rule 34: Individual breast larger than head... Lolo Ferrari.
Individual breast smaller than head... 2.


  1. just because two species sit next to each other in a key doesn't necessarily mean that they're closely related

    This should be a required introductory note to each and every identification key ever published.

    Rule 4:...but make sure the 'obvious' is actually obvious. How a specimen has been collected and preserved may affect how it appears. Colours may be bleached, soft body parts may have their shapes distorted. So try to choose characters that are as resistent to distortion as possible.

    And, in the case of birds (and certain other organisms), choose characters that are observable even from a distance.

    Lola Ferrari.

    I LOL-ed at this! Wasn't she called Lolo, though? That's what Wikipedia says anyway. (Wikipedia also says that she was 'encouraged by her husband'. Wasn't she lucky to have a supportive spouse?)

  2. Correction noted; I'd just written the name from memory (that I have the name of Lolo Ferrari sitting in my memory signifies nothing whatsoever).

  3. Rule 11. Keep in mind, that some users of Your key may have far worse optical equipment, than yours. Especially important with beetles - details of microsculpture and some other features are visible only with good microscope and light source.

  4. Good notes! I'll pocket this post away should I teach intro zoology again.

    When I made a key for vent shrimp (, I had multiple use it and work through it. In fact, reviewers commented on the key more than the actual article! Which made it even better and more useful.

    So maybe rule #12 in key construction is to test it out with your peers before going live.

  5. ha, yes. Had real problems with the key to alpheid shrimps back when I was doing volunteer work with the Ningaloo survey specimens. The authors knew what the hell they were talking about, but it didn't help a beginner at all...

  6. There is an Annual Review of Entomology (2007 - 52: 193-208) with a table (Table 2, p. 199) suggesting some 'best practices' in key writing. One of the few that you don't cover (but that Kevin's comment suggests) is their last one: "Beta-test your key with naıve users before publishing." I think this is one of the most important rules - and the best way to discover flaws in the key.

    Still, even when you do your best, it is hard to avoid Lobanov's law:

    "Keys are compiled by those who do not need them for those who cannot use them"

  7. It is called Lobanov's Law now? Does anybody know where it did originate?

  8. My apologies for the late reply to comments - for some reason, my home computer (or internet connection, one of the two) chucks a sad whenever I try to go to the Blogger commenting page.

    Kevin and Dave - that's a very good point about having the key tested, and I'd especially second the point that your tester(s) should preferably be someone(s) who doesn't work on the key's subject (remember Rule 2!)

    Marek - I recently discovered exactly this point when attempting to identify thrips (on the up side, it's giving us an excuse to order a new microscope). As a corollary to that point, I'd also suggest being careful about presence/absence choices (at least on their own). The key I was using for thrips asked me to see whether certain segments had ctenidia (comb-like structures). As it turned out, what I was identifying as "ctenidia absent" was "ctenidia there; you just can't make them out with your crappy microscope".


Markup Key:
- <b>bold</b> = bold
- <i>italic</i> = italic
- <a href="">FoS</a> = FoS