Planning Design Capacity for Changing Priorities
When priorities shifted, clear capacity planning helped the team make choices without overcommitting. Design capacity stayed at 85–90%, with allocation limited to two product areas where possible, and roadmap and resourcing decisions made visible to partners.
Sony Interactive Entertainment / PlayStation
UX Manager; capacity, roadmap, and scope planning
7–9 designers across several program areas
Monthly mobile releases and changing cross-functional requests
Design leadership, product, engineering, and program management
A delivery plan had to account for more than scheduled design
My team supported several product areas while new requests continued to arrive. Designers also had collaboration and follow-up work around their planned assignments. A plan that used every available hour left little room to respond when something changed.
I treated capacity planning as part of managing the work, alongside 1:1s, prioritization, risk tracking, and work-life balance check-ins. The purpose was to make commitments with a realistic view of the team’s availability and the decisions that would be required when priorities shifted.
This mattered for design leads as well. They needed room to focus on design direction, while resourcing and roadmap coordination still had to happen. I advocated for managers to take back more of that planning responsibility so leads had space to do the work of leading design.
Planning with room for work that emerged
I planned designers at 85–90% capacity rather than 100%. The remaining margin acknowledged that additional work would arise. It was a planning practice, not a measured increase in capacity or proof that every week stayed within the plan.
I also tried to keep designers on no more than two product areas. The aim was to limit how widely someone’s attention was spread while retaining flexibility across the program portfolio.
These rules made allocation more concrete. They gave me a basis for discussing whether a new request fit the current plan and what would need to change if it became a priority. Without that context, a small request could appear independent of all the other work assigned to the same person.
Making roadmap and resourcing decisions visible
I self-initiated roadmap and capacity planning, including prototyping an interactive roadmap view. I also worked with my manager on a resourcing and timeline document for a new resourcing manager.
The artifacts made the work discussable across roles. A roadmap connected initiatives to dates, while resourcing information connected those commitments to people’s availability. Together, they supported conversations about sequencing instead of treating each request as if it arrived in isolation.
When priorities changed, I re-sequenced six initiatives in about four hours. That is my estimate of a specific planning effort, not a benchmark for the team’s delivery speed. The useful result was a revised sequence that reflected the new priorities and the stages of design work involved.
Asking for priorities and deadlines before committing
I coached designers to ask about deadlines explicitly. A request could be in progress without being late, and a shared deadline was necessary before the team could judge whether it was at risk.
I also encouraged a deliberate response to new asks: take the request back to the team, consult the relevant people, and determine its priority. That gave designers a way to respond constructively while avoiding an immediate commitment made without the full workload in view.
I used documentation to keep scope decisions visible. In one instance, the team declined an unplanned project that did not fit the annual plan. The decision connected the request to the agreed work rather than treating availability as an individual designer’s problem to solve.
Working through a late request with partners
Before a teen-account strategy workshop, a new scenario arrived while two designers were already fully booked. My manager and I worked with product on the timing and scope of the request.
The situation required coordination on both sides. I advocated for a realistic response while holding designers accountable for clarifying deadlines and communicating what was in progress. The contribution was the management work around the commitment: making the existing load visible and addressing the request with the partners involved.
What the work established
The team had explicit capacity assumptions, a limit on the number of product areas assigned to a designer, and roadmap artifacts that supported prioritization. Scope and timing could be discussed in relation to an existing plan rather than negotiated through disconnected requests.
I do not claim that these practices reduced burnout, eliminated overtime, or increased delivery speed; those outcomes were not measured in the project record. My contribution was to make workload and tradeoffs visible, coordinate changes, and support more realistic commitments as priorities evolved.