The UX of Currency Display — What’s in a $ Sign?
There’s more than meets the eye when it comes to how currency shows up in your UI. Symbols, codes, and values matter in a global product.
By Joe McCunney, Globalization Architect on the Global Growth Engineering Team at Workday
If you had $10.00, what would you buy for lunch?
It could depend on few things. On one hand, you might think ,“it depends on what I feel like eating that day;” on the other, you might ask yourself, “where am I eating?” This where is a key concept when it comes to currencies, and carries with it a deeper meaning. This I promise will drive you into a rabbit hole of the UX of currency display, part of the bigger wonderland of internationalization and localization.
Let’s consider a slightly different question. Monetarily speaking, what does $10.00 really mean? Or better yet, what is the actual currency of $10.00?
Are we talking the Hong Kong Dollar, Australian Dollar, or US Dollar? Or is it even a “dollar” at all?
The $ symbol is one of the most widely used currency symbols to represent various currencies. It is currently used in 28 different countries and doesn’t always mean “dollar.” For example, in both Argentina and Uruguay, the $ symbol can represent the Argentine peso and Uruguayan peso, respectively.
So all this time were most of us incorrect in assuming and thinking “dollar” whenever we saw the $ symbol (yes, you did it again)? Not really. It’s just the way we’re wired; it’s based on our schooling, culture, or simply what we were exposed to, and now it’s ingrained in us. Because symbols like the $ sign are ingrained in our everyday psyche, we may not think twice about the deeper meaning behind what it represents. Going back to our example, when considering the actual value of $10.00, we need a bit more context to help dispel any assumptions or misunderstandings.
Currency and the User’s Context
A host of UX references will tell you that for anything in UI design, context is key. We need to consider an experience in which users can intuitively understand what is presented to them at a glance, and on top of that, create an aesthetically pleasing design within a modern day cloud application.
Good design anticipates the user’s needs in context. Let’s look at a few different ways of displaying currency codes, and why certain things might need to be considered when displaying these currencies.
Imagine that you’re Ms. Jane Halick, a head regional sales rep based out of Singapore. As the lead sales rep, you regularly travel all over Asia, across multiple borders, to meet various clients. You’re a seasoned traveler who accumulates receipts from various countries and regions. Before you forget, one of the first things you do when you return home is to run through and submit your expense reports, because if you don’t get to them immediately, the receipts will pile up, and you never know when you’ll have time later.
Let’s take an expense report with minimal context. If expense reports only reflected the symbols in the currency input field, you might see something similar to the following:
Let’s say your company had a lunch budget of $20.00 Singaporean and a dinner budget of $50.00 Singaporean. From first glance, a number of questions arise:
- How do you know what you’re actually spending is Singaporean dollars?
- Is the $16.00 spent with Ms. Mathma and the $16.00 spent with Mr. Akbar the same value in the same currency?
- What currency does the ¥ sign represent? Is it the Japanese Yen or the Chinese Yuan?
Looking at the above chart, it’s difficult to guess what the amounts exactly mean in relation to your budget, or to determine the actual value of each itemized row. Without additional context, it’s impossible to determine what the exact amount is in relation to your needs.
Location — Enough or Not Enough?
Okay, so let’s provide a little more context by adding a column with the location names of the cities or countries where the transactions actually occurred. We might then have something like the following:
From a contextual perspective, this might seem better, but it’s actually just as confusing.
We see that you started your journey in Hong Kong, and ended up in Sydney, hopping around a few countries in between. We also see that in Tokyo, there was a charge for $10.00. You ask yourself, isn’t that supposed to be in Yen? Then you remember that you paid with your US corporate credit card, so you made the charge in US currency. However, this is still not very useful to you since your primary currency is the Singaporean dollar and you want to see the amounts in your local currency.
Associating the expense amounts with country or city names still creates quite a bit of ambiguity. It might tell you where you’ve spent that amount, but does it really tell you the actual amount spent in that particular region? Not exactly and there may be multiple reasons for this. Many regions in the world accept multiple forms of currency. For example, Guatemala accepts both the US Dollar and the Guatemalan quetzal as official currencies. On top of that, credit card transactions can potentially be charged in the credit card’s home currency (where the card was issued), and if you’re the adventurous foodie type who likes eating at one of the local hole-in-the-wall hangouts in some back alley (because that’s where you find the best food), they may accept any major currency.
In an era where applications are used globally, context means everything, so without the currency code considered as a design element, there is no effective way to visualize what your expenses really mean monetarily. In addition, if somebody else wants to view your expense report who isn’t based out of your home country, we need a way to contextually represent this so they understand what they are seeing in their currency.
For instance, if you are based out of Singapore, but your manager is based out of the US, what they should see from a currency standpoint should be different from what you see.
From the perspective of an expense report, what this means is that contextually, the expense reports should be dynamic enough to switch between currencies based on the end user’s preferred currency.
User’s Local Currency
Let’s remove the location column which was included in the previous example, and in its place show the currency code with the expensed amount, as well as a separate column with the amounts in the user’s local currency (in this case the Singaporean dollar or the SGD).
From a contextual perspective, for international organizations, displaying expenses in this way makes the most sense. By incorporating UI design considerations like displaying the currency code and local currency amount rather than location, this not only gives users the much needed context to make better decisions, but it also reduces potential misunderstandings and reduces questions which might come up from a less multi-culturally intuitive design. Simple design elements make things like expense reports easier to understand if multiple currencies are being expensed. This small addition of the currency code creates a more intuitive UI for global users who may be used to dealing with multiple currencies.
So, there you have it. We’re done, high five! This is all there is to currency symbols and how to handle currency codes, right? Well…not exactly.
Currency Display and Symbolism
You’ve only just entered the rabbit hole of the $ symbol and considerations for displaying monetary amounts. There are cultural, regional, and locale considerations which need to be taken into account when dealing with the display of currency symbols, codes, and the actual numeric values themselves
So here we go again, full circle…if you had $10.00, what would you buy for lunch?
The answer has further complexity. Decimal places and symbols are handled differently across the globe. If you were a French user, you might say that the “$10.00” doesn’t make sense, or that it’s simply not formatted according to standard.
Examples in Decimal Place Design:
- The accurate display of a monetary amount, its currency symbol, and decimal separator in France would be: 10,00 $ USD and for larger numbers would be 50 000,00 $ USD. This is because, in France, the currency symbol should be displayed on the right of the numeric amount. Also, rather than a period for a decimal separator, the French use a comma as a decimal separator and a space for the thousands separator.
- Algeria, Iraq, Kuwait and a few other Middle Eastern nations may display three decimal places rather than the two decimal places you find in the US.
- Japan, Korea and a few other countries don’t use decimal places when displaying the local currency. For example, ¥10,000 Japanese Yen and ₩50,000 Korean Won.
Decimals aren’t the only consideration. Right-to-left and bi-directional regions have additional design considerations, which affect the display of the entire application, including text and currency. An Arabic user (depending on which Arabic country the user is based in) may need to see the numeric value displayed right-to-left and in Arabic script.
At Workday, we believe every user should be able to see the currency symbol and value in the way that makes sense for them. Every region has its own format settings, called format masks, for currencies. Workday sets the default formats within “Preferred Locale” under “Change Preferences” and, as of Summer 2019, we offer 84 different locales, each with its own format mask for currencies.
UX Design Considerations
Even if your organization is only operated out of a single country, you may need to consider the International Standard for Currency Codes. No one starts a company with the intention that it shouldn’t grow. In five years, your company may be operating overseas. If you haven’t considered currency codes in the original design, to go back and fix that would be potentially costly for your organization. If you consider currency codes up front, early in designing the application, you are helping to future proof your business.
The million dollar question is, how do you design and maintain currency codes, values, and symbols in a scalable way?
The hope is that, in a fully integrated system architecture, the designer or developer won’t need to check currency formatting guidelines, or worry about various internationalization elements from a technical perspective. Leveraging the International Components for Unicode, as well as incorporating global best practices into your overall design of a system is essential when considering system architecture design. When the end user accesses components such as expense reports or paychecks, or even just currency fields, these elements should be displayed correctly and in the proper format.
From the design perspective, we want to consider whether or not the field widths are wide enough to accommodate for the display of larger currencies, multiple decimal places, or no decimal places. When designing using currencies or any global feature, the best thing to do is to get end user feedback, if available, from your international users. In this way, you help to ensure that the applications you are building or designing not only adhere to your corporate standards, but are global friendly.
If you’re interested in issues of globalization, feel free to reach out to the Global Growth Engineering team at Workday.