Dooly

Overview

Dooly had engineering momentum, product-market fit, and a scattered design practice. Designers were strong individual contributors embedded in product teams, but there were no shared patterns, no critique system, no leveling framework, and no design voice at the leadership table. Quality was happening because individual designers were grinding — not because anything about the organization made it repeatable.

The fix required two kinds of infrastructure. A design system that produced continuity in what got shipped. An operational layer — principles, critique, growth frameworks, planning rituals — that produced continuity in how decisions got made. Seven designers, four workstreams, one coherent product.

Role

Head of Design, Senior Leadership Team — Remote (Vancouver, BC) · 2021–2023

• Owned the full design function across Product and Marketing
• Built and managed a team of seven designers across four workstreams
• Designed and shipped the Dooly design system (Product Language)
• Established the Quality Bar — the principles, critique rituals, and growth framework
• Partnered with PM and Engineering leadership on roadmap and release planning
• Represented design at the SLT on company-level product and GTM decisions

Approach

Design System

Built a component library, pattern set, and token system authored against real product contexts — not abstract grids. Tokens governed color, type, spacing, and motion. Patterns for dense data surfaces, for configuration, for collaboration — each one designed with its specific product use case in hand. The system shipped alongside product work, not ahead of it, which meant adoption was never the question.

Impact: Seven designers shipped to four workstreams without the rework tax. Visual and interaction continuity stopped depending on any individual's taste. Engineers pulled from the system as readily as designers, because the components were precise enough to reference in code review.

View the design system →

Operations

Built the Quality Bar as three layers reinforcing each other, plus the alignment artifacts that made them stick. Design principles as decision-making tools. A structured critique format every designer used weekly. A growth framework that made leveling legible. A user journey map that gave PM, Engineering, and Design a shared reference. Work-back planning that pulled design upstream into scoping.

Impact: Design velocity and quality rose 30% once the Quality Bar was the team's working standard. Critique expanded into a cross-functional alignment surface PMs and Engineers attended. The user journey became the default reference in roadmap disputes.

View the operations framework →

Outcomes

• A seven-person design function supported four workstreams with continuous quality instead of sprint-by-sprint heroics
• The Quality Bar crossed out of the design team and into the company — PMs and Engineers quoted the principles in their own reviews
• The user journey became the default cross-team alignment artifact across Product, Engineering, and Design
• Design moved upstream in prioritization, contributing to what to build rather than only how it should look
• Design perspective shaped SLT decisions on product direction, positioning, and GTM

The User Journey Map

What it is. A single-page narrative map showing how Dooly's product connected from a user's perspective — a sales rep's week across the four workstreams. Not a detailed flow diagram. A picture the team could read from across a room.

How it's built. Hand-drafted first, then refined through 1:1s with leaders in Sales, CS, and PM. The structure followed the rep's actual day — morning prep, midday deal work, manager sync, next-day handoff. Each product stream mapped to the moments where the user actually touched it. The map stayed at one page intentionally; when it grew, it stopped being scannable.

What it feeds. Roadmap discussions started with "where on the journey does this sit?" instead of "whose team owns this?" Scope disputes got a shared reference — the user's experience, not the team's turf. GTM borrowed the structure for demo flow. Design critiques returned to it to check features against real moments in the rep's day.

One image. Multiple durable uses across functions. The artifact that made cross-team alignment cheap.

What I'd do differently

• Open critique to PM and Engineering from week one. The cross-functional value was obvious in hindsight. Gating it to designers for the first several months left leverage on the table.
• Build the user journey map in the first 60 days. Every project conversation would have been cheaper from the start. I delivered it mid-tenure.
• Tie the Quality Bar to product KPIs explicitly. Buy-in came, but slowly. Connecting bar-raising to adoption and activation would have accelerated cross-functional adoption.