Appfolio: Influencing Product Road Map by Listening to Customers & Stakeholders

‍My Role 

- Advocated for re-design of core workflow in order to improve customer and developer experience

- Worked alongside product and 8 engineers to deliver this in time for largest conference

- Led end-to-end research for this project including quantitative data and qualitative interviews 

- Created journey maps, lo-fi and hi-fi mockups 

- Planned and facilitated design thinking work

- Prototype I created was presented at QBR in order to advocate for more UX teams in my domain space 

- Presented the new future on the main stage at our Customer Conference with over 5,400 attendees 

‍

Problem

The beginning of the month marks a significant period for Affordable Housing Property Managers. Not only is it rent week, but it’s the week they need to submit a myriad of information, complete complex subsided accounting, and anything that happened in the prior month in hopes of obtaining government money. This process is known as the TRACS Submission process. Everything must go well. One miscalculation in accounting could lose the company upwards of 100k in subsidy payments! The voucher would be rejected and returned for corrections or in HUD world - adjustments. 

How often did this happen to our customers? Too often. Our vouchers had about 50% of them coming back with errors. Seeing this dramatic metric, I asked myself, is this a backend accounting issue or possibly something in the UX of the submission process itself? 

Prior to me joining the team, our product was rushed to launch in under a year. For any product that is a tough timeline, but for a software that integrates with the national government…. That is tough. 

Digging Into the Data: 

“TRACs submission is not the cleanest.”

-Quote Source: Prospects and Customers shared with Sales and SE’s. This design has lead us to lose several deals.

The Technical Problems: 

Not only were the vouchers themselves coming back with errors, developers were getting inundated with bugs every week due to this experience. So many in fact that we implemented a whole new process “lighting bug” which was a new on-call rotation for this page specifically. The overall state management of the page is complex, and actions taken in one place on the page can impact the state of other places on the page in ways that can be rather convoluted to understand, which results in buggy code and poorly written unit tests. 

This problem would be exacerbated by the two additional features that are needed to allow us to go upmarket. This experience had to change, and fast. 
‍

Strategy: Making the Problem Real to Stakeholders

Convincing stakeholders to pivot on our road map to address a feature that technically “works” but was falling apart fast was a challenge. I had to figure out how to make them feel our customers’ pain. 

I conducted a “walking the store exercise” where I asked Senior Directors of Product, UX Design, and Engineering to go through 8 key workflows. They failed 85% of the tasks and asked several questions throughout. I had them rank each flow in order of priority and give it a rating. 

They finally got it. Now they understood rather clearly why the engineers and I have been clamoring about redesign. 

‍

A Short Ramp-Up and BIG Vision 

I had about 5 weeks of lead time before we needed to start development for this project so that we can launch at an upcoming customer conference at the end of the year. 

I quickly put together a Design Sprint where I was able to bring the whole team together to dream up creative solutions to this complex problem. This was challenging because we were not able to start the current work streams that I had in flight, so I was spread thin amongst our 12 engineers. 

‍

‍

I continued to repeat this phrase to my team “Just because the world of Affordable Housing is complex… our software doesn’t have to be.” 

In the sprint, we got very clear about the problems, both technical and user experience. We dreamed and I encouraged the team to go wide, a hard task for developers. The team rallied together and we came up with several different versions that addressed the problem on all fronts. I found it crucial to include developers and our customer support team in this process, as they were the key subject matter experts. I quickly tested it with our charter customers and consumed their feedback. They were impressed with the new solutions, so I raced off to make more medium-fidelity solutions for more testing. Hooray! 

‍

I continued to make iterations on feedback from testing. I decided to break this up into 3 major actions and create one dashboard where a customer could launch off from these actions. 

‍

‍

‍

I continued to make iterations on feedback from testing. I decided to break this up into 3 major actions and add a modular approach and create one dashboard where a customer could launch off from these actions. I made more HiFi solutions and after several rounds of feedback from peers I fixed a pesky navigation as well! 

‍

‍

‍

‍

Naming became a big challenge. The industry uses several words interchangeably. However, depending on region of the US one term is used more than others. Because of this, I did extensive testing and research. In the designs I showcased you can see different terms being used. In the end I landed on HAP Submission Experience because the HAP is what you get from the government at the end of this.

Dashboard Experience

The problem was that these flows did not account for another issue. Where does this all live? We built the product very fast and sadly did not stop to think about architecture. During this time, I was able to go to the Config conference where I spoke to several design professionals about this very issue. To fix this issue,  I designed a new dashboard experience. I had a vision for a new dashboard that would serve as not only an action center, hub for previous vouchers sent, but a launching point for the 3 key workflows. I laid down a vision for where we would go in the future, but understood the constraints that we may not be able to do now. 

‍

‍

Due to contratints and customer feedback, I decided to use Dashboard Version 1 which actually ended up driving new components for our design system to help modrenize our workflows.

‍

Major Wins and Learnings 

I was able to showcase this design at our customer conference. The feedback was sensational!

“We have never seen Affordable Housing look so sleek before.” -Horizon Customer, 5,000 Units 

This quote made it all worth it. Now, we were ahead of the market and in fact, leading the way of change for all Affordable Housing Products. Our Voucher submission rate increased. With the momentum at Future, we were able to go upmarket and have successfully achieved our company-wide OKR of unit acquisition. 

Organizational Change 

This new design showcased to the org that we did in fact need to slow down. We did need to remember the importance of talking to customers and validating designs. This design was presented at our QBR to the C-Suite staff in order to advocate for more UX Designers in my domain space. C-Suite leaders saw the importance and power that good design can have on customers and business outcomes - a major win for me as a designer and leader! This is who I am truly as a designer, not someone who only thinks about the user needs, but rather what is good for the buisness and employees.

Constraints 

-Spread thinly on 4 different work streams with 9 engineers. Seeing that we were  

-Small testing window on a complex project space 

-Solving the needs of upmarket customers we did not have yet, I had to rely heavily on my design skills and strategy 

-Not being able to solve the navigation issue right away 

-New Design System components being used

‍

‍