Back in the 1980’s my beloved colleagues and mentors at Indiana University got me involved in a little project that is still going strong and finding a lot of value: The IU Technology Services “Standard Terms List” (insider nod: The use of “STL” is an acceptable acronym variation).

It was during those formative years before the web, that IU’s University Computing Services Publications Group was charged with reporting on and enticing students toward usage of the fledgling realm of personal computing. We were a young department of five persons responsible for writing technical documents, marketing pieces, instructional manuals, and newsletters on every aspect of campus-wide computing.

There was a lot of exciting writing and reporting to be done during those early years, and we quickly learned to enlist experts from across the campus to help us create a buzz.

Consistency and audience tone was key. So how could we make certain our guest writers and lecturers were speaking the same voice when even The Chicago Manual of Style wasn’t ready to offer advise on best practices for such an emerging and quickly expanding area of terminology?

Enter the Standard Terms List. As “keepers of the word,” the Ms. Thistlebottoms and I would refer to this running index as a way to illustrate proper text usage. The original document started with less than 50 key terms and their preferred (and un-preferred) usages. Eventually this index grew into a tool of 1000+ items that is used daily by writers, editors, campus Web managers and support teams across eight campuses.

Taking the success of this document on the road, I’ve found its format a welcome and differentiating deliverable for many large clients including Blue Cross Blue Shield Association, Emory University, and SunTrust Bank.

In addition to providing support to my clients’ marketing and editorial teams, this document format proves a valuable tool for:

• QA Teams
• SEO/SEM Tools
• Taxonomies
• Metadata
• and, of course, Knowledge Management and data warehouse teams.

Check out the Indiana University Technology Services “STL”.

I find it fascinating that there’s so little information available out there on the value of taxonomy as a founding principle in Web design strategy.

Taxonomy - the study of the general principles of scientific classification - has been around for hundreds of years. In Web work, it’s generally the organization of contexts into logical groupings and hierarchies.

It’s those groupings that, in turn, help IAs determine navigation structures, metadata, even the very nomenclatures that are the foundation of Web usability best practices.

If you’ve ever been approached to help a client correct a truly horrific Web site, you’ve no doubt found that some (possibly much) of their pain points can be traced back to a poorly designed – or altogether missing – taxonomy.

Maybe it’s that those of us who build Web strategies have just come to see taxonomy as a “given” within the Information Architect’s toolset — something IAs employ but needn’t share with the rest of the creative team or [forbid!] the client.

Maybe people think taxonomy is just an issue for larger, content rich KM sites.

Maybe I’m not finding a lot out there because whoever is writing tomes on taxonomy best practices just isn’t remembering to add metadata to their articles.

Ok. That was a cheap shot. But where IS the supporting data in Taxonomy’s defense? I’m disappointed by just how little taxonomy information is out there on the Web. Do a search on your own and you’ll see examples for “Taxonomy best-practices” and rationales are few and far between.

As a creative body, IAs all too often struggle with clients who “just want to see the comps.” Client’s don’t realize how much of their bottom line rides on the contextual storylines inherent in the usability of the site.

The process of taxonomy creation is really much easier and effective than the name might imply. Yet, I’m amazed at how few IAs are given [or is it take?] the time to apply it. And I’ve [almost] never seen nor heard of a client demand a content outline as a deliverable.

I recall a previous colleague who was asked to design wireframes as the initial deliverable for a large eCommerce client. He produced very innovative wires complete with auxiliary navigations, functional buttons, web 2.0 components… the whole nine yards. The client was delighted with the results. After all, they were the pre-cursors to some beautiful graphics.

The site, however, was completely useless. By not first establishing a contextual format for the linear plots and subplots of the user experience, the navigation “buckets” we’re little more than a sloppy hodgepodge of disparate functions and features. The site’s organization lacked cohesion and the end users simply couldn’t build a mental storyline around its intended purpose.

That’s why, whether creating a new site or performing an audit on an existing one, I find reviewing the site’s taxonomics an invaluable starting point.

I begin with a literary outline based on the site’s overarching goals. Sound too old school for today’s hyper-connected world? You’d be amazed at how much mileage you can get by FIRST establishing the value of those straight pathways. It helps the client visualize those important “subplots” that will eventually become the site’s use cases. It also points out where there are potential holes or disparages in the client’s existing content sets and expectations. It also grounds them in reality that these areas of the site will need to be created AND maintained by someone in order to be successful.

More important, we’re helping rationalize and strengthen their business requirements – an important pre-visual practice before going to the expense of designing (and redesigning) wireframes or comps.

After all, isn’t the role of a good taxonomy advisor to SAVE the client some money?