Docs / People / Program management
<DesignProgramManager />
Warren Velázquez, for Staff Design Program Manager, Design Systems on UX Foundations at Etsy.2 A design system rarely fails at build. It fails at adoption, and adoption is an operations problem: what enters the queue, how it gets ranked, when it ships relative to product, and whether anyone can tell what changed. That is the job I have been doing under other titles for thirteen years.
This page is written as documentation because that is the artifact the role produces. Collage already has a Design Systems team and a Content Design team doing the craft.1 What I would bring is the operating layer around them: a backlog that is granular enough to act on, prioritization anyone can predict, a release rhythm that matches product, and reporting that makes the work legible to people who will never open Figma.
// usage import { DesignProgramManager } from 'warren.digital' <DesignProgramManager team="UX Foundations" supports={['Design Systems', 'Content Design']} mode="working leader" // strategy and the ticket queue, same week shields={true} // intake is mine so focus is theirs onAmbiguity={(req) => rank(req)} // published weights, not a negotiation reportsTo="Director, Design Program Management" />
API reference
Props, and the proof behind each one
Every prop below is a line from the posting. The evidence column is work I have actually done, with the program named so it can be checked. Two rows are marked partial on purpose.
| Prop | What the posting asks for | Evidence | Fit |
|---|---|---|---|
| shieldTeam (intake) => ProtectedRoadmap |
Architect team stability. Streamline intake, keep the roadmap realistic and protected. | At Dow Jones six teams send me quarterly plans and requests in six different spreadsheet formats, incomplete and inconsistent. I built Relay to absorb that and return one resourced plan, then hand it to Asana through the API so nothing is retyped. The teams never touch it. I am its only user,4 which is the honest version and also the point: the mess stops at me. | met |
| backlog Item[] => Sprint |
Drive the end to end lifecycle of the Design System and Content Design backlogs. Granular, actionable, aligned to quarterly goals. | I own the Asana implementation for a brand marketing team at Dow Jones: reporting, capacity and resource management across roughly eight events and five launches in the past five months. Planning happens upstream in Relay, execution happens in Asana, and the seam between them is deliberate. A tracker should never get to decide how work is planned. | met |
| prioritization Weights => RankedQueue |
Establish and socialize clear, observable principles. Balance urgent fixes against foundational builds. | A worked model is on this page: four lenses, published weights, and the two items that never resolve inside the model. Observable means someone else can run it without me in the room and get the same answer. | met |
| cadences Ritual[] => Flow |
High signal, low friction rhythms. Standups, retros, crits that improve flow and decision quality. | At Everyrealm I introduced the standups, crits and retros into a team I had just hired. A new team owes you no attendance, so every ceremony had to earn its slot on signal per minute, and the ones that stopped earning it got cut, including mine. On APS the review cadence was built to catch drift at implementation rather than at QA. | met |
| orgIntegration Core <=> Local |
Orchestrate how product teams interact with UX Foundations. Consistency without bottlenecks. | Moving Brands / NYU Langone: I ran the UX and IA audit on a design system that was good and still being worked around. Naming, findability and local overrides are where that shows up. My contract for core versus local is on this page, including the exception path, because a governance model with no exception path is just a queue of people asking for exceptions. | met |
| releaseSync SystemRelease ~ ProductRelease |
Ensure system updates are synchronized with product release cycles. | Google, Android pod: one launch calendar across android.com, tv.google and wearos.google.com, three properties that shared components but not release dates, including the Android 12 launch. That is the same coupling problem a design system has with every product team it serves. | met |
| contentDesign Scaffolding |
Build the operational framework for Content Design. Backlog, capacity deployment, integration into design reviews. | At Dow Jones I resource my team and oversee design, content design and copy from a brand standpoint. My team owns the brand guidelines and is wrapping up refinements to a visual system that will feed a brand hub, which has not shipped yet. The honest edge: I oversee and resource content design, I have not run a dedicated Content Design function or owned its craft ladder. | met |
| visibility Audience => Artifact |
Streamlined, audience appropriate reporting. Dashboards, newsletters, executive summaries. | GE Healthcare: I built the executive level visualizations for the asset production phase of the global Better Health Study, one of GE's largest campaigns, which is what kept leadership aligned on a cadence while hundreds of assets moved underneath. Three audiences, three artifacts is how I would set it up here. | met |
| vendors Agency[] => Standard |
Operational lead for design agencies or vendors. External work meets the standard and integrates cleanly. | The Row at Everyrealm: I owned the Monaverse vendor relationship through implementation and platform testing to a single coordinated launch, plus external motion, 3D rendering and video vendors. I have also spent years on the agency side, at Huge, Vertic, POSSIBLE and Beyond, so I know how a scope gets written to be gameable. | met |
| designToCode participate, not lead |
Partner with Engineering Ops and Brand Design. Participate in technical discussions on the design to code pipeline. | Closest real experience: stewarding the Arizona Public Service design system into production with Infosys and 28+ engineers, and the current migration of eight properties onto one system. I can hold a token and component API conversation and I can tell when an estimate is a guess. I am not an engineer and would not pretend the depth is there. The posting says participate rather than lead, which is the accurate line. | partial |
| scale multiPlatform |
A mature system serving buyer and seller experiences across platforms. | My systems work has been web and brand surfaces: eight event and conference properties into one at Dow Jones (six of eight migrated, build time cut about 80 percent),3 a transactional .com and mobile app system at APS, an audit at NYU Langone. Native iOS and Android at marketplace scale is new to me. | partial |
| orgWide Program[] |
Lead occasional org wide programs with the Director of Design Program Management. | Everyrealm: a creative operations function and its team built from zero, across 12 platforms, working with finance, architecture, product, marketing and engineering with no playbook. Org wide programs are the shape of work I like most, and the one I would want to earn rather than assume in month one. | met |
Fit marks are mine, not Etsy's. Two partials is the honest count, and I would rather you read them here than find them in an interview.
Foundations
Operating tokens
A design system has color, spacing and type tokens: named decisions, defined once, referenced everywhere. An operating model has them too, and most teams leave them undefined, which is why the same argument gets rehearsed every quarter. These are mine. Each one is a decision I have actually made somewhere, with the program that taught it to me.
Components
Evidence library
Nine pieces of work, documented the way components are: what it is, the status, and what it proves for this role. Open one for the detail and the fit.
Patterns
Prioritization logic, made observable
The posting asks for clear, observable principles that balance urgent fixes against foundational builds. Here is what I mean by observable: the weights are written down, anyone can run them without me, and the same request gets the same answer on a Tuesday as it does the day before a launch. Pick a lens and watch the queue reorder.
Design System and Content Design backlog, ranked
Eight representative items.5 The lens is the argument a team is actually having when it argues about priority. Naming the lens ends the argument faster than debating the items.
On this lens:
Two items never resolve inside the model. A dated partner launch and a cross platform token change both need a conversation, not a score. The model's job is to make sure everything else does not need one, so the conversations you do have are the ones worth having.
The items and their dimension scores are illustrative, written by me to show the model. I have no access to Etsy's backlog. The model is the artifact here, not the data.
Patterns
One request, from intake to adoption
End to end lifecycle is the phrase in the posting. This is what I mean by it, walked one stage at a time, with the record on the right filling in as the request moves. Note where content design enters, and note the field that stays null until it does.
Proposed
A product team says they need something. What arrives is almost never a component request, it is a problem with a solution already attached to it. The intake asks for the problem, the surface, the date pressure and who is blocked, and it takes under five minutes to fill in.
- One door, published response time, no side channel that quietly works better.
- Date pressure is captured as a fact, not as an argument to be relitigated later.
Triage
Before anything gets built, the question is whether it already exists. Six local overrides of a card in three surfaces is not six requests, it is one unfiled bug report about the original component's API.
- Duplicate and override check first. This is where most of the backlog quietly disappears.
- Decision recorded either way, so the next team asking gets an answer instead of a queue slot.
Spec
Definition of ready. States, props, accessibility target, and the surfaces it has to hold on. If a spec cannot answer what happens when the thing fails, it is not ready, and building it will cost more than finishing it.
- Accessibility target named at spec, not discovered at review.
- Content design is named here as a participant, which is the whole point of the next stage.
Content
The stage most backlogs skip, which is why error states end up reading like a database message. Content design decides the pattern, the voice in failure, and whether the term already exists in the glossary. This is operational scaffolding, not a review gate: capacity for it is deployed at spec time, on the calendar, before anyone needs it.
- Failure copy, empty states and the glossary decision, made once and reused.
- If content design has no capacity this week, the item waits here rather than shipping with placeholder copy. That queue is visible, and it is the argument for their headcount.
Build
Figma library and code package move together and carry the same version. When they drift, every downstream team pays for it twice, once in confusion and once in a workaround that becomes permanent.
- One version number across design and code, or the changelog is fiction.
- I participate in this conversation. I do not lead it, and the posting agrees.
Review
Crit, accessibility and content review, with named reviewers and known turnarounds. Review is where most systems work actually sits waiting, and it is invisible unless somebody measures it. Measured, it becomes a planning input instead of a surprise.
- Each reviewer has a baseline. Parked past baseline shows up as a colored bar, not a Slack thread.
- Work in review frees the assignee's capacity for something else. That is a real capacity model, not an optimistic one.
Release
Shipped with the product release train, not ahead of it. A system release that lands out of phase is a migration nobody scheduled, and it teaches teams to pin an old version, which is how a system dies quietly.
- Changelog entry a person can read, with the migration note and the deprecation date.
- Partner teams hear about it before it lands, in the channel they already read.
Adoption
The only stage that tells you whether any of the previous seven mattered. Adoption per surface, overrides still standing, and the reason each one is still there. An override that survives two releases is a design decision the system got wrong.
- One adoption number per surface, published, including the ones going the wrong way.
- Overrides get read as feedback, not as non compliance. Teams that feel audited stop telling you things.
Patterns
Core standards, local needs, and the exception path
The posting asks for the interplay between core standards and local team needs, so product designers stay consistent and still move fast. In practice that is three buckets and one door out. Most governance models get written with only the first bucket and then spend a year absorbing requests they framed as violations.
Locked
- Tokens: color, type, spacing, elevation
- Accessibility floors
- Interaction semantics of core components
- Voice, and the terms in the glossary
Configurable
- Variants, density and layout within a component
- Composition of core parts into local patterns
- Copy inside an approved content pattern
Local
- Surface specific experiences the system has no opinion on
- Experiments, before they have earned a pattern
- One off marketing and seasonal work
Patterns
Three audiences, three artifacts, one cadence
Strategic visibility fails in two directions: nobody reports anything, or everyone gets the same deck. Different readers need different depth, and the honest test is whether each artifact would be missed if it stopped arriving.
Changelog
What shipped, what is deprecated and when, what is next. One line each, written for a person rather than for a release note. It goes where designers already read, not to a wiki page somebody has to remember.
Adoption and queue
Adoption per surface, overrides still standing with their reasons, review turnaround against baseline, and what the queue looks like next month. Including the numbers going the wrong way, which is the only reason anyone trusts the ones going the right way.
One page
What the system bought the business this quarter in hours and consistency, what it cost, and the one decision I need from them. At GE the executive artifact was what kept leadership aligned on a cadence without stopping production to explain.
Each one owned by a named person who is not me, once it is running. Reporting that depends on my calendar is a single point of failure wearing a dashboard.
Guides
AI as operating leverage
Not a section about being clever with models. The posting does not ask for this, so here is the short version and why it is relevant to a design systems backlog at all.
For twenty years you found the closest tool and reshaped your process to fit what it could do. That constraint is mostly gone, so the first question is now buy, adapt or build, asked honestly. When I hit an operational problem nothing on the market fit, I built the thing rather than contorting a team around a near miss. Relay is the one that matters here: six teams send me quarterly plans and requests in six different spreadsheet formats, and Relay turns that into one clear, resourced plan before anything reaches Asana. Vizor is capacity planning for design teams, in private beta, invite only, where the review baseline idea in the tokens above actually lives.7
The highest leverage AI in a design org is operational, not generative
Triage, summarizing research, drafting a first pass spec, keeping a changelog current, turning a messy intake into a clear brief. That is where the hours actually go and none of it touches anyone's craft. I would not put a model anywhere near the part of the work a designer is proud of.
In an operations tool the model proposes and a human decides
In Vizor, reassignments and capacity calls stage as cards, every card cites the exact sentence that triggered it, and nothing changes until a person approves it. A policy is a promise. That is the same promise made structurally, where nobody has to remember it.
Withheld on purpose
The middle of Relay's pipeline, how it reads intent out of half written prose, normalizes six vocabularies into one schema, and chases missing fields on its own, is the part with real engineering judgment in it. I am glad to walk through it in a conversation. Publishing it on a public page is not scoping judgment I would want a hiring manager to see me lacking.
Guides
Qualification fit, line by line
The nine qualities from the posting, marked honestly. Seven met, two partial. The partials are real and I have not written them softly.
Guides
First 90 days
Written for this team specifically: Design Systems and Content Design, with occasional org wide work. Nothing here reorganizes anybody.
Read the queue, not the roadmap
Map every path work takes into UX Foundations: where it enters, who bypasses the front door, and why they were right to. The roadmap tells me what was promised. The queue tells me what is actually happening.
Sit in every ritual before changing one
Crits, standups, reviews, office hours. Time them, note who talks, note what decision came out. Two weeks of that earns the right to cut something. Doing it in week one just makes me the person who cut the meeting.
Publish the prioritization logic
Written weights covering the fix versus foundational build tension, agreed with the leads, posted where requesters can read it before they ask. Then hold the first quarter's ranking to it in public, including the time it ranks my own request low.
Definition of ready, with content design in it from the start
One checklist for a component, one for a content pattern. Content design capacity gets deployed at spec time rather than discovered at review, which is the single change that stops placeholder copy from shipping.
Couple the release train to product
Get the system's release rhythm onto the same calendar as the product teams it serves, publish the changelog on a cadence, and give partner teams notice in the channel they already read rather than the one I would prefer.
Make it observable, then give it away
One adoption number per surface, one monthly queue report, one quarterly leadership page. Each owned by a named person who is not me, so it survives my calendar and so somebody else on the team gets the visibility that comes with owning it.
Guides
What I would deliberately not do in 90 days
Rename anything
Tokens, components, rituals, channels. Renaming is the cheapest way to look like you are improving a system and the most expensive thing to undo. Names carry history I have not learned yet.
Replace the tooling
Every tool migration costs a quarter of everyone's attention and produces a spike of compliance followed by a return to whatever people were doing. If the tool is the problem, it will still be the problem in month six, and I will have evidence by then.
Introduce a framework with a name
A named framework is a claim that the answer arrived before the diagnosis. The boring changes work better and are harder to take credit for, which is roughly the job.
Announce a governance model before watching a release ship
I would want to sit through at least one full cycle, from a partner team's request to the migration note, before writing down how it should work. Governance written from the outside is how you end up with an exception queue.
Meta
Changelog
Thirteen years, in the format this page has been using all along.
Meta
Who has used this
Four people who worked with me, one from each seat that matters for this role: a director, a design operations practitioner, an IC designer, and a partner exec.8
Meticulous capacity planning to hit our targets across every workstream, without burning the team out. Exceptional communication and problem solving.
Great PM. Diligent on the financial, creative and timing sides, a go getter, and brought real UX and design input rather than only tracking the work.
A year long program, complex and multi part, held together on both the project management and the client side. Team player, problem solver, real relationships.
Exemplary on a complex large scale project. Diligent planning, adaptability, and expectation management internally and externally. His role was critical to the outcome.
Why this role, and what I would want from it
I like the operating half of design systems more than most people who are good at it do. The part where a request becomes a spec, a spec becomes a release, and a release becomes something a team actually adopts instead of overriding. Etsy has a mature system and the teams doing the craft. The gap this role names, backlog, prioritization, governance, content design scaffolding, visibility, is the exact half I have been building for other people for thirteen years, usually without the title. I would take it with the platform learning curve stated up front and a willingness to be measured on adoption rather than on output.
Notes and sources
- Etsy's design system is named Collage and is owned by the Design Systems team inside User Experience Foundation. Source: Etsy Code as Craft, "Improving our design system through Dark Mode," and Etsy's Design Systems engineering posting. Nothing on this page uses Etsy internal information, because I do not have any.
- Role details are from the posting: Staff Design Program Manager supporting UX Foundations, primarily Design Systems and Content Design, reporting to the Director of Design Program Management, Brooklyn Office Hub, in office once or twice a week.
- Dow Jones: the design system unifying event and conference site builds, six of eight core properties migrated, build time cut about 80 percent. The "about" is doing real work in that sentence and stays in it.
- Relay is an internal tool with no public URL. Six teams send me spreadsheets. They do not open, log into, or self serve from Relay. I am its only user.
- The eight backlog items and their dimension scores on the prioritization board were written by me to demonstrate the model. They are not Etsy's backlog and are not drawn from any employer's data.
- The lifecycle record is representative for the same reason. The field list reflects how I actually structure this work.
- Vizor is at vizor.work, in private beta, invite only and free. The review baseline and propose only behavior described here are shipped features of it.
- All four quotes are from people I worked with, condensed from written recommendations. References available on request.
- Type is Figtree and Fraunces from Google Fonts, standing in for Etsy's licensed brand faces. Colors are read from Etsy's public marketplace UI. This is a fan styled personal page and uses no Etsy assets.