Payments Redesign
Introduction
Ancillary Services Management's internal tool helps the company keep track of the services agreements they are involved with; payments made; and the providers, properties, and clients to whom those agreements apply. The tool was originally created with no awareness of usability concerns, so I was brought on to improve the user experience. The final goal will be to transform it into a software as a service (SaaS) product, but my focus at this point has been to reduce the pain involved with its use.
I interviewed the three users of the tool and worked with the product manager (who was also one of the users) and the developer to identify and create both quick fixes and larger, longer-term improvements. I will be going into detail on our redesign of the payments portion of the tool in this section.
Original design
The original design had some major problems from the perspective of the most common use cases. The biggest one was around the need to enter batch payment information. The accountant who needed to use it often had large checks which applied to multiple properties.
The existing interface required scrolling up to the remaining balance and back down to where payments were being entered to track the remaining balance once the list of properties with payments grew longer than the screen real estate. Users also needed to add additional lines for payments themselves, rather than the software realizing that there was still a significant balance remaining and doing it for them. For any data entry-type interface, every time the user has to use the mouse instead of the keyboard - or move around on the page - there is a significant cost in time and focus.
There was also no single page interface to enter single payments, batch payments, scheduled (by the software) and unscheduled (due to a problem with the software) payments. This meant that users had to know which kind of payment needed to be entered before they started, and the developer needed to maintain extra pages.
Exploration Meeting
The developer, product manager, and I met to discuss our thoughts and ideas around the redesign. We talked using freeconferencecall and sketched and clarified our thoughts using Miro.
The product manager was concerned about not making sweeping changes to the interface and providing context that I did not always have around its use, the developer with feasibility and suggestions based on his understanding of the software and UX, and I wanted to be sure to share what I had learned from my interview with the accountant using the software and make general best practices suggestions.
The PM had put together some mockups - still separated between single and batch payments - based on her understanding of that part of the interface, and was worried that my suggestions were too based in a single person's experience. This was an entirely valid concern, but this meant that she had not looked at what I had learned from that interview when creating her mockups. I was able to get across that there were pieces of the accountant's process that needed to be part of the redesign, since he was the one most often using the payments interface and had the most experience with that aspect of the tool's needs.
Once I had successfully communicated the major problems that I believed were not specific to the accountant user, we took a break from that meeting and the developer put together a Balsamiq mockup based on our discussion.
Followup Meeting
We met again, and the product manager and I explained our concerns about the usability of the developer's mockup, since people would have to click on each of the dropdowns to get to what they want. I was also concerned because there was no indication of the remaining amount for a batch payment.
I jumped onto Balsamiq in the meeting and started mocking up some ideas based on my understanding of the user needs. I described what I was doing and why so that it was clearer where my concerns lay, and in the process we came to the conclusion that we could remove the need for multiple payment pages from "single", "batch", "scheduled", and "unscheduled". I also made very sure that the "remaining balance" part would stay at the bottom of the list. We decided to let people tab to add an additional line instead of having it default to happening with a significant amount left in the balance.
Next Steps
After this meeting, the developer put together an initial pass on the new design and requested my feedback. At this point, the plan is to get some usability studies done when the team has time to work with me on it.