Refining Design Through User Feedback
Problem
Our ePay application was unclear and difficult to complete which resulted in increased support volume
Solution
Introduce an ePay onboarding experience to decrease the time it takes for a property manager to get up and running.
Team
UX Designer (me), Product Manager, Engineers (3)
Background
What is ePay?
ePay is Buildium’s highest generating add-on service that allows property managers to receive online payments from their tenants and rental owners.
How does a user get started?
An application is required in order for property managers to start receiving online payments, however most users didn’t know a setup was required after their application was approved. Even once they were aware, they had difficulty setting it up on their own.
Usability concerns
I moderated a heuristic evaluation of our ePay setup experience with product managers, engineers and UXers, which uncovered major to critical issues in our setup experience.
Impact
The poor usability of the experience had a down stream impact on the business.
Increased support volume
We received 200 calls (340 hours of support) per month around ePay setup alone.
Lost revenue
Tenants can’t make payments if ePay isn’t set up properly. This means our users (and Buildium!) were missing out on a revenue opportunity.
Frustrating user experience
Property managers could rarely configure their ePay settings on their own due to the confusing experience.
Goal 💫
Reduce the time from ePay application approval to first online payment through usability improvements.
Usability tests
Based on the usability issues addressed in heuristic evaluation, I worked with product, customer teams and engineers to redesign the ePay onboarding experience. Before moving forward with development, we needed to test our assumptions—time for usability tests! I led recruiting, wrote the script and moderated the calls.
Findings
Improving the usability of the ePay settings page
Pain points ⚠️
All page elements had the same, flat visual hierarchy
A confusing information architecture caused errors
Various steps of the ePay setup lived on different pages
Copy used “Buildium” nomenclature rather than customer centered language
Common actions were hidden behind too many clicks
What we tested 🧪
Our redesigned page emphasized the primary call to actions, had a reorganized information architecture and alerted users of the required setup.
Research questions:
Do users understand the bank account information?
Do users understand what actions to take on this page?
Do users understand how to edit information once it’s set up?
Do users have any questions or concerns after landing on this page for the first time?
What we learned 🔦
All participants read through the limits and hold days section with ease.
Participants were unclear if they were enabling incoming or outgoing payments.
The majority of users expected to see a visual confirmation after enabling incoming payments.
How we iterated ✨
Based on our learnings, I added an incoming payments header to avoid confusion and introduced a status pill to improve system visibility.
2. Streamline the ePay onboarding experience
Pain point ⚠️
The ePay setup experience was disjointed and fragmented. Users were expected to navigate to several pages in the application in order to fully complete their setup.
What we tested 🧪
The design we tested initially was a streamlined onboarding experience that included property enablement, rental owner enablement and the set up of convenience fees. Instead of having the user scramble throughout Buildium, we provided a directive and supportive experience to guide users throughout the set up.
What we learned 🔦
After flying through the resident setup, users became confused once they landed on the rental owner setup portion because the page layout looked extremely similar to the page layout of step 1. What they didn’t notice was that they were actually completing the setup for a different persona.
How we iterated ✨
To help reduce confusion, we split up the resident and rental owner setups into two separate experiences.
What else did we learn 🔦
Participants understood how to do something but they were confused on what they were doing and why. For example, users understood how to enable specific properties for ePay in the UI, however they were unclear as to what enabling properties actually did in the real world.
How we iterated ✨
We added a cover page to the setup wizard modal to better set users’ expectations. The focused nature of these screens helped users understand what they were doing before getting started.
3. Driving users to the setup flow
Pain points ⚠️
Users were unaware that additional steps were required after their application was approved.
Subject line: Action required: Your Buildium ePay application is approved!
What we tested 🧪
We tested a new email and subject line. The subject line explicitly called out that an action was required even though the application was technically approved. We also added a call to action to drive users to the setup flow in their account. Our research goals for this email were to understand if the language resonated with users and whether users knew a setup was required and how to get started.
Subject line: Action required: Your Buildium ePay application is approved!
What did we learn 🔦
8 out of 8 participants knew a setup was required and clicked the “setup now” button when asked what they would do next. Huge win!
How we iterated ✨
We made some minor tweaks to the content to make it more intuitive and familiar to our users.
Results
Ultimately, we increased the workflow assessment score by 324% which contributed reducing the time from ePay approval to first resident payment by 4 days.
Sharing our story
We were excited to share the amazing insights that came out of our research! 50 + Buildians attended an hour long research readout.
