Speak the Language of Your Audience

# The central problem Many technical people start projects focused on the technology rather than the people who will use it. That approach produces brittle solutions, missed assumptions in specs, and miscommunication. The author gives a concrete example: at a polo match, regulars described the game using sport-specific terms that newcomers couldn't follow. If the goal is to bring new people into the sport, the regulars needed to explain the play in words the newcomers would understand.

# Why matching audience language matters

The author draws on decades of varied work—Drupal sites, Salesforce consulting, nonprofit energy systems—to show the same pattern repeats across tools and domains: systems work better when builders adopt the users' terms and mental models.

# Examples of failures to understand

• On Salesforce projects, building a Flow without knowing what users expect to happen wastes effort. Page layout decisions require knowing which fields users consider most important and how they group related information.
• At the polo match, failure to explain what was happening led to confusion when a horse was injured and no one explained the situation until emergency help arrived.

# A note on ethics The author treats ethical consequences as a professional responsibility. Designing or building tools without regard to how they will be used can enable harmful outcomes. Saying "I don't care how it's used" is, the author argues, an implicit acceptance of whatever outcomes follow. Ethics is a large subject, but basic care about who benefits and who might be harmed belongs in everyday decisions about product and system design.

# When do you know enough?

# Practical cues and next steps for builders

• Start conversations by asking users to describe their work in their own words. Record the terms they use and prefer.
• Ask "why" about visible choices in designs or processes to capture intent, not to challenge style.
• Use user terminology in labels, API names, and data models so future editors and users can find the right items.
• Before automating a workflow, validate the expected outcomes with users and observe an actual run if possible.
• Keep a running document of domain terms and their plain meanings to onboard teammates and reduce rework.

If you adopt the habit of meeting your audience where they are—linguistically and operationally—you reduce friction, reveal hidden requirements, and build systems that actually support real work.