Skip to main content

Being a design team lead or manager can be a little daunting, to say the least. There’s so much that comes into play – your design capabilities, your organizational and planning skills, your management and communication abilities, your strategic skills, and probably some more that no one really knows about.

Design managers have a lot on their plate and there is always room for improvement. But sometimes, it can be difficult to see the next step among the clutter of all the tasks and responsibilities. One area to target is planning for budgeting and resourcing. These discussions can be difficult conversations for most all managers and leaders especially design leadership. It’s hard for multiple reasons.

First, nobody really prepares you for it. With engineering management, as an example, there is a need to have this resourcing conversation with the engineering team because their ability to deliver is critical to the ability of the organization to deliver. This is not always true for design, especially in enterprise.

Second, it is difficult because whatever budget you are asking for, someone else is making a case for why their budget ask is more timely or critical. This is true especially as you initially start to establish design thinking into the organization.

Over the past few years, I have had the opportunity to develop and build teams within multiple enterprise in-house teams, in part because of the work we’ve done to ensure the case for design resourcing is made and identified early in the process. Trust me we’ve made mistakes and the team tried different paths until we found the most reasonable and effective way to have this conversation. This is the guide I’ve developed to have these specific conversations.

---

What is Resource Planning?

Resource planning is a process of allocating tasks to human and non-human resources so that they’re maximized for efficiency. Resource planning helps team managers manage resource utilization and track resource capacity, to keep projects on track and on budget.
Resource planning helps you to organize your team so that they know exactly what projects they're working on. More importantly resource planning accurately tracks and manages your resource capacity to ensures that you're managing your team's time effectively and not burning anybody out.

---

Discover the Resourcing and Budgeting Cycles

Most big companies either agency or enterprise level do resource planning in cycles. Sometimes it is annual, bi-annual, or quarterly. Learn who is part of this conversation and what are the requirements to get you off to a good start. Your Finance/Product partners are a key to this. If you don’t know who they are, find them. Invite them for a quick chat and ask them to get a better understanding of how resourcing and budgeting works and what are the upcoming timelines for the next cycle.
The timing of your ask is critical to your ability to actually prepare in advance and ask within a time that the leadership is actually able to give you the resourcing you need to execute.

Focus on the Work

Now that you know the specific on why to focus on resourcing and how the funding cycle works, it is time to build the right relationships and get prepared.

If there is anything to take out of this post it is that your primary focus shouldn’t be on resourcing, it should be on the outcome/goals you’re trying to help the company achieve. What are we trying to achieve together as a cross-functional team and what is it going to take to achieve it?

"

Don’t just focus on resourcing, focus on the outcomes within your company”

This is not only important because it is the right thing to do, it is important because it shifts the tone of your role into business leadership instead of just design leadership. You want to be seen in the organization as a knowledgeable business and design leader not one or the other.

Depending on how your organization is structured, it is generally best to start working with the product leadership/owners – on the roadmap they have for the next quarter or year. As I have tried and failed through multiple iterations and cycles of this, we came up with a clear format for how to do this.

A screenshot showing a table highlighting the way resourcing asks are outlined. An explanation is available below.

We use this format to highlight the total resourcing need – based on the work outlined in the roadmap. This is not only highlighting the gap or the budget ask, it is highlighting the total number of design or researcher effort needed to execute on the roadmap as outlined by the product teams suggested on the PI (Program Increment – in an Agile workflow).

Let’s take a deeper look at each section:

One

Stories:

There are different stories or features we’re focused on within each product area. These stories are larger areas of focus and represent an end to end experience/interaction or a larger customer/client need within the Agile epics. Stories or features are generally highlighted in Rally or Confluence (depending on the team) so this would link to the scope to make sure we’re on the same.

Two

Initiative:

Within stories or features, we have initiatives that focus on a specific area, this also links to Rally or Confluence initiatives/epics depending on the team or where this request lives within our eco system.

Three

UX Needed:

This represents the number of designers needed to complete this initiative. The rule we set here is that designers are not focused on more than one or two projects at a time, depending on the size of the project. Rule – Only use increments of 0.25 which is a full designer’s time for a full quarter. ie (.25Q1 + .25Q2 + .25Q3 + .25Q4) = a full business fiscal year.

Four

Location:

Location could impact budgeting. We generally highlight a location when it is important for a designer to work closely with the engineering and product management team if those teams are located in a specific area or a time zone. But again, within our experience in working distributively location is not something that matters so much.

Five

Required Level:

For some projects, the designer’s level or experience matters. Level doesn’t have to correspond to a career ladder. It generally corresponds to the level of work required. For example, are you asking for a lead or a junior for this specific ask?

Six

Comments:

This is where some of the reasons and assumptions can be clearly outlined. As you discuss the scope of these initiatives, it’s important that you’re verifying assumptions or if this is a carry-over from previous asks etc.

Seven

Cross-functional Feedback:

This is designed to collect feedback on the worknot the resourcing asks. It is important that the focus of the comments is on clarifying scope, sharing thoughts and opinions on how design can be engaged, and to share any concerns around location, level of engagement, etc.

Eight

Totals:

This is simple math (rounding up).

Nine

Totals After Discussion with the Cross-functional Team:

You notice that the numbers are lower The reason is that after discussions with the cross functional teams, two of the initiatives you see listed were delayed or cancelled. Basically, the roadmap changed in the middle of resource planning which automatically changes the numbers. Which I’m sure you all have seen before.

Once you’ve done this across multiple Stories/features within the same product area, it’s now time to do the math.

A screenshot of a table showing the total numbers of designers needed and the gaps highlighted in need of additional budget.

This gives a complete picture of where we are as an organization. It is important that you are looking at this as a complete picture while also highlighting the gaps.

Let’s not Focus on the Ratios.

The number of UX staff you “need” depends on the needs of your product and organization. Ratios themselves might not be the right metric to determine how many UX designers/researcher vs. the number of developers you have on deck. Industry standards suggest that the most typical ratio in organizations is 1 dedicated designer for every 20 developers and 1 dedicated researcher for every 100 developers.

There is a fair amount of variation and some caveats with these ratios. Organizations seem to place more priority on UX designers over UX researchers. This data shows that in most cases an organization has at least 5 designers before there’s a dedicated researcher (the 1:5 ratio of researchers to designers).

1:5 ratio of researchers to designers

1:4 ratio designer:developer

Further research shows that 43% of companies have a 1:4 designer:developer ratio or better (largest 1:12). Optimizing for design is increasingly about mobilizing design correctly and less about having “enough” design resources.

So as mentioned previously, focusing on the ratios is relatively not important, when you solely do this it creates specific bottle necks:

Funding isn’t Always Equal

Just because a certain team is funded a particular way, doesn’t mean another team needs to be funded that way as well.
Forgetting to understand the full details of that funding, you are automatically linking your funding to an existing teams’ inefficiencies without articulating a case around the outcomes.

Ratios Focus on a “Unbalance”

It makes the case for design teams being underfunded in comparison to engineering but it’s unclear why that is an issue for the company and the ability to execute… hasn’t been an issue so thus far, right? They show there is an issue, but do not show what the issue is. For example, the ratio of HR to engineering is similar, is that an issue too? Why not?

The lessons learned here are that ratios and industry averages highlight an issue to the executive leadership team but don’t focus on them in real budgeting and resourcing conversations except with the goal of showing a relevant data point.

Additional Insights + Takeaways

Transparency and Focused Principles, at a 37K arial view help set the conversation.

Be transparent, ask for what you need, not your maybes or what you wished you had.
  • It is normal as you go through this process to ask for what you believe will be reasonable based on your understanding of the organization and available budget. Ask for what you really need to deliver quality work if you get the budget you asked for. Also, don’t ask for what you wish you had. Budgets are limited. This is not a wish list; it is a clear ask to achieve outcomes.
Don’t go too deep into the specific UX roles.
  • Depending on the structure of your team, you might have researchers, designers, or different verticals in design. If you do, don’t ask for resourcing separately per role, ask for the total number of “designers” you need then break up the budget you get in whatever way that helps you achieve your goals. Asking for different types of resources differently is confusing to colleagues outside of design. Once you have your budget, it is now your responsibility to decide how to best spend it to achieve the outlined outcomes.
Put together a set of principles for the discussion.
  • Before having a discussion with the cross-functional team, put together a clear set of principles that will help guide the conversation. Mine were somewhat simple:
  • Compromise on scope and timelines, not quality.
  • Discuss the work, not the number of designers needed.
  • Alignment is needed to deliver the scope of work, this is important to all of us. This isn’t just a design ask, rather it’s a cross-functional team experience.

The one push back you are likely to get looks something like this:

You walk your General Manager or finance lead through this and they’ll say:

"

You don’t need that many designers for this concept/initiative/product, you can do this with {X} amount of people less, I’ve seen it done before”.

"

This ask is for what has been determined to be the number of designers needed". -

Follow up can look like this:

– This based on the experience leading design in an enterprise organization like this and based on the set of processes and development work needed. Underfunding design in the cross-functional team risks our ability to deliver the quality of work and increases the risk of delivering work that might need developer re-work. The scope has been worked through closely with the PM and Development leadership so unless the scope has changed, this is the level of funding needed. I do fully understand if we don’t have the necessary budget and I am more than happy to discuss what level of work can be either de-scoped or delayed. Let’s figure this out together”.

This isn’t a one size fits all by no means but at least, it shifts the discussion in the right direction.

Thank you!

Overall, budgeting conversations are hard. You are not alone in feeling that way. That said, how you approach these conversations matter.
Resourcing is only a single part of the conversation as you move your organization's focus towards a one-experience led organization. The work you do in the background to build relationships,

work with the cross-functional teams, and advocate for design is the year-long work you also need to build the credibility needed as you have these discussions.

If you enjoyed this article then so will your friends, why not share it and all the rest of my articles be greedy it counts!

2 Comments

Leave a Reply