The Paystack Web Dashboard gives businesses and their service providers a variety of essential tools to manage customer transactions. With so many actors stirring the pot, from external developer support to operation managers, how could we provide oversight to administrators trying to make sense of who did what, when and where on their Paystack integrations?
Customer support consistently reported a rising number of cases where merchants called or emailed to report or ask about activities that had been carried out on their accounts without their knowledge.
“Payouts to our business bank have stopped!”
- Angry Merchant
A typical Paystack Merchant has anywhere between 2 to 4 external service provider roles accessing their Dashboard in a week. Include the number of internal business staff members carrying out daily operations and a myriad other activities, all without any accountability or records to show who did what, when, where, and we are left with the right conditions for “a customer support hell”, as one Paystack support expert put it.
The customer support team had some pretty interesting ideas on how to solve the crisis but in order to get to the root of the problem, I needed to hear first hand from the businesses with the issues. So for a week, I worked with the support teams as a support agent, answering merchant tickets.
An analysis of my observations gathered from my week working on user enquires and complaints showed there was a clear need for businesses to have insight into their dashboard activities. This insight needed to
Like most SaaS products, all user actions on the Paystack Dashboard were already being logged in various databases. The primary task was to transform this data into easily digestible information and ensure intuitive navigation for users.
A single user activity contains a plethora of information and could have multiple effects across numerous sections of a business’ dashboard. Only necessary and actionable information need be presented to the user, with options to progressively disclose more.
This early hifi iteration of Audit Logs didn’t fly. For one, it didn’t show enough information. A huge missing piece was the resulting change from the activity.
When viewing early prototype versions of an activity, 87% of test participants tried clicking the described change to view more. I had initially encapsulated activity change summaries behind a link but user testing results indicated that this was information users wanted to see up front.
This version took up unnecessary screen real-estate.
Changes weren’t pronounced in this version.
This version was the winner. It clearly showed what had changed and the current status of the changed entity, all at a glance.
A major use case for the Audit Logs feature, was businesses auditing their organization’s books. To that end we needed to provide simple tools for sifting through logs of past actions for auditors and any other authorized users looking to quickly and efficiently find activities.
Within the first 3 weeks of launching, the Audit Logs feature had 18,000 businesses actively using it everyday. By the end of the quarter, business-action related support tickets had dropped by 60%.
As with every project, I learnt a lot from the experience. In this case, there is nothing like hearing straight from users when trying to understand their pain points. Documentation and accounts from the customer support teams accurately described the problems businesses were having but a lot can get lost in translation. There is no substitute for getting first-hand information from users in the thick of it.