Creating a user guide, error messages and tooltips
Summary
I created a user guide, error messages and tooltips for a new software product at Barclaycard Business.
(Note: Even though the software was created in 2018, it was built on old architecture, so the visual design looks quite dated 😕 )
The problem
The software needed to help our business customers manage 'chargeback' cases made against them.
A chargeback happens when a customer formally challenges a payment taken from their bank account.
The brief was to:
-
Ensure the software was easy to use
-
Ensure the user knew where to find help if they needed it
-
Reduce 'needless' calls into the contact centre by providing online guidance content
My approach
1. Briefing
I was brought into the development team after the the first version of the software had been built.
The Lead Engineer gave me a demo of the software. He answered the multitude of questions I had about how the software worked.
I then worked with the Product Owner and UX Designer to understand how we could improve the user experience using content.
2. Designed UX content
Collaborating with the UX Designer, I re-wrote the UX content. This included labels, button text, error messages and tooltips.
Error messages
See below some examples of the error messages I wrote for the system. I tried to make these messages as useful as possible, highlighting positive actions the user could take to fix the problem.
Where possible, I pushed Engineers to make the error messages dynamic – surfacing useful information in the message.
For example: "Error – [CASE ID NUMBER] has already been accepted by [USERNAME]". This small but useful feature helps users see who in their team had been dealing with that specific chargeback case.
Tooltips
Here's a screenshot of the tooltip messages I wrote.
Users could click an ⓘ symbol to expand the tooltip (see below screenshot, right hand side).
Accessibility push back – abbreviations
Someone in my team suggested that we didn't need to explain the abbreviations in the above screenshot. They said that nearly everyone using the software was going to be a 'super user', and therefore would understand all the abbreviations.
However, I insisted that we at least include tooltips that explained the abbreviations. This would help new users and those who might not be familiar with payment industry jargon.
Abbreviations are often a content accessibility issue that is frequently overlooked. By default, we should explain abbreviations. (Or – my favourite – avoid them whenever possible!)
3. Created support content
Of course, we designed the software so that, hopefully, users wouldn't need to look for help.
We created guidance content so users could quickly and easily find the answers they needed. This would also reduce the number of 'needless' inbound calls to the contact centre.
I made the guidance content simple, actionable and visual, including screenshots of the system in action.
(Here's a link to the draft support content guidance. However, this is only a late-stage draft because I left Barclaycard before it was published.)
4. User testing
-
We listened to recordings of user testing sessions, led by our Researcher. The participants were chosen from a small sample of our high volume customers.
-
We found that users were very happy about the changes to the platform – given how bad the previous version of it was. (Previously, they had to fax their documentation over... and that's no fun for anyone!)
-
There was some minor feedback about technical aspects of the software
5. Iterated designs based on feedback
We implemented the feedback from the testing sessions, and I updated the support content accordingly.
Outcomes
-
Users found the software intuitive and were able to complete their tasks easily
-
Users found the support content easy to understand
-
The launch of the software was a big step for Barclaycard as a digital first business