Vocabulary

During the design process, and particularly during brainstorming, I place a unique emphasis on creating and using a detailed and precise vocabulary. I believe that the technical nuance of designing interactive products is so important that a single misconstrued word can derail an entire project. I have seen different members of a client team use common words such as button or dialog for dramatically different things. I recall a client meeting in which 10 highly paid professionals wrangled for two hours over a disagreement that existed only because the various parties knew different definitions for the same words.

If you don't have words to express an idea, it is nearly impossible to communicate it. Certainly it is impossible to analyze and decompose the idea at a level of technical detail sufficient to implement it in C# or Java.

When the words are fuzzy, the programmers reflexively retreat to the most precise method of articulation available: source code. Although there is nothing more precise than code, there is also nothing more permanent or resistant to change. So the situation frequently crops up in which nomenclature confusion drives programmers to begin coding prematurely, and that code becomes the de facto design, regardless of its appropriateness or correctness.

When there are insufficient or imprecisely defined terms, people's thinking grows more conservative. Without a robust and precise set of terms, new ideas can't be defended well, so they are discarded prematurely.

The terms we select are not those that will be plastered on the outside of the box. We use our vocabulary internally, so we don't care about the marketing palatability of the words. They need only to be precise. Later on, the marketing department will come up with appropriate words that can be used on the buying public. The Logitech ScanBank, for example, was originally called the "shuffler," which was perfectly adequate for us to use in the design process and was never intended for public consumption.

During one project, our own design staff was deadlocked on a problem. As we argued back and forth, it became evident that some of us were using terms differently from others. Our discussion lacked effectiveness because we didn't have a common vocabulary. I insisted that we break down the components of our design into their atomic pieces which we could all agree upon and assign them completely new, unrelated names. For no particular reason, I chose the names of Alaskan mountain ranges. We named the four primary chunks of the product St. Elias, Brooks, Alaska, and Wrangell. We all had a good laugh at the incongruity of our new terms, but then we proceeded to achieve instant consensus and move our design process forward very quickly.

Breaking Through with Language

Primarily, using a robust vocabulary makes our communications more effective. However, developing a strong nomenclature sometimes has another very important use. Occasionally we find that certain terms have become ossified in a client team's culture. A phrase like Microsoft's "Embrace the Internet" is a good example. It can attain an almost religious significance and be treated with a kind of awe. This awe leads to an inability to deconstruct its meaning and reexamine it in light of new design imperatives. Does it mean embrace browsers, or HTML, or just TCP/IP? The sacred words are the fence around the shrine. It doesn't further our design effort much if we trample our client's sacred beliefs in the process. So we break processes, tasks, and software down into well-defined, discrete chunks and assign them new names that are utterly nonmnemonic. These new names are also typically humorous, too, and the levity helps to break through everyone's serious mien.