Design Article
Understanding user interface design rules - Part 2: System vocabulary and risk
3/28/2011 12:25 PM EDT
Finally, WordPress.com provides an example of the same term for different concepts - also called overloading a term. For administering a blog, WordPress provides each blogger with a Dashboard consisting of monitoring and administrative functions organized into several pages.
The problem is that one of the administrative function pages in the Dashboard is also called the "Dashboard," so the same name refers to both the whole Dashboard and one page of it (see Fig. 11.12). Therefore, when new bloggers are learning to use WordPress, they have to discover and remember that sometimes "Dashboard" means the entire administrative area and sometimes it means the Dashboard page of the administrative area.

Developing task-focused, familiar, consistent terminology is easier with a good conceptual model
The good news is that when you perform a task analysis and develop a task-focused conceptual model, you also get the vocabulary your target user population uses to talk about the tasks. You don't have to make up new terms for the user-visible concepts in your application - you can use the terms that people who do the task already use. In fact, you shouldn't assign new names for those concepts, because any names you assign will likely be computer technology concepts, foreign to the task domain.1
From the conceptual model, a software development team should create a product lexicon. The lexicon gives a name and definition for each object, action, and attribute that the product - including its documentation - exposes to users. The lexicon should map terms onto concepts 1:1. It should not assign multiple terms to a single concept, or a single term to multiple concepts.
Terms in the lexicon should come from the software's supported tasks, not its implementation. Terms should fit well into the users' normal task vocabulary, even if they are new. Typically, technical writers, user interface designers, developers, managers, and users all help create the lexicon.
Certain concepts in GUIs have industry-standard names. These are the GUI equivalents of "reserved words" in programming languages. If you rename such concepts or assign new meanings to the standard names, you will confuse users.
Follow the product lexicon consistently throughout the software, user manuals, and marketing literature. Treat it as a living document: As the product evolves, the lexicon changes based on the basis of new design insights, changes in functionality, usability test results, and market feedback.
Footnote:
1 Unless you are designing software development tools.

