Project Management for Design Projects

Story points were never built for this

Ask a designer to estimate a screen in story points and you'll get a number, and the number will be wrong in a specific way: it'll capture how long the making takes and miss almost entirely how long the deciding takes. A screen that took two hours to design can sit for two weeks waiting on a stakeholder's feedback, a second opinion, or a scheduling gap before the next review slot, and none of that waiting is effort, which is what story points were built to measure.

The honest bottleneck in most design work is the review cycle, not the craft. Round one comes back with three conflicting opinions. Round two resolves two of them and surfaces a fourth nobody raised before. By round four, the thing that's actually slow isn't the designer, it's the process of getting five people to agree on a direction, which a sprint board built for coding tasks was never going to make visible.

Then there's handoff, which has its own failure mode: a spec that looked finished in Figma turns out to be missing three states once an engineer actually tries to build it, and "design is done" quietly becomes untrue a week after everyone agreed it was.

None of this means design work is unmanageable. It means it needs to be managed against a different variable than engineering work is. Engineering's constraint is usually effort; design's is usually consensus, and a tool built only to track the first one will always underrepresent how design projects actually run late.

It also explains a specific complaint design leads make often and rarely get a good answer to: why the same team can ship a genuinely hard, technically demanding screen in two days and then spend two weeks on something visually simple. The simple one usually just has more people with opinions about it, and that's a fact about the organisation, not about the designer's speed.

Track the wait, not just the work

The fix isn't forcing design into engineering's estimation model. It's giving review cycles a place to actually live on the board, as a stage in its own right, with its own WIP limit, rather than folding "waiting for feedback" into a single generic "in progress" column where it's indistinguishable from active work.

Capping how many items can sit in review at once does something useful here: it surfaces when the actual bottleneck is stakeholder bandwidth, not designer output, a distinction that changes what you'd actually fix, and one that's usually invisible until someone counts.

Handoff gets the same treatment. A task doesn't leave design and land on engineering's board as a vague "ready." It moves with the states, edge cases and assets attached, and the GitHub sync means the branch built against it moves the card again on engineering's side, so the same item is tracked end to end instead of restarting as a new ticket the moment it crosses teams. Run on ShipSprint, that's the difference between a handoff and a re-brief: the engineer opens the card and the context is already there.

What actually shortens a review cycle

Adding more reviewers rarely speeds a review up, it usually slows it down, because more opinions means more conflicting feedback to reconcile before a direction can move forward. The teams that get through review cycles fastest tend to do the opposite: fewer required approvers, named explicitly, with a deadline attached to each round rather than an open invitation to comment whenever it's convenient.

A capped review stage forces this decision to actually get made, because an unbounded queue of "waiting on feedback" items makes the cost of an open-ended review process visible in a way a private inbox never does. Once a design lead can see three items stuck for the same reason, fixing the reviewer list becomes an obvious next step instead of a vague sense that reviews take too long.

The other lever is scoping what a round of feedback is actually for. A round meant to validate direction and a round meant to catch pixel-level detail are different reviews with different reviewers, and conflating them is a common reason a round that should take two days takes two weeks instead.

Async review compounds the problem when it's the default for everything. A comment thread that stretches across three time zones and four days produces a decision eventually, but usually a worse one than a fifteen-minute call would have, because nuance degrades fast in writing and nobody wants to be the person who reopens a debate that's technically already been "resolved" in a comment nobody fully agreed with.

What a clean handoff to engineering actually needs

• Every state a component can be in, empty, loading, error, attached to the task before it's marked ready, not discovered by the engineer building it
• The stakeholder who signed off named on the task, so "who approved this direction" isn't a memory exercise later
• A single review round with a deadline, rather than an open-ended thread that can technically stay open forever
• Assets and specs attached to the item itself, not a separate link that goes stale the moment the file gets renamed

None of it is about making design more like engineering. It's about making the parts of design work that already resemble a process, review, approval, handoff, visible enough to actually manage.

Where design meets the build it's feeding

Once a spec is handed off, the engineering side runs the way it does for any team: sprints, GitHub-synced cards, cycle time, covered in the software development use case. Design's board and engineering's board are different in shape by design, connected at exactly the point where the work actually crosses.

Design teams sit inside the same subscription as everyone else, with their own templates rather than a license bought separately from engineering's; see how the platform fits together across departments.