What happens when designers open pull requests?
I asked a room of senior designers to do something they would be visibly bad at, and I had not thought hard enough about what that costs a person.
There is a particular silence that falls when you ask a designer to open a pull request.
I have caused that silence. It is not confusion and it is not refusal. It is a senior person working out, in real time, whether they are about to be bad at something in front of people who are good at it.
What are we actually asking?
Not a change of tools. A change of standing.
The tooling part is genuinely small. At ClearCo I built a template repository that designers and product managers work in: a running application on the real component library and the real tokens, with mock data, installing on anybody's machine without the legacy Windows stack that used to gate it. That last detail did more for adoption than any argument I made. A thing that will not install is a thing that stays a policy.
But the ask underneath it is that people who are expert at their work become beginners on a Tuesday, in public, in a system where being wrong leaves a permanent record with their name on it. Design critique is a room. Code review is a transcript.
I underestimated that for longer than I should have, because from where I stood the change was obviously good.
Why did the wall exist in the first place?
Because it protected both sides, and nobody built it on purpose.
Handoff kept designers from being judged on a craft they were never trained in. It also kept engineers from receiving design opinions as commits from people who could not be held to the consequences. Those are both reasonable instincts. Together they produced a door that opened one way, and a category of decision that could only ever be described, never made.
Every wall in an organization is like this. It is load-bearing for somebody, and the person proposing to remove it is usually not that somebody.
Who does this change things for?
The people neither side meets.
When a designer ships through the same gate as an engineer, the gates apply to their work too. The person who picked the gray now gets the failing build, in the minute they picked it, rather than a note from an auditor eleven months later addressed to a team that did not choose it.
That inverts something our field has quietly accepted. For most of my career the person who made the choice that excluded someone was structurally insulated from finding out. The knowledge arrived somewhere else, later, as somebody else's defect.
The other half matters as much and gets less attention: drift found downstream now flows back upstream as a pull request against the template. When a designer discovers that the real component does not behave the way the system claims, that discovery has somewhere to go. Before, it went into a document, or into a conversation, or nowhere.
What made it survive?
Six things, and the order mattered more than any of them individually.
- Make it install. Not "it works if you have the stack." On any laptop, that afternoon, no permissions ticket. Adoption is mostly a function of the first twenty minutes.
- Make the first contribution trivially small. A copy change. A spacing token. Something where the review will be "looks good" and the person learns the mechanics without also defending a decision.
- Go first, and be visibly bad at it. I have opened pull requests with the wrong branch, the wrong base, and a merge I had to ask someone to undo. Doing that in the open is not humility theater. It is the only evidence anyone has that the cost of being a beginner here is survivable.
- Review the work, not the git. A reviewer who corrects someone's commit message before reading their change has ended the program. Say this out loud to the engineers before the first pull request arrives, because they will not know they are doing it.
- Report before you enforce. Same as any gate. A new check that breaks a designer's first build teaches them the system dislikes them.
- Put the rules in the repository, in plain markdown. Design rules, the accessibility standard, writing guidelines. If the answer to "is this allowed" is a person, then the answer is unavailable most of the time.
What did it cost?
More patience than I budgeted for, and some goodwill I had to spend twice.
I would also be overstating it if I said everyone came along. Some people contribute constantly and some open two pull requests a year, and I have stopped treating the second group as a failure of the program. Not every role needs the same distance from the running thing.
What I cannot tell you is whether the product is measurably more accessible because of it. I believe the decisions arrive earlier, and earlier is the only moment this work is ever inexpensive. That is a position, and it is a different kind of sentence from a measurement, and I would rather keep the two apart.
The part I would argue for anywhere
Our defaults about who is allowed to touch what are as unexamined as our defaults about color. They were set by a handoff model most of us inherited rather than chose, and they decide something large: how far a decision travels from the person who made it before anyone finds out who it excluded.
Find the wall nearest you and ask who it is load-bearing for. Then ask what would have to be true for one person to step over it on a small thing, next month, without it costing them their standing.
That is the whole intervention. Everything else is tooling.