Application / Etsy / UX Foundations
Design Program Manager
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, and whether anyone can tell what changed. That is the job I have been doing under other titles for thirteen years.
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.
The role, as I read it
- Team
- UX Foundations
- Supports
- Design Systems and Content Design
- Mode
- Working leader. Strategy and the ticket queue, same week.
- Intake
- Mine, so the focus stays theirs
- Ambiguity
- Settled by an agreed lens, not by who asks loudest
- Reports to
- Director, Design Program Management
Me, against it
- Status
- Available, New York
- Current
- UX Program Manager, Brand at Dow Jones
- Systems
- Three, in three different relationships
- Content design
- Inside my remit today, not adjacent to it
- Office
- Brooklyn hub, once or twice a week, fine
- Limitations
- Two, stated in Qualification fit
The specification
The posting, line by line
Every line below is from the posting. Open one to see the work behind it, named so it can be checked. Two are marked partial on purpose.
Shield the team met
What the posting says
Architect team stability. Streamline intake, keep the roadmap realistic and protected.
The proof
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.
Run the backlog met
What the posting says
Drive the end to end lifecycle of the Design System and Content Design backlogs. Granular, actionable, aligned to quarterly goals.
The proof
I own the Asana implementation for a brand marketing team at Dow Jones: reporting, capacity and resource management across roughly eight events and six 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.
Define prioritization met
What the posting says
Establish and socialize clear, observable principles. Balance urgent fixes against foundational builds.
The proof
Worked through on this page: four lenses, each with what it optimises for and what it costs. Observable means someone else can apply it without me in the room and reach the same order.
Optimise team rhythms met
What the posting says
High signal, low friction rhythms. Standups, retros, crits that improve flow and decision quality.
The proof
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.
Integrate with the design org met
What the posting says
Orchestrate how product teams interact with UX Foundations. Consistency without bottlenecks.
The proof
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.
Sync with product releases met
What the posting says
Ensure system updates are synchronized with product release cycles.
The proof
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.
Scaffold content design met
What the posting says
Build the operational framework for Content Design. Backlog, capacity deployment, integration into design reviews.
The proof
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.
Make the work visible met
What the posting says
Streamlined, audience appropriate reporting. Dashboards, newsletters, executive summaries.
The proof
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.
Manage external partners met
What the posting says
Operational lead for design agencies or vendors. External work meets the standard and integrates cleanly.
The proof
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.
Partner with brand design met
What the posting says
Collaborate with the Brand Design organization to align product and brand systems and standards.
The proof
This is my job title today. I am the brand steward for all product touchpoints at Dow Jones, sitting on the brand side of exactly this seam and partnering with the commerce and acquisition product design teams across WSJ.com, Barron's.com and MarketWatch.com. My team owns the brand guidelines and is refining the visual system that will feed a brand hub, which has not shipped. So I have argued both halves of this: what the product system owes brand, and what brand has no business asking product for. Most people arrive at that conversation from one side only.
Design to code partial
What the posting says
Partner with Engineering Ops. Participate in technical discussions on the design to code pipeline.
The proof
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.
Multi-platform scale partial
What the posting says
A mature system serving buyer and seller experiences across platforms.
The proof
Scale and complexity, yes: I have planned and overseen the design of more than five large enterprise sites, for Vodafone, SAP Ariba, Microsoft, Merck and Arizona Public Service, plus android.com, tv.google and wearos.google.com at Huge. Systems specifically: 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. What is genuinely new is native iOS and Android at marketplace scale.
Lead org-wide programs met
What the posting says
Lead occasional org wide programs with the Director of Design Program Management.
The proof
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.
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 tokens: named decisions, defined once, used 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 with the program that taught it to me.
Components
Evidence library
Nine pieces of work: what it is, its status, and what it proves for this role. Open one for the detail.
Patterns
Prioritization, and why the lens decides it
The posting asks for clear, observable principles balancing urgent fixes against foundational builds. Here is the principle I would bring to that conversation, which is that most priority arguments are not about the items at all.
Same five requests, four different teams
Nothing about the requests changes between these views. Only the lens changes, and the order changes with it. That is the whole argument: name the lens out loud and the queue stops being a negotiation.
Two of these never settle by principle alone. A dated partner request and a change touching every platform both need a named human and a short conversation. The point of agreeing the lens is that everything else stops needing one, so the conversations you do have are the ones worth having.
The five request types are generic, written by me. I have no access to Etsy's backlog and I am not claiming to know what is in it.
Patterns
One request, from intake to adoption
End to end lifecycle is the posting's phrase. Here it is one stage at a time, with the request record filling in as it moves. Note where content design enters, and the field that stays empty 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. Out of phase, teams pin an old version and stay there, 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, not after.
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.
Request record, representative
Stage 01, Proposed. 4 of 17 fields written. Open items: none.
Printed complete. On screen the record fills one gate at a time, and one field stays open between Spec and Content.
Representative record.6 The real ones are somebody's planning data. The field list is the part that cannot be faked, so that is the part I am showing you.
Patterns
Core standards, local needs, and the exception path
Core standards against local team needs, so product designers stay consistent and still move fast. In practice: three buckets and one door out. Most governance models ship only the first bucket, 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
Visibility fails two ways: nobody reports anything, or everyone gets the same deck. 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
The posting does not ask for this, so here is the short version and why it matters to a design systems backlog.
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.
What arrives
- Subscription strategyits own sheet
- Product designa different sheet
- Product managementhalf a brief
- Performance marketingdates, no scope
- CRMscope, no dates
- Event marketinga mail thread
Relay
Collect
Withheld on purpose
Hand off
The middle is where the engineering judgment is. Happy to walk through it in a conversation, not on a public page.
What comes out
One resourced plan
- Every request in one shape
- Missing fields chased, not guessed
- Ordered, with the reason attached
- Named owner and a week
then into Asana through the API, where the teams see their tasks
Six teams send. One person uses it, me. The mess stops here rather than at the team downstream.
The resourcing tool is the other one, and the problem behind it is not specific to any employer. The same hour goes wrong in every creative team I have worked in. Agencies, a startup, in house teams. The resourcing meeting happens, real decisions get made out loud, and then somebody has to remember them and write them up afterwards, usually late and usually thinner than what was said, and the plan drifts out of date until the next meeting rediscovers it.
What the tool does about that is narrow. The decision is captured as it happens and staged for a one click yes, so nothing changes unless a human confirms it, and once confirmed the capacity view and the team's plan of record update themselves. The meeting updates the plan, instead of someone updating the plan after the meeting. It is a fully built tool, in real weekly use, that I built to solve a problem in my own role.7 Happy to walk through it live if this turns into a conversation.
The resourcing hour
In the meetingSaid in the meeting, confirmed once, reflected in the plan of record.
The names and percentages in the loop above are illustrative, written by me to show the shape of the thing. They are not anyone's real capacity data.
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 the resourcing tool, a call made out loud in the meeting is captured and staged for a one click yes, and nothing changes until a person confirms 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 posted qualities, plus two the posting raises elsewhere that I can only answer partially. Nine met, two partial.
8+ years in program management, project management or design operations within product developmentmet
13+ years, agency through Fortune 500, B2C and B2B: Beyond, POSSIBLE, Vertic, Huge at Google, Everyrealm, freelance, and Dow Jones now.
Direct experience with design systems and component librariesmet
Three, in three different relationships. Leading one at Dow Jones, eight event and conference properties onto one system, six of eight migrated, build time cut about 80 percent. Stewarding one into production at Arizona Public Service with Infosys and 28+ engineers. Auditing one at NYU Langone to find out why adoption had stalled.
Experience working with content designersmet
Current remit. I resource my team and oversee design, content design and copy from a brand standpoint at Dow Jones. The honest edge, since it matters for a role that scaffolds Content Design: I oversee and resource that work, I have not run a dedicated Content Design function or owned its craft ladder.
Context switch smoothly between tactical execution and strategic planningmet
The same week at Dow Jones holds a Friday event go live and a multi quarter migration of eight properties into one system. A working leader is not a compromise between those two, it is the only way either one gets finished.
Clear, succinct communication that adapts depth to the audiencemet
GE Healthcare executive visualizations for a global campaign, and a Google director on the record about communication and capacity planning. Three audiences, three artifacts above is the same instinct written as a system.
A focus on team flow, decision quality and craft standards, not just velocitymet
Rituals charged against focus and cut when they stop earning their slot. A review cadence at APS built to catch drift at implementation rather than at QA. Review baselines measured so waiting is a number instead of a mood. Velocity is the easiest of the four to improve and the least useful on its own.
Planning and negotiation with leaders, trust with ICs through ownership and follow throughmet
Two years embedded from an agency seat with no formal authority at all, partnered with Google's Search UX Design Director and his team on a year long exploration, and with PMMs and strategists across three properties. The IC half is on the record too, from a designer I worked with for a year at Vertic.
A generous collaborative spirit, with a passion for leveling up the operational skills of those around youmet
The test I hold myself to is whether the thing still runs when I am not in the room. At Everyrealm I hired a team and then handed them the methodology rather than the instructions, because a set of instructions makes people dependent and a method makes them faster than you. The ritual rule is the same instinct pointed at myself: when a meeting stops earning its slot it gets cut, and mine goes first, which is the only version of that rule anyone believes. It is also why the last step of my 90 day plan is giving the reporting away to named owners who are not me, along with the visibility that comes with owning it. Operations skill spreads by someone handing you a model and letting you run it badly once.
A mature design system serving buyer and seller experiences across platformspartial
Partial, and worth saying plainly. The scale is not the gap: I have planned and overseen the design of more than five large enterprise sites, among them Vodafone, SAP Ariba, Microsoft, Merck and Arizona Public Service. The gap is platform. My systems work has been web and brand surfaces plus one transactional .com and mobile app, so a system spanning native iOS, Android and web at marketplace scale is new to me. What transfers is the operating half: intake, prioritization, release coupling, adoption measurement, governance. What does not transfer automatically is platform intuition, and I would spend the first month earning it rather than assuming it.
Technical depth in the design to code pipelinepartial
Partial, and the posting says participate rather than lead. I have taken a comprehensive system into production with a 28+ engineer partner org and I am running a migration onto one system now, so I can hold the conversation and spot a guess dressed as an estimate. I am not an engineer. I would lean on Engineering Ops for the depth and make sure the seam between Figma and code is tracked as a real dependency rather than an assumption.
Familiarity with Jira, Figma, Notion and Googlemet
All four in regular use, plus Asana, where I own a team's implementation for reporting, capacity and resource management, and Webflow. I build with Claude and Cursor rather than sampling them.
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
Agree with the leads what the quarter is optimising for, write it down, and post it where requesters read it before they ask. Then hold the first quarter's ordering to it in public, including the time it puts my own request last.
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
What people who worked with me say
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.
On the obvious question, since I started my current role in February. I am not running from anything. The work is real, I am doing well at it, and staying would be a perfectly good year. The reason I am open to this got clear over thirteen years rather than over the last seven months: I do my best work where the design system is a product in its own right, with craft teams already doing the craft and buyers and sellers on the other side of every component, because that is where the operating layer decides whether any of it lands. Etsy is one of a small number of places where that is true, and that is worth acting on when the right role appears rather than discovering in month four that I should have.
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 five request types on the prioritization section are generic examples of work any design system receives, written by me to show how a lens changes an order. They are not Etsy's backlog, they are not a diagnosis of Etsy's system, and they 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.
- The resourcing tool is a fully built tool, in real weekly use, that I built to solve a problem in my own role. It is not a venture and not a product I am selling. The honest limit on it: it is built for and used by me and my own planning, and it has not been deployed across my employer.
- 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.