Naming
The names we give our products and features ideally teach physicians how to use Commure and how to find the things they need to run their practice.
Thoughtful naming
Names influence how physicians and other audiences perceive and understand Commure. A well-chosen name will:
- Put clarity above creativity
- Help establish a mental model for our audiences
- Enhance people’s perception of our brand
- Increase adoption of the product or feature
- Differentiate Commure from other products
- Clarify where a product or feature fits into our brand system
The naming process involves collaboration. Include different disciplines and people with different subject matter expertise in the creation of a name.
Does it need a branded name?
Most features don’t need an official, branded name. For example, encounter entry is a feature that’s referred to descriptively and so doesn’t need to be capitalized. When choosing what to call a feature, pick words that describe what the feature does or represents. If there’s room, add extra context for physicians by describing the feature instead of using only the feature name.
Avoid capitalizing descriptive feature names.
If there‘s room, describe the feature instead of defaulting to only using the name.
Using “Commure”
Only Commure can use the word “Commure” in a name. The word “Commure” can’t be used to name third-party products.
It’s important we use the word “Commure” consistently, and sparingly. Don’t use “Commure” in a name unless there’s a lack of surrounding context and we want its target audience to know it’s associated with Commure.
Adding “Commure” doesn’t add clarity in the context of other Commure products and features. For example, most physicians using Listrunner will know it by name but will not recognize Commure. Our support staff often provide a brief explanation when referring to Commure. Use “Commure” in front of a name when a product:
- Is or will become a separate product or platform and we need to associate it with Commure
- Should be differentiated from other, similar products in the industry
- Doesn’t justify an evocative name, but still needs to associated with Commure
Don’t use “Commure” in a name for built in functionality features, like user management or importing patients.
Commure makes apps that physicians can add to their Commure admin. It’s okay to say “Built by Commure” or “Made by Commure” after the app name. Once you’ve picked the format that works for the design, use it consistently.
Apps that aren’t built by Commure should not use the word “Commure” in their name or say “for Commure” after the name.
Using "FHIR"
FHIR is an acronym for Fast Healthcare Interoperability Resources. For more information on FHIR, check out their website.
When a feature is part of FHIR specification or extends it, it should be reflected in the name. Examples: FHIR Path, FHIR Resource.
For products that are FHIR native, it is not necessary to include it in the name.
Using "SMART"
SMART is an acronym for Substitutable Medical Applications, Reusable Technologies. For more information on SMART, check out their website.
Any feature that is built using the SMART framework should be named using the SMART-(feature) name format (note the dash). Examples: SMART-react, SMART-core.
Descriptive vs evocative names
There are two types of approaches to naming, the descriptive approach, or the evocative approach.
Descriptive names are concrete, while evocative can be more abstract. Descriptive names are provider-friendly, and the most common. Features should always have descriptive names.
Standalone products that require independent branding can use evocative names. Third-party apps and channels should have their own branded names and should never use the word “Commure” in the name.
If you’re a Commure employee and are looking to trademark an evocative name, ask the legal department for help.
Descriptive names
Features and products connected to Commure’s main product offering should have names that reveal something about their purpose. Avoid jargon and make sure the name you pick won’t get confused with similar names or terms.
Reserve evocative naming conventions for standalone products.
Descriptive names should:
- Describe the experiences they represent
- Fit into the information architecture of the product
- Use physician-friendly terms, not industry standard terms
- Make sense in marketing materials
- Align with brand guidelines
If it’s a default feature (as in physicians don’t have to sign up or opt in to use it), don’t capitalize it.
Avoid jargon and give physicians a hint about the actions they’ll be able to take when they interact with the product or feature.
Evocative names
Standalone applications use evocative names to position us in the industry. These unique and bold naming conventions can help with branding or recall, but don’t always help people understand the experience. They’re better for standalone products, and not for experiences that are part of Commure’s main product offering.
Sometimes Commure acquires a product or service that already has a unique, branded name. Even though it may become more tied to Commure, it can keep its name to maintain its brand identity. This also helps maintain the context audiences already have about the product.
Certain standalone names use the word “Commure” because it differentiates the product from similar ones in the industry, like Commure Notes in comparison to Google Notes, or Apple Notes. For more details, see the guidelines for using “Commure” in a name.
Evocative names should:
- Have a strong, independent brand identity
- Help with branding or recall
- Reflect the concept it represents
- Make sense when used in marketing materials
Some evocative names can be more descriptive, although they’re harder to trademark if they use common terminology. Not all evocative names need to be trademarked.
If you’re creating an application for an existing brand, maintain its brand identity and keep “Commure” out of the name.
Commure products and features
An off-brand and unclear name can confuse your audience. It can also feel disconnected from the rest of Commure.
A good product or feature name should:
- Help physicians understand what the experience represents
- Fit into the information architecture of the product or application in which it belongs
- Make sense when compared to other products, features, websites, or events in the same market
- Avoid any negative or weird connotations
Referring to Commure and areas in the documentation
Use consistent and easy to understand descriptions when referring to locations in product, especially in help documentation. Descriptive feature names aren’t capitalized, but when providing steps in a workflow, it’s okay to capitalize the page name, for example, “Go to the Patient page”. Note that the page name is capitalized, but “page” isn’t.
When referring to Commure’s main product offering, use “Commure”. The only exception is when you need to differentiate it from another product, like the mobile app, or explain a task specific to the admin. In these cases, you can use “Commure admin”.
A good description can:
- Increase adoption of the product area
- Help establish a mental model for physicians
- Clarify where the area fits into the product system
- Help support staff and physicians understand each other when communicating
A good description should:
- Avoid jargon
- Be used consistently
- Describe the area it represents
- Prioritize terminology used by physicians over industry standards
Use consistent descriptions when referring to areas in the Commure application.
- The patient list is found on the Patients page.
- Manage patients in Patients.
- Patient information is automatically added to Patients in the Commure admin.
Physicians call our main product offering “Commure”, so we use that same terminology.
- Use “Commure” when talking about our main product offering
- Use “Commure admin” if you need to differentiate it from the mobile app
- Don’t use “admin” or “Commure admin” if “Commure” will do
Using “app”
For app names in areas with surrounding context, like in the app store or on the Apps page in the Commure admin, don’t add the word “app” to the end of the name.
Exception: Listrunner's webpage is www.listrunnerapp.com and can be referred to as the Listrunner app page. This is due to pre-existing brand guidelines.
General guidelines
In general, capitalize evocative names and don’t capitalize feature names. Avoid acronyms, and think about how your audience will interpret a name.
Capitalization
Don’t capitalize default features. Default features are built into Commure and physicians don’t have to sign up, add, or opt in to use them. Examples names for default features include analytics and admin.
Capitalizing names should only happen:
- For independently branded, evocative names
- When we want to try and claim specific words (think Tweet or Pin)
- For names listed in top level navigation, like Products
Names shouldn’t be capitalized if they:
- Are descriptive
- Include common or familiar words
- Are default features
Acronyms and abbreviations
An acronym is a word formed from parts of an existing compound term. For example, “rich text editor” could be written as “RTE”. An abbreviation is a shortened form of a written word or phrase used in place of the whole word or phrase. “Amt” is an abbreviation for “amount”.
Our stance on acronyms:
- Use acronyms if they are established and clearly improve the UX
- Avoid creating acronyms
- Acronyms take longer to understand and might reduce adoption of a product, feature, or concept
- Acronyms are like inside jokes—people who understand the acronym feel included in the meaning, but people who don’t feel left out and confused
- If you have to use an acronym, spell it out the first time you use it and follow with the acronym in brackets
- Internationally understood acronyms and abbreviations are acceptable, like the word “app” or “HR”
- FHIR and SMART have their own guidelines
Avoid using Internet slang acronyms in Commure products and when creating new, branded names. These acronyms are exclusive to certain online communities and are not approachable for everyday physicians.
Some acronyms are commonly used in the international medical community. If they have to be used, spell them out the first time to educate new physicians about their meaning.
Similar names
Being a medical platform has its naming challenges. For example, a lot of feature names could include the word “medicine” or “labs”. Think physician-first and be descriptive to differentiate the name. Picture what it’s like to have conversations with physicians about similar names like Commure Vitals and Commure Labs, or around our pricing plans to identify names that might be confusing.
Before naming a new product or feature:
- Conduct an audit of our vocabulary list to narrow down your naming choices
- Ask the sales team, support team and marketing team to see if they think it’ll conflict with another name
- Draft a test conversation around similar sounding names
Avoiding negative connotations
Some words or terms have unintended negative connotations for some audiences. Do some research to avoid associating offensive words or phrases with your product or feature name.
Start by:
- Saying it out loud
- Getting people outside of your team to look at the name with a new perspective
- Doing a Google search to see if it surfaces with another meaning
Components
Be strategic and consistent when naming components. It makes it easier to create and build products and features for Commure when people can switch between implementations and see the same names represented throughout.
For example, we should use the same name across Rust, React, and Sketch. It’s okay if each implementation has its own spelling convention. For example, Patient list in documentation and in Sketch layer names, but “ui_patient_list in Rust, and “PatientList” in React.
A good component name can:
- Increase adoption of a component
- Clarify where a component fits into our system
- Help establish a mental model for people using the components
Component names in documentation should:
- Describe the functionality they represent
- Avoid jargon so different disciplines understand its function
- Be written in singular, not plural, format
In documentation we write out the name without any punctuation and use sentence case, meaning, the first word is capitalized and the rest is lowercase.
In code, we use the same name as the documentation, but can alter the spelling convention to suit the implementation.
For sub-components, the same rules apply. In documentation, write out the name with a space between words, and use sentence case.
For sub-components in the code, use a period in place of the space.
For all components, use American spelling.:
For FHIR components that use the acronym, in documentation always start with the acronym and capitalize it. Aside from that, standard guidelines apply. Write out the name with a space between words, and use sentence case.