Producing screens quickly does not make a team fast. The real delays usually sit between decisions, reviews, and handovers.
I focus on shortening those gaps before increasing the volume of design work.
Start with open questions
At the beginning of a piece of work, I list what the team knows, what it assumes, and which decisions could block delivery. I add an owner to each open question.
This gives reviews a purpose. A session about journey structure should not turn into a detailed discussion about button labels.
Share work before it is polished
I review rough flows with product, engineering, content, operations, and control partners before creating detailed screens. Technical constraints and policy concerns appear while the work is still easy to change.
For smaller decisions, I share a short written recommendation with the options and trade-offs. People can comment asynchronously instead of waiting for another meeting.
Important decisions go into a simple log. It records the choice, the reason, the owner, and anything that could cause us to revisit it. This stops the team reopening the same conversation when someone new joins.
Keep design and build close
I involve engineers while interactions and states are being designed. During build, I review working software rather than waiting for a final design check.
We catch differences when they are still small. Empty states, errors, responsive behaviour, and content changes are discussed as part of delivery, not saved for the end.
The team moves faster because less work returns for another round. Speed comes from clearer decisions and earlier feedback, not rushed screens.