One of the keys to designing an effective information system is defining the concepts people must understand to use the system. What are its key components? How do they relate to each other? How do they differ? What should we call them?

This last question is especially important. The words we use to label system elements affect how people understand them and the system as a whole. Terms people are familiar with can make the system more learnable. However, familiar terms may also raise undesirable expectations.

Proposing “good” language requires that we understand both the system and the people who need to use it. How do these people see the conceptual domain? Do they already have words or phrases to describe comparable features or functionality? Are any of these terms ambiguous or otherwise misleading?

Answering these questions is why we do research. Concept maps are useful artifacts in these early research stages of projects. Although these maps are abstract (and therefore potentially confusing), they can elicit feedback on whether we’re creating useful distinctions and labeling them with understandable terms. What I’m describing so far shouldn’t surprise anyone familiar with information architecture. That said, the system’s end users aren’t the only people who will help inform its architecture. Product owners, executives, subject matter experts, and other key stakeholders must also understand and provide feedback on our proposed models. These people have words of their own to describe system components and processes.

Some organizations are more prone to jargon than others. Still, they all develop specialized language to talk about what they’re doing. Often, this internal language isn’t fit for public consumption; it will likely be meaningless to people outside the organization. Conversely, labeling proposed system components using only external terms may confuse internal stakeholders, making it more difficult for them to give feedback.

The answer to this dilemma lies in creating artifacts that bridge the two domains. We can label internal and external language in the model: “This is what we call this feature, and that is how we propose to label it for end-users.” Offering bridges between the internal and external language greatly improves the quality and timeliness of stakeholder feedback.

Bridging internal and external language can be tricky when we’re proposing structures that introduce radical new distinctions, since the organization may not have internal terms to describe the new configuration. But in my experience, this is the exception rather than the norm. Acknowledging the lack of internal language raises the level of visibility of these exceptions.

As I’ve written about before, effective designers aren’t only concerned with the needs of system users. We must understand all the forces that shape the goals and structures of the systems we design. This requires that we speak the language of internal stakeholders and that we convey the relationship between these internal terms and the external terms people will use to interact with the systems we design.