The System
I designed a “conveyor belt” workflow that moved tickets through clear stages:
PM → Designer → Reviewer → Designer → PM
This allowed:
The PM to review and validate the request
The Designer to complete the work
A Reviewer (often the requester or a manager) to confirm accuracy
The Designer to make any required updates
The PM to do a final review
Since we didn’t have a dedicated QA team, I acted as the final checkpoint — making sure requests were clear upfront and that the final output was accurate and ready to ship.
I also provided design guidance when needed and deferred to our senior UI designer for higher-level UI decisions.
Sprint Adaptation
In 2024, I introduced a sprint-style system adapted to our actual needs. After researching common sprint models, I realized none of them fully supported a workflow with many small requests alongside a few larger, long-running ones.
I divided each month into two phases:
Requests due between the 1st–15th were assigned immediately or placed into the previous P2. Requests due later were bucketed accordingly. Larger projects, such as landing pages, were placed into an active sprint and carried forward as long as they were still in progress.
While this wasn’t a traditional sprint system, it worked extremely well. During December 2024 — a high-volume period when the team was understaffed — we were able to keep up with holiday demand without delays or burnout.
