Research-led permissions that ended support tickets and unblocked sales

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.

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.

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.

The complexity wasn't the role itself. It was the interactions. In Divvy, a person has a role but can also be a budget owner or a budget member, each carrying its own permissions per budget. I documented exactly how the role and the budget permissions intersect across every feature, so design and engineering could reason about it without guessing. That matrix is still referenced more than two years later.

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.

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.

Within 8 months of launch, 7,606 users had assigned the new role, across about 9% of customer accounts, and adoption grew steadily month over month. Most didn't need the optional permissions, but the customers who did called them essential.

And the pressure that started the project eased. Sales reported no meaningful close-loss tied to the missing role, and support saw no significant traffic about it anymore.

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. And on a project with this many stakeholders, clear communication wasn't overhead; it was part of the design.