How to tell whether your AI tools actually made the team faster
By Allan Leone on
The average designer's toolstack went from three to seven in a year, and nearly half of teams have not settled. Everyone reports feeling faster. Very few have measured whether the work moves through the studio quicker.
Ask designers whether AI tools improved their output and the answer is overwhelmingly yes. Ask how many tools they now use and the average went from three to seven in twelve months, with close to half still describing their setup as unsettled.
Both answers are honest. Together they describe a trap, because per-task speed and end-to-end delivery time are different measurements and only one of them shows up on an invoice.
Where the time goes back
Each tool is genuinely faster at its task. What each one also adds is a boundary, and boundaries are where the time reappears.
- Another place where work lives, which means another place to look when something is missing.
- An export step, and usually a manual one, because the two tools do not share a format.
- A sync problem when the client changes their mind, since the change now has to land in four places rather than one.
- A subscription and an access list, which is somebody's afternoon every quarter.
None of those are visible in a demo. All of them are visible in the gap between when a client asks for a change and when they see it.
The measurement that settles it
Per-task speed is easy to feel and easy to fool yourself about. The number worth tracking is cycle time on a change request: the client asks, and you measure until they can see it. Nothing else in the middle counts.
That figure exposes tool sprawl in a way that individual timings never will, because every boundary crossing lands inside it. If your per-task times all improved and cycle time did not move, the tools are fine and the seams are eating the gain.
One rule that has been worth more than any tool
Nothing new gets added unless it replaces something. Not complements. Replaces.
It sounds arbitrary and the effect is that every adoption decision has to name a victim. If nobody can say which existing step dies, the new tool is not a gain, it is a tab. That single constraint has killed more bad purchases for us than any evaluation matrix.
Where to start
- Measure cycle time on the next five change requests. Ask to see it, then look, and write down both timestamps. Five is enough to see a pattern.
- List every tool the team touched last week and mark which step of the work it owns. Two tools owning one step is where the sync tax lives.
- Apply the replacement rule to the next adoption. If nothing dies, do not add it.
- Re-measure cycle time a month after any change. Feeling faster is not evidence.
Tags: ai, process, tools