I'm not just referring to the misappropriation of the latest and greatest buzzword slang where the web [Version and Build Number here] jargon randomly punctuated with choice Godin'isms spews forth like the worst imaginable case of verbal diahhrea known to the members of the digital realm. At some point we become accustomed to this - we no longer hear it as noisecore, and I dare say, some of us even become tolerant of it. If you are like me, you find it a source of entertainment and develop a game based on it called Jargon Bingo where a straight line in a single sentence takes the pot. Work intercom policies are meant to be violated - interrupting the peace for a blue light special moment to yell bingo with unadulterated glee - well it really can do wonders for staff morale. Trust me.

Now, during projects, I often wish I banked a dollar for each time I was rendered completely dumbfounded when trying to understand what someone meant by that "widget" or " section content" or "call to action button" - all very intuitive, explicit and self explanatory terms that leave nothing to the imagination. So you mean that call to action button - the one that is different from the other 16 call to action buttons within this project. 99% of the time, clarification necessitates sitting in front of a computer screen and cringing as someone graciously rubs their greasy mitts all over my cinema display because when all else fails, its the index finger for the win. "See, that dashboard, right there. " Cut to me, with the WTF expression painted on my face and random uncontrollable ponderings such as why is this person even on my planet running through my head. Ok, so you mean the navigation? Many times, I've had to stop and step outside of the conversation I'm having and wonder to myself - when did I become part of this 3 stooges act, more importantly, which one am I, and why am I allowing it to continue well past its slotted air time?

Adopting a project taxonomy is one of the simplest pro-active ways to avoid hours of frustration caused by miscommunication. Once team members, regardless of discipline and role, utilize a shared vocabulary, interactions become more meaningful and ultimately more productive as more time is spent in communicating the message and less time clarifying its context.

I truly never appreciated the value of a shared vocabulary until a couple of years ago. I was a stranger in a strange land - experiencing some minor version of culture shock when I moved to the dirty south to work at an interactive firm in Atlanta. My first couple of days were spent getting used to the charming southern drawl - I had pretty much no idea what anyone was saying because I was so unaccustomed to the accent and I'm pretty sure I gave off the impression that I was borderline incompetent because I asked for everything in an email. This was a survival tactic because I couldn't understand what was being said or asked of me, and well, I didn't read emails with a southern accent.. During some of the initial meetings, team members kept referring to this thing called a "flash pocket". I figured perhaps it was some inside joke or term - maybe a distant cousin of the hot pocket and immediately, when having to use the phrase did my best voice quavering "hot pocket" inflection. Nope. It really was something and everyone but me knew exactly what they were talking about. This happened with several terms or rather how they were used that equally confused me - "dashboard", "webshow","creamcorn","cdn", etc.. Regardless of whether I agreed with how they were being used to communicate certain aspects, they were being used consistently and by everyone. Its much like that spelling argument - if you misspell it consistently - does it mean its wrong? We spent much more time communicating about the project because we spent less time clarifying what was being talked about. Reduction in the random unsolicited WTF proclamations directly correlates to productivity increase.

Its one thing to have this community lexicon, its another thing to define it and more importantly who constructs that definition. Is it defined by the smug account manager whose primary skill set is that of copy and pasting tomorrow's catch phrase into yesterdays RFP? Is it declared by the project manager - the same person who truly understands the digital space because they subscribe to the TechCrunch RSS feed and occasionally flip through last years Wired while spending quality time in the can negotiating a hostage release? Do we rely on the designer - the one who lacks anything remotely close to organizational prowess because it imposes structure hindering opportunities for creative greatness? Surely I'm not suggesting we leave it to the developer brood with their penchant for camel case unless we want to run the risk of creating a taxonomy that reads like a Gang of Four soliloquy in iambic pentameter of the framework kind.

So who creates it? It could be the responsibility of any of the aforementioned players. I've slowly come to the conclusion that perhaps, the foundation of this utopic shared vocabulary is probably best defined in the strategy phase and is something that infiltrates and is reflected in all respective phases of project production and development. This would mean that naming conventions and file management would ideally reflect the projects taxonomy reducing barrier to entry for the different disciplines.

I've gone to great lengths to perpetuate the idea of a shared vocabulary. Recently while working on a fairly long project, I've take on more of a secondary role to help out - I've been heading up the quality assurance efforts and some basic technical lead responsibilities to lighten the load of others. Some team members were very intimate with the project having participated in its process since its conception. Others, such as myself, were brought on much later in the process, to be the extra hand with less of an understanding and ultimately, investment in the project.

Watching this group communicate, it became apparent - although a project taxonomy existed, it was hardly fully defined, and this missing piece posed a greater problem than just the immediate problem of a team struggling to find efficiencies in communication. The development team would find a way to communicate - they would in fact, create their own project dialect that outside disciplines would not be privy to, and while it would solve the immediate issue, it would in fact, perpetuate a much greater one. I became worried about the build release and qa process. How would feedback, features and issues be communicated if everything was going to be lost in translation? Is a fragmented vocabulary, then, much more dangerous than an incomplete one?

Thus I channeled my inner anal organizational freak - ironic in the fact that I'm not at all organized - I just have this compulsive need to force structure and organization on others particularly in the midst of chaos, in the blind hope that I will be forced follow in step. I created what I now refer to as a taxonomy document and although hindsight suggests that it was beyond late in the game to do something of this nature, it has helped bridge the communication gap across the disciplines and invested parties to ensure that not only are we speaking the same language, we're sharing the same dialect.

A project taxonomy document, in this case, was nothing more than marking up the wireframes / designs with the proposed names for the various components within the project domain. If someone was referencing the Site Manager View , for instance, there was no mistaking the context of the proceeding communication. This document was provided to any invested parties, and for the qa process, it became invaluable as it reduced the number of vague bug entries greatly. Every bug had an immediate and known context - developers were taking less trips to the haystacks and more jaunts to the corner store with a list.

Adopt a project taxonomy - sharing a vocabulary encourages inclusion amongst the team where all members can participate and contribute to the discussion in a meaningful way. Be explicit, not implicit. How do we judge the success of such a practice? Perhaps it can be determined by the severity of the greasy fingerprint film generated on monitors throughout the team.

Read the rest of this series here.