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.

It installs 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, 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 in this system, being wrong leaves a permanent record with their name on it.

Design critique happens in a room, and 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. It also 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 they produced a door that opened one way, and a category of decision that 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

The change is mostly 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.

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 structurally insulated from 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 discovers that the real component doesn't behave the way the system claims, that discovery has somewhere to go. Before, it went into a document or a conversation, or it went nowhere.

Six things made it last

The order mattered more than any one of them.

• Make it install. I don't mean "it works if you have the stack." I mean on any laptop, that afternoon, with no permissions ticket. Adoption is mostly a function of the first twenty minutes.
• Make the first contribution trivially small. A copy change or a spacing token will do. 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 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, because 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. That means 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 budgeted for, and some goodwill I had to spend twice. Not everyone came along, either. Some people contribute constantly and 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.

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 inexpensive. That's a position and 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.