Shorter stories
Web Design
For additional context, see the Merchant Services web portal case study.
The Daily Transactions Report was a static report in the classic web portal that allowed users to select criteria like a time period, a result (approved, declined, pending), and group that report by transaction date or account type. The report then displayed the appropriate transactions and their totals.
There was quantitative evidence from Google Analytics that the report wasn’t used often and it would have been a high level of effort to rebuild the functionality in the upgraded portal.
Additionally, there is the transactions list page, which is new functionality that was built in the upgraded portal. The transactions list page displays all of a customer's transactions in a list. The user can apply filters to see the data they need, export that data to a CSV, and manipulate it in whatever way they need to to meet their organization's specific requirements. The transactions list page was created to provide users with more flexible reporting so they can easily meet their organization's reporting requirements, whereas the Daily Transactions Report was a static report.
Because the Daily Transactions report was not included in the upgraded portal and there was no adequate replacement functionality, user experience benchmark scores decreased dramatically. According to Happiness survey responses and user interviews, users relied on the Daily Transactions Report more than initially indicated by Google Analytics. During discovery, we found that 2 of the most common use cases users relied on the Daily Transactions Report for were quick auditing, and for comparing portal transactions to CRM transactions, i.e. reconciliation.
Those use cases are supported with the new transactions list page, but from user interviews we uncovered major pain points with the transactions list page. The pain points were so extensive that users were not adopting the upgraded portal. They found more value in the Daily Transactions Report, so were returning to the classic portal, which still existed at the time, in order to access this report. As the classic portal was scheduled to be shut down, we recognized that we needed to increase adoption of the upgraded portal. Ultimately, to support the immediate needs of our users, we decided to rebuild the Daily Transactions Report in the upgraded portal.
The transactions list page usability problems and low adoption of the upgraded portal indicated a lack of feature parity and inadequate replacement functionality in the upgraded portal. After the Daily Transactions Report was rebuilt in the upgraded portal, user experience benchmark scores increased dramatically, almost back to where they were prior to the upgraded portal release. This indicates that the addition of the Daily Transactions Report and other enhancements we made had a positive affect of the usability and adoption of the upgraded portal.
The transactions list page allows the user to manipulate their data in whatever way they need, providing flexibility with reporting. Because our users needs are so varied and their organizations have such varied reporting requirements we wanted to continue to analyze our discovery findings to determine how best to add value to the transactions list page and encourage usage of it, rather than having users rely solely on the static Daily Transactions Report.
To start figuring out how to add value to the transactions list page I determined what problems I thought our users would find the most value in if they were solved. I focused on the following pain points identified in discovery.
A few of the open ended survey responses used the word "clunky" to describe the filtering experience. It was unclear exactly what clunky meant. It was also unclear if these users were referencing the filtering mechanism itself (a modal) or if they were including another pain point "must apply/reapply filters multiple times in order to view data needed" in their description. I determined we needed additional discovery for this specific pain point before I could design a viable solution. As of February 2023 this discovery had not begun yet.
The transactions list page was initially set up to only display one list at a time. The user could add/remove filters and columns in order to see different data they needed. Discovery findings indicated that it was frustrating to users to have to apply a set of filters to see the data they needed, then clear those filters and apply different ones in order to see a different set of data. This was especially frustrating for users who knew they needed to view the same sets of data at specified intervals. For example, every Monday apply filters to see Saturday's approved transactions, clear those, reapply filters to see Sunday's approved transactions, clear those, and finally apply filters to see today's approved transactions.
This pain point is related to the removal of the Daily Transactions Report. The Daily Transactions report was used frequently for quick auditing, meaning users were pulling it in order to see totals quickly. A major pain point with the transactions list page is that there are no totals shown in the portal. The user has to export their filtered list to a CSV, and manually add totals.
This new workflow introduces additional pain points:
The web portal provides 3 different unique transaction IDs per transaction. However, there is no uniformity in which transaction ID is displayed in consuming applications (other Blackbaud products). There was going to have to be a wider collaborative effort across multiple products to implement a consistent transaction ID. As of February 2023, that had not been completed.
Because the team's software engineers observed most of the user interviews I conducted, I facilitated a brainstorm session with them where we generated potential solutions. I wrote mini-problem statements for each of the above pain points to keep us on track.
Brainstorming with engineers is valuable because they are easily able to articulate what they think or know is technically possible. Additionally, they will likely have ideas that I would not necessarily think of because I do not know everything that is technically possible.
We implemented 2 solutions proposed during the brainstorm session. The solutions were released in the portal after the 2022 HUX survey because they were technically complicated and took months to implement, so there is no quantitative data yet about how these features impact the experience benchmarks. They will be included in the next HUX survey or Happiness survey, whichever comes first.
Determining the cause of user dissatisfaction with the merchant services web portal was a large and complicated project. All of the work happened simultaneously, so it was hard to write a case study in a linear fashion. I chose to break up the case study into this shorter spotlight story because the Transactions list page was an integral part to the story and I wanted to have more space to explain its importance. If the Daily Transactions Report had initially been included in the upgraded portal I'm not sure that we would ever have discovered all of the usability issues with the transactions list page so quickly. The Daily Transactions Report was important to reconciliation workflows in a way that had not previously been understood. Taking the time to understand why it was so important and why the initial version of the Transactions list page was not an adequate replacement was integral to the success of this project.
The merchant services portal uses Blackbaud's open source design system called SKY UX. The email notifications feature uses multiple SKY components and patterns.
The email notifications feature is accessed on the web portal settings page and is displayed in a SKY UX component called a tile. A tile is a flexible container that is used to display content. All of the settings on the settings page are displayed in their own tiles.
The information in the email notifications tile is displayed using another SKY component called a repeater. Repeaters display information in containers for a list of objects. The objects displayed in the email notifications tile are the types of email notifications available.
There are 11 types of email notifications available and if they have the correct permissions, any user can set up an email notification for themself or another user.
The most recipients per email type today is 11. The average, however, is only 1 - 3 recipients per type.
To set up an email notification, a user selects the desired notification type and adds the desired email address. They will also need to select the frequency at which the email notification is sent to recipients. However, the frequency is set at the type level, meaning each recipient in a notification type will receive the email notification at the same frequency.
Email notifications are tied to the user that created them. This allows anyone to set up and edit notifications for any user. However, it also means that only the user who initially set up the notification is able to view, edit, or delete that notification.
For example, if I set up an email notification for User 1, User 1 would not be able to view, edit, or delete the notification I created for them, even if they had the correct permissions. Only I would be able to view, edit, or delete User 1's email notification.
This creates a few problems:
The solution to the email notifications problem was twofold. Engineering work needed to be done in order to "elevate" the email notifications from the user level to the organization level. This would allow any user in an organization with the correct permissions to view, edit, and delete notifications and would solve all of problems listed above.
This solution would also require a redesign of the UX and UI of the email notifications feature.
Initially, I explored the concept of sorting the email notifications tile repeaters by email recipient rather than by notification type. When a repeater was expanded it would show all of the email notification types a recipient was signed up for as well as their frequency.
Today, the repeaters in the tile are organized by email notification type and when a user needs to edit a recipient’s notifications they are forced to go category by category to edit or delete notifications.
From a UX perspective, organizing the repeaters by recipient made sense. This approach would allow users to edit all of the email notifications for one recipient at the same time and would allow users to easily delete a recipient. However, there were significant technical constraints with this approach. It would essentially be a code rewrite, so would have been a high technical effort to make this approach work.
After several iterations, I landed on a simple and intuitive design. It allows a user to select a notification type and add, edit, or delete a recipient. Additionally, the frequency selection is set at the recipient level.
During testing, one of our QAs uncovered a use case that was overlooked at the beginning of the redesign.
Previously, each recipient in a notification type received notifications at the same frequency, so we did not take into account that a recipient might want to receive the same notification type at multiple frequencies. In the above design there was no way to select multiple frequencies for the same recipient. I redesigned to account for this use case.
If you like what you see and want to work together, get in touch!
