From a feature list to one model of the admin’s job

Skim mode is on: just the key point of each paragraph. Turn it off to read the full case study.

The stakes: every hub runs on the admin’s setup

I led UX for HubSpot’s CRM Data Management Group, which builds the tools admins use to understand, configure and maintain the data model every HubSpot hub runs on. I grew the design team from 4 to 7 designers and partnered with 10 cross-functional teams.

The data model is the foundation. Sales, marketing and service all run on the objects, properties and associations an admin sets up. When that setup is wrong, the cost shows up everywhere downstream: reps fill in bad data, reports mislead leaders, and teams stop trusting the CRM.

The pain showed up with reps, but it started with admins. Our support data showed that most rep tickets traced back to how the CRM had been configured. Admins were reactive and overwhelmed. Setup could take many months, and the tools to configure the data model were scattered across the product.

Meanwhile, the roadmap was a list. HubSpot was moving upmarket with its Smart CRM, and leadership’s strategy named the gaps blocking larger customers: sensitive data, global teams, permissions, governance. Every item was real. Together they didn’t add up to an experience. We were catching up to competitors one feature at a time.

The work before the work: one model the whole group could plan against

We wrote the mission before anything else. Before any of the vision was built, my team and I defined the foundations: a mission to help admins understand, configure and maintain their data model, and three UX principles to guide the work. Those three verbs became the stages of the admin’s job: understand the system, configure it to fit the business, and maintain it as the business changes.

Then we mapped the pain at each stage from research and interviews. Partners and admins told us the same story: months of setup, followed by years of fixing what that setup got wrong.

My team and I built the 2024 vision on those foundations. It was the UX vision for unified data management: three principles (an intuitive and unified information architecture, proactive tools that empower admins, and a flexible, scalable data model), plus a roadmap from current work through near-term and future. A senior designer on my team owned the data model workspace concept, and another led the Settings structure work.

Every project had to answer to the admin’s job. Every project on the roadmap, about 25 of them, answered three questions: which business goal does it serve, which part of the admin’s job does it improve, and which UX principle does it advance?

I defined success in the admin’s terms: admin satisfaction (NPS and CSAT), how many admins configured their data model, and how fully their properties were filled in.

I built it to extend the product strategy, not replace it. The vision opened by naming the problem it solved: unseen misalignment. Product had a clear strategy. What it didn’t have was a shared picture of what that strategy meant for the person using it.

The trade-off: keep shipping commitments, or build toward the future

Customer commitments or the future. We had commitments to large customers that couldn’t stop, including work tied to contracts. But if we only worked the list, we’d keep catching up to competitors on features and never fix what was broken underneath.

I ran both in parallel. Committed work kept shipping in the current and near-term columns. At the same time, we explored the deeper ideas in the future column: a central workspace for data admins, a data model health score, smart recommendations, and AI that sets up a data model from plain language. Every project, committed or exploratory, mapped to the same model of the admin’s job. The point was that when our commitments ended, we wouldn’t be starting from zero.

The cost was a running fight to prove the future track was worth it. I kept making the case with snapshots of the vision, the research and the evidence. I also pulled in support and sales. They were the source of most of our feature asks, and they became the people who helped us get past the surface problems to the root ones.

Beyond my team

I took the vision on a roadshow. I presented it group by group to product, engineering and the platform’s general manager, and that’s how it won their buy-in.

Product adopted our mission as the group’s own. The mission and principles my team wrote became the Data Management Group’s official mission, used in its strategy and planning documents.

Admin work crossed group lines, so I built a group that crossed them too. I drove a cross-group UX working group on the admin experience, with owners across data management, account management and settings, approved by the platform’s product leads. It ran alongside HubSpot’s platform-wide navigation redesign, and when the broader effort was paused, the Settings work continued in phases.

I scoped Settings to what could ship. With navigation changing underneath it and our commitments in flight, I chose structural fixes first and deferred the larger information architecture. Account setup owned the admin’s first exposure to HubSpot, so after working through the options together, I handed overall Settings ownership to them. My team owned the data management section and consulted on the rest. A coherent Settings experience had to wait.

The group planned against the vision for about the next 18 months. Partner groups also planned to reuse pieces of our data admin workspace in their own tools.

Growing the team

I grew a senior designer into a lead. One of my senior designers wanted to move toward management, so I grew them into a design lead, the first step on that path in HubSpot’s career ladder, and hired an associate designer to work under them day to day. I stayed the associate’s manager for career coaching, so the new lead could practice managing without carrying it alone.

Outcomes

Shipped from both tracks. Parts of the vision reached customers 18 to 24 months after we wrote it. The vision set the direction; HubSpot’s teams built these:

• Committed track, carried forward by the vision: Sensitive Data ↗ for regulated industries, and sync properties ↗ that share values across records.
• Future track: AI data model recommendations ↗. Admins describe their business, and AI recommends the objects, properties, pipelines and associations to set up, which they can save as templates. In our 2024 vision this was a concept called “Gen-AI for configuration tasks.”

Early indicators, annualized, projected +19% user engagement and +14% data accuracy. These are projections, not measured results.

What I’d do differently

I’d have taken the vision across groups sooner. It solved the unseen misalignment inside my group, but the costliest misalignment lived between groups. I got there with the cross-group working group, but later than I should have.

What I carry forward: a vision succeeds when product adopts it as their own plan. I judge it by whether it shows up in their planning documents, not by how good the deck looks.