As a UX design intern at a leading payment solutions company, I relied primarily on Hotjar and Google Analytics for studying user interactions, behaviour and garnering feedbacks. All these eventually constituted to guiding my design decisions.
Payment link is being re-designed with a new concept of re-usable links which would support multiple payments on the same link. The scope of this article is limited to creation of form and its entities and how minor interactions could make the experience better, or worse.
The following sections are conclusions drawn from feedback and analytics of data points gathered. The project is under progress, however I decided to share my brief experience while handling Hotjar and Google analytics.
Meaningful field titles and placeholder text
It is highly important that the field title and its placeholder text together convey a meaningful and complete message.
While creating a payment link, users are asked primarily to fill the amount and description (payment for) of their link.
Across multiple recordings, I saw users were spending a lot of time on the field “Summary” wherein they were required to provide description of payment link.
Also, upon closer inspection on Google analytics, we found that nearly 10% of users were typing the description for more than 800 characters. However, the average character limit was 40.
Most of the users were having tough time to fill the description. On top of that, some of them were providing an input of 800 characters on a hosted page.
There could have been two reasons behind it:
- Counterintuitive field title.
- Absence of placeholder text.
Placeholder text played an important role, since numerous people would input “Payment for buying automobile” in the field of “Payment for”. This would look obnoxious on the hosted page where it’d say:
Payment for “Payment for buying automobile”
Following this, I decided to break down the flow in two parts:
- Title (Purpose for payment) which was mandatory, and had a character limit.
- Description which was optional, and had no character limit.
This made sense, since there were nearly 10% users who wanted to provide a description exceeding 40 characters, while 90% of the users who found 40 characters sufficient.
The field Amount also had a currency symbol preceding it, which made it evident that integers have to be provided here.