What happens when designers open pull requests?

There's a particular silence that falls when you ask a designer to open a pull request. I've caused it, and I don't read it as confusion, or refusal.

It's a senior person working out, in real time, whether they're about to be bad at something in front of people who are good at it.

The tooling part of what I was asking for was small. At ClearCo, I built a template repository that designers and product managers work in. It's a running application, on the real component library and the real tokens, with mock data.

And it installs on anybody's machine, without the old Windows stack that used to block it. That detail did more for adoption than any argument I made, because a tool that won't install stays a policy.

The other part wasn't small at all. We're asking people who are expert at their work to become beginners on a Tuesday, in public. And here, being wrong leaves a permanent record with their name on it.

Think about the difference. Design critique happens in a room, but code review leaves a transcript. I underestimated that for longer than I should have, because from where I stood, the change was obviously good.

The wall protected both sides

Nobody built the wall on purpose, but it protected both sides.

Handoff kept designers from being judged on a craft they were never trained in. And it kept engineers from receiving design opinions as commits, from people who couldn't be held to the consequences.

Both of those instincts are reasonable. Together, though, they made a door that opened one way, and a kind of decision designers could describe but never make.

I'd say the same of every wall in an organization. It's load-bearing for somebody, and the person proposing to remove it usually isn't that somebody. This time, that person was me.

It helps the people neither side meets

So who is the change for? Mostly, the people neither side meets.

When a designer ships through the same gate as an engineer, the gates apply to their work too. So the person who picked the gray now gets the failing build in the minute they picked it.

Before, the news came as a note from an auditor eleven months later, addressed to a team that didn't choose it.

That reverses something our field has accepted. For most of my career, the person who made the choice that excluded someone was shielded, by the structure, from ever finding out. The knowledge arrived somewhere else, later, as somebody else's defect.

The other half gets less attention, and it matters as much. Drift found downstream now flows back upstream, as a pull request against the template.

So when a designer finds that the real component doesn't behave the way the system claims, that finding has somewhere to go. Before, it went into a document, or a conversation, or nowhere.

Six things made it last

The order mattered more than any one of them.

• Make it install. Not "it works if you have the stack." On any laptop, that afternoon, with no permissions ticket. Adoption is mostly decided in the first twenty minutes.
• Make the first contribution tiny. A copy change or a spacing token will do. The review will be "looks good". 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 the only evidence anyone has that 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. Tell the engineers this before the first pull request arrives. They won't know they're doing it.
• Report before you enforce. 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 and writing guidelines. If the answer to "is this allowed" is a person, the answer is unavailable most of the time.

It cost more patience than I'd budgeted for, and some goodwill I had to spend twice. And not everyone came along, either. Some people contribute constantly, while some open two pull requests a year.

I've stopped treating the second group as a failure of the program, because not every role needs the same distance from the running thing.

So is the product measurably more accessible because of it? I don't know. I believe the decisions arrive earlier, and earlier is the only moment this work is ever cheap. That's a position, not a measurement.

Most of us inherited the handoff model, and its defaults about who is allowed to touch what. We didn't choose them. So find the wall nearest you, and ask who it's 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.