Making Design Work Visible
Design work was invisible during planning and discovery. I had no data on how much time my team spent in discovery, and the same gap showed up in delivery: feature teams requested high-fidelity mockups whether a project needed them or not. So the question became: how do you make design work measurable without adding overhead to a team that’s already stretched?
My role: Initiative sponsor, tool design, team leadership
Outcome: The Estimation tool, a tool for designers to estimate design discovery and delivery needs so that designers can break design work into tasks and easily track in Jira.
The Problem
I had no reliable data on designer capacity or throughput. Designers didn't track their work in Jira, and feature teams didn't track product discovery work, so design effort was largely invisible during those phases.
A second problem made it worse: designers were being asked to over-design for the engineering hand-off. They delivered full-fidelity mockups for everything, including pages that could easily be assembled straight from design system components. That cost the team time we didn't have but nobody could see it.
The Insight
Design effort isn't driven by the size of a page. It's driven by how much the cross-functional team understands about the problem space. A well-understood problem built from existing design components requires very little design effort. An open-ended problem with many potential solutions needs exploration, iteration and user validation. And I needed to give teams a common language for estimating design work so the effort was understood.
The Solution
Working with Claude as a thinking partner, I built an estimation tool that let designers size any piece of design work across three phases: discovery, design delivery and design QA.
The tool asks three sets of questions:
Scope: is the team building an experience, a capability, a feature or a task?
Confidence: has the team built something like this before, how well do they understand the problem, and have they talked to users?
Risk: can the release be reversed, would customers forgive a misstep, and would it add work for support teams?
The answers place the project on a 2x2 of confidence against appetite for risk. Each quadrant gave the team a recommended path: discover first, prototype and test, experiment, or move straight into delivery.
The tool then estimated days for each phase. Discovery scales with certainty, so the more a team already understood about the problem space, the less discovery it needed. But scope still mattered. Even with high certainty, an end-to-end experience meant significant design effort overall. The tool also recommended the ideal set of design artifacts, ranging from full craft for a new experience down to a consult with no artifacts for a task built from design system components.
