Latest Update:
Growth Manager

Most marketing teams do not have a design problem. They have a production problem.
Knak's 2026 survey of 333 enterprise marketing decision-makers found that 82% of teams spend at least half their time on production, meaning building, reviewing, approving, and sending, rather than on strategy or planning. In the same survey, 85% missed at least one campaign launch date in the previous twelve months. The single biggest reason was getting approvals and sign-off.
Read that again. The most common cause of a missed launch was not a designer running out of hours. It was a decision that nobody made on time.
That changes what "scaling design production" has to mean. It cannot just mean producing more assets. It has to mean building a system that turns finite creative capacity into finished, valuable work at a reliable pace. Hiring another designer will not fix an unclear queue. Buying another tool will not resolve contradictory feedback.
This guide covers creative and marketing design production: campaign assets, landing pages, sales collateral, product marketing work, social creative, and brand updates. It is not a guide to physical product manufacturing.
TL;DR
Scale the flow of finished work, not the number of requests you accept. An overflowing queue hides priorities and creates more waiting.
Give every request one owner, one decision maker, a clear audience and outcome, and an agreed definition of done before production starts.
Reuse approved foundations such as brand rules, components, templates, and source files, but govern them so reuse improves quality instead of spreading errors.
Protect throughput with work-in-progress limits and explicit review rules. A repeated bottleneck is a signal to fix the system, not a reason to ask designers to work faster.
Measure lead time, approval latency, rework, on-time readiness, and reuse alongside output. Volume alone rewards low-value work and hides quality loss.
What scaling design production actually means
Design production is the work of turning a business need into a launch-ready creative asset. It starts before a designer opens a file. It ends after the asset is approved, exported in the right formats, and available to the people who need it.
Scaling design production means increasing the amount of valuable, on-brand work you finish reliably as demand grows. It does not mean making more assets for their own sake.
A team can double its social output and still fail. Important launches wait behind low-value requests. Stakeholders reopen settled decisions late. Designers rebuild work that already exists. Output went up. Impact did not.
The goal is dependable flow. The right work reaches done at a sustainable pace.
How this relates to creative operations and DesignOps
You will see three terms used for overlapping problems. They are not identical, and knowing the difference helps you pick the right fix.
Design production is the pipeline itself. Request, brief, create, review, approve, produce, deliver.
Creative operations is the wider practice of running that pipeline across a marketing organization. It covers intake, prioritization, resourcing, asset management, and reporting. Marketing and brand teams usually use this term.
DesignOps is the same idea with roots in product and UX teams. Nielsen Norman Group's Kate Kaplan defines it as "the orchestration and optimization of people, processes, and craft in order to amplify design's value and impact at scale." Her summary of the underlying problem is blunter: designers are often too busy to design.
Kaplan draws a useful distinction between DesignOps the Role and DesignOps the Mindset. The role means hiring a design program manager or a production lead. The mindset means agreeing on standard processes and tools without hiring anyone.
You almost certainly need the mindset. Most growth-stage marketing teams do not yet need the role. The five loops below are the mindset version, sized for a team that cannot dedicate a headcount to running itself.
What makes a design scalable
Scaling the process is one thing. Making individual design work scalable is a separate problem, and teams often skip it.
A scalable design adapts to new contexts without being rebuilt. Four properties make that possible.
It is modular. The work is assembled from reusable parts such as components, sections, layouts, and type scales. Changing one part does not require redrawing the whole thing.
It is documented. Someone who did not create it can apply it correctly. Documentation covers what the element is for, what may change, and what must not.
It is adaptive. The design holds up across screen sizes, formats, aspect ratios, and channels. A hero layout that only works at one width is not scalable, however good it looks.
It is governed. One named person owns it, versions are visible, and there is a route for changes. Without ownership, a component library becomes a folder of guesses within two quarters.
Note what is not on that list: complexity. A scalable design is usually simpler than the one it replaces, because every extra variable multiplies across every future use.
Why design production breaks as a company grows
Early teams cover for missing process with proximity. A founder clarifies a request in a Slack thread. The designer knows where every file lives. Three people make an informal decision in a hallway.
Growth removes those shortcuts. Demand expands across channels, audiences, products, formats, markets, and stakeholder groups. Most breakdowns then happen at the handoffs, not in the craft.
Airbnb's design team tripled in fifteen months. Adrian Cleave, the design director who built its DesignOps function, described the result as reaching a tipping point where things suddenly became harder. His list of what broke is worth quoting because it is so ordinary: access to information, design standards, workstream collisions, and quality issues. None of those is a talent problem. He wrote that account in 2016, so treat the structural detail as historical and the pattern as current.
Superside's Overcommitted report, a December 2024 survey of 206 enterprise creative leaders run by Regina Corso Consulting, found that more than three quarters of leaders say creative demand is higher than their capacity to deliver. It also found that 96% believe their team has the skills to complete its projects. The capability is there. The system around it is not.
Superside sells creative services, so read its framing with that in mind. The finding still matches what Airbnb described from the inside.
Here are the five failure modes that show up most often, and where to start on each.
Failure mode | What it looks like | First fix |
|---|---|---|
Unqualified demand | Everything is urgent. The loudest request wins. | One intake path plus a regular prioritization decision. |
Ambiguous brief | Designers infer the audience, the offer, and the constraints. | Require a short brief before work starts. |
Too much active work | Dozens of files are in progress. Few are ready to launch. | Set work-in-progress limits. Finish or unblock before starting. |
Review by committee | Feedback arrives late, conflicts, or reopens settled decisions. | Name one decision owner and write review criteria. |
Reinvented assets | Familiar layouts and formats get rebuilt from scratch. | Maintain a searchable, approved production library. |
Treat these as system failures. None of them is evidence that individual designers need to work faster.
If you are not sure which one you have, diagnose before you build. Our guide to finding your real creative bottleneck walks through mapping recent requests stage by stage.
The six steps to scale design production
Before the framework, here is the sequence. Run these in order. Each one makes the next easier.
Map ten completed requests from first ask to launch. Record when each stage started and ended. Mark the longest wait.
Create one intake path with a required brief. Everything enters the same way, and incomplete requests sit in a "needs brief" state.
Name one priority owner and set a recurring prioritization decision. Someone chooses what matters most, on a schedule.
Set a work-in-progress limit for the stage where work piles up. When the limit is hit, the team finishes, unblocks, or defers.
Standardize your three most repeated asset patterns into governed templates. Retire the duplicates.
Measure lead time, approval latency, and rework for one month. Change one thing based on what you see, then repeat.
Steps one through four cost nothing but decisions. Step five costs real build time. Step six is what stops the whole effort from becoming a one-off cleanup.
The five-loop operating system
You do not need a large creative operations program to start. You do need five explicit loops.
A loop is a repeating cycle with a named owner and a defined output. There are five because design production fails in five distinct places: getting work in, choosing what matters, making it, judging it, and improving how you do all four. If one loop is missing, adding capacity usually just moves the bottleneck somewhere else.
[VISUAL 1: five-loop operating-system diagram. Alt text: "The five loops of design production: demand, decision, production, quality, and learning, arranged as a cycle."]
1. Demand: turn requests into comparable work
This loop decides what enters production and in what condition.
Every request should arrive through one visible path. That path can be Slack, a project tool, email, or a form. The tool matters far less than the information and the ownership attached to the request.
Require only what production actually needs:
Business objective and audience
Deliverable, channel, and required formats
Approved source material, offer, and constraints
Deadline, and the event that makes the deadline real
Request owner and final approver
Keep incomplete requests in a "needs brief" or "blocked" state rather than starting them. This makes the real constraint visible. A designer should not have to turn half a sentence into a launch asset.
One warning about intake forms. A form does not fix an unclear owner. If nobody can name the approver before work starts, you do not have a brief. You have a request.
2. Decision: make trade-offs before production starts
This loop decides what the team works on next, and it is where most teams lose the most time.
Superside's survey found that creative teams are told an average of 55% of their projects are high priority. And 35% of the time, that pressure comes directly from executives. When more than half of everything is urgent, nothing is, and the queue gets sorted by whoever asked most recently.
Design capacity is a budget. Spending it on one thing means not spending it on another. If leaders do not choose, the production team inherits the conflict. It arrives as constant context switching.
Run a short recurring prioritization review. Compare requests on five things:
Expected impact
Time sensitivity, and what makes the date real
Confidence in the brief
Effort, and whether a specialist is required
Whether the work unlocks another initiative
A score makes trade-offs visible. It is not objective truth. A leader still owns the call.
For complex launches, approve the core message and visual direction before producing every derivative. Changing one landing page story is cheap. Changing a campaign's ads, deck, email, and social formats after production has started is not.
3. Production: make repeatable work truly repeatable
This loop decides what gets built from scratch and what gets assembled from approved parts.
Scaling does not mean templating every decision. It means preserving the approved answer to problems that keep recurring.
A production library might hold brand rules, common layouts and UI patterns, campaign format sets, approved proof points and disclaimers, source file conventions, and export presets.
A folder of old templates is not a system. People need to know four things about every asset in it: when to use it, what may change, who owns it, and where the latest version lives.
That is the principle behind mature design systems. The GOV.UK Design System assesses every proposed contribution for whether it is useful, consistent, versatile, and backed by evidence of usability. A startup does not need that level of governance. It does need a named owner and clear usage rules.
Start with the three things your team recreates most often. Prove that people can find, use, and maintain a small library before you expand it.
4. Quality: design the review, not just the asset
This loop decides how work gets judged and by whom. It is usually the hidden production line.
Remember the Knak finding: approvals and sign-off were the single biggest reason teams missed launches. Review is not overhead around the real work. For most teams it is the constraint.
Define four things for each type of work.
Review moment. What gets reviewed at concept, at draft, and at final?
Decision owner. Who consolidates the feedback and makes the binding call?
Review criteria. Does the work meet the audience, message, accuracy, brand, accessibility, and channel requirements?
Response window. When is feedback due, and what happens when it is late?
The designer should receive one consolidated direction. Not six incompatible comment threads.
Your definition of done should also cover final copy, exports and handoff, link and tracking checks, source file storage, and launch readiness. "Approved" is not always "ready to publish."
5. Learning: feed friction back into the system
This loop decides what changes next time. Skip it and the other four loops stay frozen at version one.
After a campaign or a cluster of requests, ask two questions. Did the work achieve its business purpose? Did the production system help or hinder the team?
If work launched late, trace the delay to a stage. Was the request late? Was the copy unstable? Was the final decision unresolved? Was the reviewer unavailable?
Then turn the answer into something durable: a better intake prompt, a new template, a checklist, a revised lead time, or an approval rule. That is how a system compounds instead of resetting.
Where AI actually helps, and where it does not
AI is now standard in marketing production, and it has not fixed the queue. Knak found that 70% of teams have deployed AI in their production workflow. In the same survey, 85% still missed a launch date. Only 29% describe their adoption as advanced, with AI embedded across the whole workflow rather than just at the drafting stage.
The reason is structural. AI compresses the stages that were already fast. It leaves the slow ones alone.
Two more numbers explain it. 64% of teams use AI to generate first-draft email or landing page copy, which is the cheap end of production. And 88% say AI output needs moderate or substantial editing before it is usable. So AI does not remove the work. It converts producing into reviewing. Review was already your bottleneck.
Where AI earns its place
Point it at work with reliable inputs and cheap verification.
Resizing and format adaptation across channels
First-pass localization and translation drafts
Background removal, object variants, and image cleanup
Alt text, asset tagging, and search inside your production library
Turning a call recording or a messy brief into a structured first draft
Video cutdowns and transcription
Where it backfires
Concept generation when review is your constraint. Forty ad variants is easy. Deciding which four to run, and getting them approved, was the slow part.
Anything brand-critical where checking costs more than making. If a human has to verify every pixel against brand rules, you added a queue.
Work with unreliable inputs. A vague brief produces vague output, faster.
One test before you point AI at a stage: if this stage got twice as fast tomorrow, would more useful work reach the market? If not, you found an annoyance, not the constraint.
Worth noting for your capacity planning: the US Bureau of Labor Statistics now cites automated design tools, including AI, as a factor that may reduce demand for freelance graphic designers. It projects 2% employment growth for graphic designers from 2024 to 2034, slower than the 3% average across all occupations.
Tools for each loop
The tool matters less than the information and the ownership. That said, "figure out your process first" is not an answer when you need to pick something on Monday.
Here is a working stack mapped to the five loops.
Loop | What you need it to do | Common options |
|---|---|---|
Demand | One visible queue, required fields, clear states | Asana, Linear, Notion, Jira, ClickUp, Trello |
Decision | Priority view, capacity picture, recurring review | Same tool as intake, plus a simple scoring sheet |
Production | Components, shared libraries, version history | Figma, Adobe Creative Cloud Libraries, Canva for templated work |
Quality | One review surface, threaded comments, approval record | Figma comments, Frame.io for video, Filestage, Ziflow |
Production library | Search, permissions, latest-version clarity | Brandfolder, Bynder, Frontify, or Drive with enforced conventions |
Learning | Cycle time and stage duration exports | Whatever your project tool reports, plus a spreadsheet |
Two cautions. Do not run intake in one tool and priority in another, because the two views will disagree within a week. And do not buy a digital asset manager before you have anything worth managing. Enforced folder conventions in Drive will carry a team of ten further than most people expect.
Control work in progress before adding headcount
When every request is active, the team looks busy and work moves slowly.
Each new task adds a file, a context, a dependency, and another chance to be interrupted. The visible cost is a longer queue. The hidden cost is less protected time to finish anything.
Set work-in-progress limits for the stages where work gets stuck. Active concepts per designer. Items waiting for review. Requests in production at once.
A work-in-progress limit is not a productivity target. It forces a choice: finish, unblock, defer, or explicitly add capacity.
[VISUAL 2: WIP bottleneck diagram. Alt text: "A design workflow with queue depth shown at each stage and the approval stage highlighted as the constraint."]
Repeated breaches tell you where to look.
A full "waiting for approval" column means decision latency, not a design capacity problem.
A congested specialist stage means you need earlier sequencing, backup skills, or a different request mix.
One large job blocking the queue means you need a direction-setting milestone and smaller production batches.
Kanban guidance describes work-in-progress limits as a way to expose bottlenecks and focus attention on completion. Atlassian's explanation is a good primer on the principle, though a design workflow needs different stages than a software one.
The research case for protecting focus is real but narrower than it is usually presented. A controlled 48-person experiment by Mark, Gudith, and Klocke interrupted participants every two minutes while they handled email. The interruptions did not produce more errors. After twenty minutes, participants reported significantly higher stress, frustration, time pressure, and effort. That was a lab study of mostly university students, not a design team, so it cannot set a staffing benchmark. What it shows is that apparent output and a healthy production system are different things.
Warning signs the system is burning out the team
Burnout is not a soft concern here. It is a leading indicator that your production system is broken, and it shows up before the metrics do.
Superside's survey found that 76% of creative leaders say they and their teams felt burned out by their workload over the past year. Two in five say their team is understaffed. And 79% say they want to create bolder work but are always racing against the clock.
The most useful finding is this one: 70% of leaders say many of their most talented designers are working on tasks below their skill level. That is not a motivation problem. It is a routing problem.
Here are the signals worth watching, and which loop each one points to.
Signal | Likely loop at fault |
|---|---|
Senior designers spend most of their week on resizes and exports | Production. Repeatable work is not templated or routed separately. |
Everything is urgent and nobody can say what got deprioritized | Decision. No priority owner, no recurring trade-off. |
The same project returns for a fourth and fifth revision round | Demand and Quality. Weak brief, or unclear decision rights. |
Designers spend more time waiting for answers than designing | Quality. No response windows, no named approver. |
The team is visibly busy and shipping less than last quarter | Work in progress. Too much active, not enough finished. |
Strategic brand work never gets done | Decision. Work without an external deadline always loses. |
Three or more of these means the problem is structural. Asking people to try harder inside a broken sequence makes it worse.
One structural fix helps more than any wellbeing initiative: route low-risk production work away from the people doing high-judgment work. A resize and a brand system should not compete in the same queue, because the resize always has the closer deadline.
Choose capacity based on the work
There is no universally best way to staff design production. Choose the model that supplies the right blend of context, specialist skill, control, and flexibility for your demand pattern.
[VISUAL 3: capacity-model decision matrix. Alt text: "Five design capacity models compared by demand predictability and required product context."]
Model | Strong fit | Trade-off to manage | Cost shape |
|---|---|---|---|
In-house team | Deep context and ongoing strategic work | Fixed cost, plus uneven specialist coverage when demand fluctuates | Salary plus benefits, payroll taxes, software, and equipment. Fixed regardless of demand. |
Freelance specialists | Defined expert work or short gaps | Briefing, availability, and continuity all create management work | Hourly or per-project. Variable, but rates rise for scarce specialisms. |
Agency | Major launches or defined multidisciplinary engagements | Handoffs and knowledge transfer need active planning | Project fees or retainer, usually with a minimum engagement. |
Subscription or managed production partner | Ongoing varied demand needing flexible external capacity | Queue rules and quality expectations must be clear upfront | Flat monthly. Predictable, but underused months still cost full price. |
Hybrid | Core strategy in-house plus elastic production capacity | Ownership must be explicit or you get contradictory direction | Combined. Cheapest per unit of useful work if routing is clear. |
For the in-house baseline, the Bureau of Labor Statistics reports a median annual wage of $61,300 for graphic designers as of May 2024, with the lowest 10% under $37,600 and the highest 10% above $103,030. Total employer cost runs meaningfully higher once benefits, payroll taxes, software licences, and equipment are included. Senior, specialist, and major-metro roles sit well above the median. Treat the median as a floor for planning, not a budget.
Get current quotes for the other four models. Rates move, and any number published in an article is out of date by the time you read it.
Before you change your team, answer four questions.
Is demand predictable or spiky?
Is the bottleneck strategic judgement, specialist craft, routine adaptation, or approvals?
How much product context must the creator hold?
Who owns the final decision?
More people will not solve slow approvals or unstable strategy. Superside's data makes the point from the other direction: 41% of enterprises work with traditional agencies, and of those, only 13% say the partnership is going well. External capacity still needs a usable brief, a priority decision, and an accountable owner.
If your answer to those four questions points at capacity or a specialist gap rather than a process problem, Zyner supplies senior design capacity with a dedicated project manager and a one-active-request queue. Book a call if it would help to talk through your demand pattern.
The brief template and definition of done
Two artifacts do more for production throughput than any tool. Copy them.
Request brief
If a field is empty, the request stays in "needs brief." That rule is the whole point. Without it, the template is decoration.
Definition of done
Most teams have an implicit version of the first list and no version of the second. That gap is why approved work still misses launches.
Measure the health of the system, not asset volume
"Assets delivered" is easy to count and easy to game. Use a small scorecard that connects flow, quality, and business readiness instead.
Metric | What it reveals |
|---|---|
Lead time | Whether delivery is becoming more predictable |
Active work in progress | Overcommitment and context switching |
Approval latency | Hidden management bottlenecks |
Rework rate | Weak briefs, changed strategy, or unclear decision rights |
On-time readiness | Whether work is ready before the real launch deadline |
Reuse rate | Whether the production library is useful and trusted |
Define each measure before you collect it. Decide whether lead time starts at first request or when the brief is complete, and stick to it.
Keep "time blocked by requester" as a separate number. Otherwise the production team gets blamed for missing inputs it never controlled.
Compare each type of work against its own history. A complex landing page and a resized ad do not belong in the same average.
Only 43% of the creative teams in Monotype's survey of more than 1,000 creative professionals track creative return on investment per project. That same research found 57% spend more than a quarter of their time on non-creative tasks. If you are not measuring where the time goes, that quarter stays invisible.
Monotype sells font management software and the full report is gated, so these figures come from its public summary rather than a published methodology.
What Zyner's operating model adds to the discussion
Zyner is a design subscription service for startups. It pairs senior design talent with a dedicated project manager. Work is requested and managed through Slack, with an ongoing queue and one active request at a time.
That model is not the right fit for every team. It is useful here because of what the constraint does.
When everything can be active at once, adding an urgent request appears to cost nothing. Nobody can point to what slowed down, because everything slowed down slightly. With a limit of one active request, an urgent request means naming what it displaces. That conversation happens before the work starts rather than after a deadline slips.
The dedicated project manager matters for the same reason. Coordination is real work. When nobody owns it, it gets done by whoever notices, which usually means a senior designer doing it badly between other tasks.
The transferable lesson is broader than any one provider. Creative judgement, request coordination, and capacity each need an explicit owner. Design production does not scale while all three are somebody's side responsibility.
A practical 30-day plan
You can improve a design production system without launching a process project.
[VISUAL 4: four-week implementation roadmap. Alt text: "A four-week plan to scale design production: map, make visible, standardize, then review."]
Week | Action | Outcome |
|---|---|---|
1 | Map ten completed requests from ask to launch. Mark the longest wait. | You know the real constraint. |
2 | Add one intake path, a visible queue, clear states, a named approver, and one conservative work-in-progress limit. | Work and waiting become visible. |
3 | Standardize the three most repeated asset patterns. Retire duplicate templates. | Routine production takes less effort. |
4 | Review lead time, work in progress, approval latency, and major rework. Make one targeted change. | You improve on evidence, not assumptions. |
Give one person ownership of the mapping in week one. Splitting it across the team produces five different interpretations of when "work started" and no comparable data.
Two mistakes to avoid. Do not treat the queue as a promise to start every request immediately. And do not automate a broken handoff, because a form will not fix an unclear owner and a new tool will not resolve contradictory feedback.
One note on timelines. Weeks one through three are rules and build work, and they land quickly. Changing who is allowed to approve what takes a quarter or more, because it touches trust and job definitions. Start the quick changes now, but do not declare victory in week four if your map pointed at approvals.
Frequently asked questions
When should a company formalize design production?
Start when requests compete for the same people, when work crosses teams, or when late approvals and repeated work begin affecting launches. You do not need a large design organization. You need enough recurring complexity that informal coordination no longer delivers reliably.
Does scaling design production mean building a design system?
Not necessarily. Product teams may need a full design system. Marketing and creative teams usually need a lighter production library: brand rules, approved messaging, templates, file conventions, and format sets. Build the smallest reusable layer that solves a repeated problem, then expand only when people are actually using it.
What is the difference between a design system and a production library?
A design system governs a product interface. It contains coded components, interaction patterns, accessibility rules, and versioned documentation, and engineers consume it directly. A production library serves marketing output. It contains brand rules, campaign format sets, layouts, approved proof points, and export presets, and designers consume it. Both need a named owner. The design system needs far more governance.
Should you hire more designers or improve the process first?
Inspect the constraint first. Add capacity when there is clearly more ready, prioritized work than the team can produce. Improve the system when the real issue is slow approvals, incomplete briefs, unstable strategy, or missing reusable assets. Knak found approvals to be the single biggest cause of missed launches, which means process is the more likely answer. Often you need both, in that order.
How many designers does a marketing team need?
There is no ratio worth trusting, because the answer depends on demand mix rather than company size. A team producing ten templated social variants a week needs different capacity than one producing a website, a rebrand, and a conference booth. Count ready, prioritized requests per week and compare that against how many comparable requests you currently finish per week. The gap is your capacity question. If there is no gap and work is still late, the problem is upstream of production.
How do you measure design team productivity?
Measure the system, not the individuals. Lead time, approval latency, rework rate, on-time readiness, and reuse rate tell you where the process loses time. Asset counts and utilization rates reward volume over value and push teams toward low-impact work. Keep time blocked by the requester as a separate figure so production is not held responsible for missing inputs.
Can AI scale design production?
It can scale parts of it. AI works well on format adaptation, first-pass localization, asset tagging, and turning rough inputs into structured drafts, because those tasks have reliable inputs and are cheap to check. It does not help when review and approval are your constraint. Knak found 70% of teams have AI in production and 85% still missed a launch, and 88% say AI output still needs moderate or substantial editing.
Should you hire a DesignOps person?
Usually not at growth stage. Nielsen Norman Group distinguishes DesignOps the Role from DesignOps the Mindset, and most marketing teams under about fifteen creatives get what they need from the mindset: one intake path, a named priority owner, a governed library, and explicit review rules. Consider the role when coordination alone occupies more than half of a senior person's week, or when design work spans several teams with conflicting priorities.
How long does it take to fix design production?
It depends entirely on which fix. A work-in-progress limit is a rule and lands in days. One intake queue with a named priority owner takes a week or two. A definition of ready takes two to four weeks, because requesters have to agree to it. Templates and component systems take four to eight weeks of real build effort. Changing who approves what takes a quarter or more, because it touches politics and job definitions.



