The Importance of Plain-Language Labels
Why you should scan your dashboard for acronyms and underscores
Leaving technical names in your dashboard smacks of inconsideration for your audience.
I’ve seen both inexperienced and more seasoned dashboard developers guilty of this underscore-toting offence and it makes me cringe every time!
Technical what-now?
Technical names (a.k.a. implementation names, field names, system names, column names) are the identifiers used in databases, software, and code to refer to specific data fields. Examples are cust_id (for customer ID), order_amt (for order amount).
When a data analyst first retrieves data from its source, oftentimes whey are writing SQL against a database, using the database’s own terms for each data field. These technical names tend to follow a number of conventions and you can spot them because they are:
Either in all caps or all lower case
Often feature underscores
Contain different abbreviation conventions such as
_numfor number,_dimfor dimension,_dtfor date, and so onNot meant for dashboard end users to see!
What you should use instead
Business names, on the other hand, represent the user-friendly labels used in reports, dashboards, and other interfaces to describe data fields in plain language. These names are written using clear, descriptive words with proper capitalization and spacing.
Business names are the proper choice for anything that goes in front of business users, stakeholders, and non-technical audiences.
In most workplaces, the technical names will be imported into your dashboard by default. You, as the dashboard developer, will need to do the extra work of applying the business names as labels. It is up to you to make sure that your report is free of technical abbreviations and underscores. You and the Clarity Crusader!
The Clarity Crusader leaps over underscores in a single bound, bringing simplicity to the complex. Her keen eyes spot abbreviations lurking in dense reports, capturing and transforming them into full, plain-Language terms. Every day, she wields her shield of transparency, punishing the use of cryptic technical terms in dashboards, ensuring that every graph and chart speaks a language that all can comprehend. Through the city of spreadsheets, the Clarity Crusader fights to keep information accessible and straightforward, a true hero in the realm of clear communication.
Moving on…
Why using business names is important
While terms like sales_num (which we can fairly safely guess represents the number of sales) seem innocuous - others such as prcdcsd or indate10 might not be so intuitive. You can’t expect your business users to correctly guess what each graph is showing from alphanumeric-and-underscore soup.
And even if the business term is easy to guess, should you really be making your audience guess?
That was a rhetoric question. Your answer should be ‘no’.
Remember…
Technical terms are for computers to read, they are not for your end users to read.
Only in niche cases should you be presenting technical terms to your final audience.
Be like the Clarity Crusader
Please do everyone a favour and make sure that, when on display for your report consumers, you refer to your data ONLY in business terms familiar to them. This means making sure that you replace any database terms with the business terms your audience will understand.
While in some cases, the term will be the same (SKU, for example, is a term equally human and computer readable), but, for the most part, you will need to create plain-language labels to overlay the default text brought in from the original queries with proper business names.
The Clarity Crusader will thank you for helping her make the word a clearer, brighter place.
—
For other dashboard mistakes to avoid, check out: