How to design transaction reference numbers
Last updated on
Transaction reference numbers can come in a range of formats and used for a so many different cases, such as ordering from a shop online, filling out a request or a form or another transaction like a banking reference number. But how do you design the best transaction reference?
Questions to ask yourself before you start
This may seem counterintutive to the purpose of the article but before adding a transaction reference to your service ask if you need one to start with?
The problem with references is that they aren’t very easily rememerable. So here are some questions before adding a transaction reference:
- Before you decide to design a reference number, ask if your users really need one.
- Could the same be achieved with the user’s name or email address?
- If the user has a login, can they see their transaction status and history online?
- How will the reference ID benefit the user, whether that be internal or external users?
- If the customer services team speak to the user would they ask the user for a reference ID or ask for something else like auth code or company number?
The purpose of the reference
You should make it clear what the reference is for and what the user might do with it. If the user should write the reference down, then make sure to tell them. But don’t rely on them doing this. Make sure the user receives the reference in any case (for example in an email, text message, or accessible PDF download). Only give the user one reference for a transaction. Users get confused sorting through different references.
Don’t rely on reference numbers
Don’t force users to remember reference numbers to use your service. Reference numbers may be useful to quickly identify transactions, but have fallbacks in place (e.g. user’s name, email address, date of transaction, other transaction content).
Referring to reference numbers
Give the reference number a simple, plain English name, for example, application or reference number. Don’t use internal system names or acronyms (for example: SIK number for System Identification Key number.)
Chunking and chunks
In general usage, a ‘chunk’ means a piece or part of something larger. In the field of cognitive psychology, a chunk is an organisational unit in memory. An example of chunking could be a phone number if you compare +1–919–555–2743 to 19195552743 which one is easier to remember or to say out loud? We see this chunking approach in other areas such as debit cards for card numbers and sort codes. In the field of user-experience design, ‘chunking’ usually refers to breaking up content into small, distinct units of information (or ‘chunks’), as opposed to presenting an undifferentiated mess of atomic information items.
By chunking up a long number/letter string into a digestible format it can help your users and can improve their ability to comprehend and remember it.
Confusing numbers with letters
Another thing to think about is putting capital letters next to numbers can cause legibility issues in certain font families. An example of this is the letter “O” and the number “0” can look similar, another example is the letter “l” and the number “1”. You may want to consider a typeface optimised for numbers, or a monospace font which often have extra signifiers to identify similar characters; 0 and O.
Year in the ID
To help customer services team adding contextual information can help call centre and admin staff (e.g. xxxx xx14 for transactions in 2014, and Axxx-xxxx for transactions relating to one service and Mxxxx-xxx for transactions for another service).
Service name at the start
To make it easier for the customer services team it would be best practice to have the prefix of the service at the start of the transaction ID e.g. report a discrepancy could be RD-00–00–00.
Grouping numbers
From the research it suggests that transaction ID’s should be chunked by either threes or fours. It allows the reader to use prosody (intonation to communicate that they’ve reached the end of the group/code), and It allows for a pause between each to allow the listener to repeat back or interrupt.
For ease of reading it would best practice to not mix the amounts of digits between each dash, for example, 000–00–00–000. Instead keep it consistent such as 00–00–00 or 000–000–000.
Numbers only
Where possible it would best to use numbers only after the service name ID. This will avoid confusion over the phone as someone could get confused between saying 0 and O (as mentioned above with confusing numbers with letters). Numbers are also easierread over phone.
Further reading
Written by
Senior Interaction Designer and Co-Author to Tiny CSS Projects