The project I'm working on at the moment wants to use the software we're working on as an opportunity to homogenize the use of certain terminology across the whole organization. (To give you an idea, we had about ten different terms that would refer to two different things and sometimes the words would overlap).


download bmml source – Wireframes created with Balsamiq Mockups

We ended up (or actually the client ended up making up his mind), defining a unique term to represent Object A, and Object B. But they happen to be too large. Something like "Extremely Large Object Name" and immediately an acronym spawned: "ELON".

In some places of the application we can afford to call the ELON, Extremely Large Object Name because the screen real state permits it. But other screens have a lot of controls and naming the ELON by its full name its just inconvenient.

I'm a big advocate for visual design and consistency, but I can compromise. I suggested using ELON when Extremely Large Object Name just wouldn't fit (with an appropriate onmouseover() tooltip). But there has been dabate about it.

  • Some people say, name it ELON everywhere, which I don't consider appropriate, since the application might be used from time to time by people that don't know what the acronym means.

  • Some other people say, name it Extremely Large Object Name, which is verbose enough to hint the user what the field does, but that is likely to break the templates that we have.

How would you come about it? Is there any Information Architecture philosophy around the use of acronyms within applications and its relationship with how acquainted the users are with terms? (i.e. if the user doesn't use the application often, they might forget what the acronym meant).

Hopefully this makes sense.


4 Answers 4


As usual, the answer is "it depends on your users". Acronyms are inherently unfriendly to new users (in this case, new people to your organization), because you are left trying to figure out what they mean - I work in an environment that LOVES to use acronyms for everything, and it took me the better part of 3 years to get fluent.

On the upside, acronyms save space and convey information quicker to users familiar with them. It sounds like in your problem space there is some overloading of terms which might cause confusion - you've taken a page out of domain-driven design and worked with your client to define parts of a ubiquitous language, which is good. I like your idea of providing tooltips over the acronyms to define them, but it may be unnecessary. My shop's philosophy is to provide landing pages that use both the acronyms and their expanded form, i.e.,

Welcome, User X! This is the Vacation Expense System (VES), where you can fill out expense reports (ERs) for vacation expenses.

Generally people will pick up the acronym quickly after seeing it like this, so it may be unnecessary to provide a tooltip on every usage of the acronym; still, consider these factors in making your choice:

  • Expertise of your users (are these terms old hat? or are users frequently novices to the domain?)
  • The size of your acronym vocabulary (are there 10 terms? 100 terms? 1000 terms?). If there are a lot of acronyms, providing the definition readily becomes more valuable.
  • They're using the software to homogenize the vocabulary across different company locations with different vocabularies, which I see as kind of a Catch 22
    – edgarator
    Commented Sep 4, 2013 at 2:09
  • Sounds like providing the definition might be the way to go then, to prevent user confusion during the linguistic transition. Commented Sep 4, 2013 at 3:34

I think this question falls under the Communication Manager's domain (which the UX designer has to deal with from time to time). I say this because larger organizations have a writing style guide that dictates how acronyms should be applied for consistency is publication and corporate communication. Whether they define a standard for software applications, or if that falls under the responsibility of the UX designer (or both) will determine what rules to apply (or ignore). I am a firm believer that the content is king, and making design decisions based on compromising consistency or content should only be encouraged if there is a very good reason for doing so (having no rules is not an excuse).

Considerations such as the expertise of users and the frequency or occurrence of these terms affect the usability of the application, which means that the writing guide should give consideration when setting rules for desktop or web applications.


I would abandon your long name and come up with something shorter. Question why it is so long. Are your existing terms long also? If not, consider using the best of these existing terms as your new standard term, or as a basis for finding a new shorter term.


Provide special (and quick) answers in your global search for those who search for acronyms.

"Forgot what ELON is? Use search in the top right corner!"

I think (not) using acronyms or extremely long terms is more a customers' business. You can just come up with the solutions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.