Research-led permissions that unblocked sales and ended support tickets
Context
Divvy is a financial management platform that combines corporate credit cards with software for real-time expense tracking. It offers enhanced control over budgets and integrates with accounting systems for streamlined financial operations.
Problem
Divvy only offered two roles, Admin and Member, so customers who wanted a bookkeeper to reconcile their books had to hand over full Admin access to company credit. It was a security risk customers kept flagging, and a gap that showed up in support and sales. They needed role-specific access that was safe by default.
Impact
Replacing the blunt Admin/Member split with a research-led Bookkeeper role gave bookkeepers exactly the access they needed, without the security risk — closing the gap that had been costing deals and driving support tickets. Adoption grew steadily after the beta launched, sales stopped losing deals to the gap, and the permissions matrix is still the team's reference years later.
Team
- Product Manager
- Product Designer (me)
- Dev Lead
- Back-End Developers (2)
- Front-End Developers (2)
- Mobile Developer
Why I pushed for research
This was a big project. A new role touches every page of the product, so we couldn't ship something rough and iterate in the open. We had to get it close to right the first time.
It also wasn't a system we could easily walk back. The permission framework carried enough technical dependencies that once engineering committed to a path, changing direction meant unpicking work across the stack. That pushed the cost of being wrong to the front of the project, so we designed it fully up front and built iteratively from there.
That made the case for research, and I made it over some pushback on the timeline. We landed on two months of research and one month of design. That work still stands in the Divvy product years later, and the research is still referenced.
What the research surfaced
I went deep but fast, reading 122 support chats, interviewing 14 customers, surveying 123 more, and running a 153-person card sort on exactly which permissions this role should and shouldn't have.
The picture converged quickly:
- The job to be done was reconciling the books, which meant categorizing transactions, ensuring completeness, syncing to accounting software, and running reports.
- The people doing it were accountants and bookkeepers, and separation of duties mattered deeply to them.
- There was consensus on nearly every permission except three, which split 50/50 and became optional, opt-in permissions. Two more roles also surfaced as real, separate needs.
Mapping the permissions
Divvy's existing model was binary: Admins could do everything, and Members could only do what a budget assigned them. The Bookkeeper role didn't fit either pattern — it could hold a card, sit inside budgets, and still needed visibility across all of them, whether it owned a budget, was just a member of one, or that budget had any funds in it at all. That added a real dimension to the app: whether someone had a card, which budgets they were in, whether those budgets had funds, and whether they owned or just belonged to each one all now had to combine correctly with the new role.
The complexity wasn't the role itself, then — it was the interactions. I documented exactly how the role and the budget permissions intersect across every feature, then went screen by screen to identify which elements should appear for which combination of permissions. That matrix is still referenced more than two years later.
Designing and shipping it
Designing the experience for setting the new role was straightforward. The one real question was how to display the optional permissions that came with the Bookkeeper. On mobile we already had a pattern for exactly this: a drill-in row that rolls the selections up into a count. I followed it rather than inventing something new, keeping it consistent with the rest of the app. On web I explored doing the same thing, but ended up going a different direction with checkboxes. Listing them inline let an admin see at a glance which additional permissions were set instead of clicking into a dropdown to recall what was behind it. That favors recognition over recall, and it kept a person's access visible while it was still being assigned.
With the system mapped and Divvy's design system in hand, designing each screen for the new role became largely documentation. I produced before-and-after screens for web and mobile, reviewed them with customers and stakeholders, and the designs passed on the first try.
We shipped in chunks to de-risk it. The most-requested capability, viewing and editing all transactions, went to beta first, with the full release about a month later, then the role rolled out on mobile and across the rest of the product.
Keeping a big group aligned
A project this wide came with a large stakeholder group, and keeping everyone aligned was its own design problem. I turned everything I could (research, decisions, tradeoffs, and progress) into clear reports and visuals, so stakeholders stayed informed and bought in the whole way through rather than at the end.
What I took away
Advocating for research on a high-stakes, every-part-of-the-product change was the right call, and the upfront investment is exactly why the work still holds up years later.
That doesn't make designing everything up front my default. Most of the time you should design iteratively, because even great research has limits. What people report and what they actually do don't always match, and research rarely predicts exactly how something will land once it ships. Releasing in smaller pieces lets real behavior correct you while correcting is still cheap.
This project earned the exception because the permission framework was hard to reverse once it was in motion. Knowing which of those two situations you are in is the part I carry forward.