Early User Experience

New users signed up for Dooly and left within the first 10 seconds.

Two onboarding redesigns and a handful of value prop experiments had already come and gone without moving anything. So the real question was never “how do we improve onboarding.” It was “why does nothing we try work?”

All of that was real, but none of it explained the 10 second drop off. That’s what I set out to figure out.

The primary user was the account executive, not the sales manager or leadership. Managers and leadership were the buyers, but the AE was the person in the product every day, and the one we needed to activate. If I’d designed for the buyer, I would have pulled the first run away from the person who actually had to get value from it.

Dooly’s three-year vision was a connected workspace that makes it effortless for revenue teams to share insight with the people and systems that need to know. This project was an early step toward that. If new users couldn’t even get their footing, none of the bigger vision mattered yet.

We landed on 180 seconds because that’s roughly how long a new user gives you. People decide pretty quickly whether a product is worth their time, usually within a couple of minutes, so that became our benchmark for showing value.

The goal wasn’t arbitrary either. It tied straight back to the business goal of driving user growth, which came down to one simple measure: did new users reach value within 180 seconds?

Under all of that was one question the team couldn’t agree on: was this a product market fit problem, or a UX problem? We’d tried different value props and activation hadn’t moved, so no one could say whether we weren’t offering enough value, were too hard to adopt, or were going after the wrong users.

Before I proposed any changes, I wanted to understand why activation kept resisting every fix. I looked at it from a few angles, and everything below comes out of what I found.

I also brought the team along as I went, engineers especially, since they rarely got face time with users. Rather than hand down conclusions, I invited them into the exploration and shared what I was learning, so we built a common understanding of the problem together.

I used IDEO’s Problem Mapping to break “busywork” into layers: the behaviours on the surface, the structures underneath them, and the mindsets under that. It showed how deeply the busywork was baked into the way sales teams are run and measured.

Focus and speed were the two strategic themes leadership had set. Meanwhile, AEs just kept saying “Salesforce sucks,” which you can’t really design against. I took their specific complaints and organized them under those two themes, which turned a vague gripe into something the team could actually understand and work on.

Not all of an AE’s work is the same. I split their day into maintenance, selling, and management work, and made the case that the fastest way to a first win was the maintenance work, the part we could actually own and deliver inside the first 180 seconds.

Two calls shaped the redesign before any screens: what the real problem was, and what to lead with.

The changes followed the two decisions: first, fixing the usability problems the audit surfaced, then leading with the painkiller through a faster first run.

AEs don’t only work in the browser. The pipeline and its views had to hold up in the Chrome extension and on mobile too, so the same starred views stay usable even on a narrow screen.

I tested a high fidelity Figma prototype with real AEs across nine remote, moderated sessions, internal and external reps, and used their feedback to refine the flow before anything got built.

To ship it, I worked closely with engineering to untangle the dependencies the changes created, mostly around the new navigation and removing the dashboard, which meant relocating that widget functionality elsewhere in the product. Engineering was involved throughout, so the handoff was a collaboration, not a toss over the wall.

Here’s the prototype itself. Click through it to get a feel for the new flow.

The scope was bigger than my authority could resolve in the time we had. Shifting the product’s identity inside a company proud of what it had built, and cautious about big swings, took more buy-in than any one role holds. I drove the vision and owned the strategy, and worked closely with a lot of people across the org to push it forward, but a change this size needed more decision making power than my role carried, and more time than we had, to fully land.

I collaborated a lot on this and pushed it a long way, but if I did it again, I’d raise the flag sooner. With the pressure to keep showing progress, I kept driving the work forward before I recognized that part of the problem needed a call from a higher level before I could take it further. I took that to my manager later than I should have, and catching that kind of blocker earlier is what I’d change.