using research to ensure success when it matters most

context

Divvy offers a financial management platform that combines corporate credit cards with software to help businesses manage and track expenses in real-time. It provides enhanced control over budgets and integrates with accounting systems for streamlined financial operations.

problem

Divvy faced a significant challenge with its user role limitations. Our platform only offered Admin and Member roles, compelling customers to grant bookkeepers full Admin access to view transaction data. This exposed companies to potential security risks as it allowed bookkeepers unrestricted access to company credit. Customers urgently needed a more secure, role-specific access solution to safely manage their financial data without compromising control.

team

Product Manager
Product Designer (me)
Dev Lead
Backend Developers (2)
Front-End Developers (2)
Mobile Developer (1)

Methods

Customer support chat analysis, user interviews, survey, card sort, competitor analysis, wireframing, user testing, prototyping, and interaction design

Empathy

Customer support chat analysis

I began researching the problem by talking to our customer-facing teams. I then read through 122 customer support chats related to the feature request. From this, I put together a list of jobs to be done and outstanding questions.

User Interviews

I set up video calls with customers to dig in further. I did 14 user interviews. In these interviews, I asked the customers to describe their workflow, the reason for needing this feature, how this feature would fit into their workflow, and what they would call the feature.

Survey

I surveyed 123 customers to confirm the jobs to be done and identify the most common ones.

Card sort

I put together a card sort with various permissions within the product and had 153 customers sort which permissions they would expect this role to have and not have.

Competitor analysis

I did a competitor analysis to understand how our competitors solve this problem within their products.

Key Insights

The primary job to be done was to reconcile the books. This included activities like categorizing transactions, ensuring transactions are complete, syncing transactions to their accounting software, and running reports.
The two most common job titles for users who would be assigned this role were Accountant and Bookkeeper.
Ensuring separation of duties was very important to our users.
While there was consensus on most permissions, there were 3 that were split 50/50.
We identified 2 additional roles needed by our customers.

Screen Shot 2022-11-13 at 8.28.54 PM.png

Screen Shot 2022-11-13 at 8.29.00 PM.png

Screen Shot 2022-11-13 at 8.29.07 PM.png

Screen Shot 2022-11-13 at 8.29.44 PM.png

Screen Shot 2022-11-13 at 8.29.14 PM.png

Screen Shot 2022-11-13 at 8.29.26 PM.png

Permissions matrix

The needed permissions were clear at this point, but the details were complex. Within Divvy, a user has a role but can also be assigned a budget owner or budget member which brings its own set of permissions per budget. I needed to document the permissions in a way that considered how the roles and the budget permissions interacted. It is fun to note that this documentation is still referenced over 2 years after I made it.

Iterations

The needed permissions were clear at this point. Now I needed to determine the experience in assigning the role, setting the optional permissions, and what each page would look like for the Bookkeeper. Determining what each page looked like was a bit more complicated than one might think since a Bookkeeper could also be assigned as a budget owner and budget member, which had their own permissions.

I iterated on possible flows for the experience of assigning the role and setting optional permissions. I received feedback from customers and internal stakeholders and iterated until it was easy for customers and met the requirements of our stakeholders.

Having a solid understanding of Divvy’s design system, determining what each screen would look like for a Bookkeeper was just a matter of documentation. I created a before and after of each screen on both web and mobile. I reviewed these with both customers and stakeholders and it was a success on the first try.

Screenshot 2023-02-11 at 12.20.14 PM.png

Screenshot 2023-02-11 at 12.10.20 PM.png

Screenshot 2023-02-11 at 12.19.41 PM.png

Screenshot 2023-02-11 at 12.11.43 PM.png

Screenshot 2023-02-11 at 12.19.14 PM.png

Screenshot 2023-02-11 at 12.13.13 PM.png

Release

Due to the size of the engineering effort, we broke down this release into several smaller chunks. We began by building the most requested feature: view and edit all transactions. Once built and tested, we released this to a beta. About a month later we released the feature to all customers.

Shortly after the initial release we added the additional permissions, added the Bookkeeper transaction experience to mobile, and began the work to create the Bookkeeper experience for all pages in the web and mobile app.

Add person screen with ability to select “Bookkeeper” and select additional permissions

Data

To determine the success of this project we followed a few different metrics:

Metric: The percentage of users that were assigned the new role (adoption)
Outcome: Within the 8 months of full launch, we saw 7,606 users assigned this new role from about 9% of our customer accounts.

Metric: The percentage of users with additional permissions toggled on (adoption)
Outcome: While the majority (~80%) of users did not utilize the additional permissions, they were reported to be very important for the customers who did.

Metric: The percentage of those users who were assigned the new role that remained in that new role (retention)
Outcome: We ran into technical blockers tracking the number of users who were assigned this role and then reverted back to another role.

Metric: Close-lost sales opportunities related to the lack of a bookkeeper role
Outcome: Our sales team reported no significant close-loss numbers related to the lack of a bookkeeper-type role.

Metric: Number of support tickets related to the need for a bookkeeper role
Outcome: Our support team reported no significant traffic related to the need for a bookkeeper-type role.

Recap and Reflection

Key Challenges and Solutions

Challenge: This project was very large. It touched every piece of the product. Given the amount of work this would take to implement, we didn’t want to throw out something, see how it went, and then iterate again. We needed to get it as close to right as we could the first time.
Solution: I advocated for the need to research this project thoroughly. My PM and I received pushback on the research we did, but ultimately the results we provided with just 2 months of research and 1 month of designing still stand to this day (as of February 2023) in the Divvy product. The research I did is still referenced.

Challenge: There were a lot of stakeholders on this project. Keeping everyone up-to-date and happy was a challenge.
Solution: I created reports and visuals of everything I could to quickly and accurately communicate with our stakeholders. This worked wonderfully. We were able to keep the stakeholders informed and they were happy with the work we were doing.