Preparing QuickBooks for an adaptive, data-driven future

Overview

Personalisation had been talked about at Intuit for a while. When I joined, it was still mostly a concept. Engineers were interested in using AI to dynamically adjust the product but no one had worked out what that would look like for an actual QuickBooks user sitting down to manage their books.

I was the first dedicated design role focused on it. There wasn’t a brief so I had to define the space in collaboration with a technical director.

The problem

New users were dropping off early and the research pointed to two things: we were asking for too much information upfront and the product wasn’t responding meaningfully to what it knew about the business.

We also had a challenging internal problem; different teams had different ideas of what personalisation meant. Engineering wanted to use AI to customise dynamically, product wanted to reduce feature overwhelm and leadership saw it as a company-wide strategic priority. Getting those perspectives aligned was a big part of the desired outcome.

Design approach

Mapping the data we held

With a technical director, I mapped what we could legally capture, what we could technically capture (pre and post authentication) and what actually mattered for driving a better experience. That gave us a framework to simplify onboarding by collecting less upfront and being smarter about how we used that data downstream.

Making the QuickBooks ecosystem visible

Effective personalisation meant shipping features across squads that didn’t have strong ties to work together. Before I could ask them to take on work outside of their backlogs, I need to show the interconnectedness of personalisation and the costs of not collaborating clear.

I built an end-to-end prototype to show how data and the experience flowed across the product. It showed how a decision made in Onboarding flowed into Get Things Done experience, which affected what insights could be surfaced, etc. We hadn’t mapped this before and the prototype became the primary tool for aligning product directors and squad leads around a shared understanding of what personalisation actually required.

Building tools for teams to work with

Because personalisation cut across multiple squads, I couldn’t just hand over a framework. I created interactive wireframes that showed how a data decision in onboarding would ripple into a different part of the product. This gave teams something concrete to respond to.

I synthesised 20+ research reports alongside primary research and ran workshops to establish shared knowledge on what personalisation meant at the level of a specific widget or user action.

The Personalisation Framework

I worked closely with a technical director and we designed a framework for how we could capture onboarding and early task behaviour to build an abstract customer profile (identity stitching). For example, if a customer indicated during onboarding that they sell products, the system could begin surfacing the inventory widget before they’d asked for it. If their early task behaviour suggested they were a service business, the Get Things Done landing page would adapt accordingly.

This helped us to define what signals to capture and how each squad could act on them within their own part of the product without requiring a central team to coordinate every decision.

Ran a small proof of concept

We partnered with QuickBooks’ YouTube content team to understand how their help videos were tagged and structured. The goal was to explore whether we could surface that content contextually based on where someone was in the product and what they’d done, and during the first 31 days. It was a small experiment, but it gave engineering and product a concrete direction to get behind.

Outcomes

• Simplified onboarding. Fewer inputs based on what mattered for downstream personalisation
• Personalised Get Things Done landing page. Tailored tasks based on what we learned about each user during onboarding, replacing a one-size-fits-all experience
• Proof of concept for contextual help using existing design system components and YouTube content metadata
• Cross-squad collaboration model. Design buddies, quarterly joint sprints and just-enough information sharing to reduce silos without creating overhead ys

Challenges to learn from

I had no direct line to most of the teams I needed to influence. This meant I had to build relationships slowly though 1:1s, mentoring junior designers and making artefacts to engage teams. One ongoing tension was how we measured transaction categorisation. It kept coming up in different conversations with different answers, so eventually I pulled together a small group including PMs, engineering and design to get clear on what we were actually measuring and why. It was a small change but it did unblock a lot of work.