Proton

The inheritance

Proton was not missing. It was ignored.

Two hundred and more components had accumulated over several quarters. Ninety percent of them had never been instantiated in a real screen. There was no naming convention, so the same control existed three times under three different labels. There was no documentation, so the only way to learn a component was to find someone who had used it. And Figma did not match code, which meant that even a component you trusted in the file could not be trusted in the build.

Engineering adoption sat at twelve percent. That is not a compliance problem. It is a verdict: the library cost more to use than to bypass.

From the docs

We have seen design systems die before.

That was the first thing an engineer said to me. It was a fair thing to say, and it set the shape of the work. The answer was not a better component. It was answering the question back: what would you need from this to use it.

The team made it harder. Three designers, two in India and one in the United States, with ten and a half hours between them and about a three hour overlap window. They worked in silos. There was no critique culture and no shared ritual, so three people were solving the same problem three ways and none of them knew it.

All of this had to be repaired while shipping Panorama 360 to a six month deadline, on the same library.

Phase one was counting, not drawing

The first two weeks produced no design. They produced a list.

Every one of the two hundred components was inventoried with how many times it was actually instantiated in a real file. That single number turned an argument about taste into an argument about evidence, and it is the reason the deletions were not contested. Nobody defends a component that no screen uses.

The cleanup ran in four phases, in that order, because doing them out of order is how consolidations stall.

Phase	Weeks	What happened
Audit	1 to 2	All 200 components counted by instantiation, not by opinion
Consolidate	3 to 6	Near duplicates collapsed. Five buttons became one with variants
Document	7 to 10	Every surviving component got when to use and when NOT to use
Align	11 onward	Twenty core components rebuilt with engineering so Figma matched code

Two hundred became roughly one hundred, and the hundred that survived are all actively used. Most removals were near duplicates separated by a few pixels of padding or a state nobody had implemented. Deleting a component is more effective than writing a guideline asking people not to use it.

Documentation was the deliverable, not the artefact

With ten and a half hours between the designers, written documentation was not a nice to have. It was the only channel that worked while the other half of the team was asleep.

So a component page had to answer a question without me in the room: what this is for, what it binds to, and the part most libraries omit, when NOT to use it. A page that only lists the happy path teaches people to guess at the edges.

Friday Fundamentals

The silo problem and the governance problem had the same fix: one fixed slot every week that nobody had to negotiate.

Friday, 9am to 12:30pm UTC, inside the three hour overlap window.

9:00 to 10:30 · One to one coaching. Three thirty minute sessions. Remove blockers, and talk about where each designer wants to be in a year. This is the half that gets cut first everywhere else, and it is the half that made people show up for the rest.

10:45 to 11:45 · Team design critique. Run on I notice, I wonder, what if. The framing matters because it separates observation from judgement, and that is what makes it safe to bring work that is not finished. Unfinished work is the kind worth critiquing.

11:45 to 12:15 · Component of the Week. One component, and the team votes: publish, iterate, or reject. I did not decide; the team did. That vote is what turned the library from mine into ours.

Last Friday of the month · The Proton Purge. Every component gets keep, fix, or delete. The rule is written down and it is not negotiable: if it has been unused for thirty days, it goes.

Response time on a design question went from twenty four hours to six. Consistency between design and production went from sixty percent to ninety five. And all three designers levelled up in a way I could point at.

Ownership, distributed on purpose

A system that routes through one person stalls the moment that person is asleep, and with a ten and a half hour gap someone always is. So each designer owned an area outright, and reviewed changes in it.

Owner	Area
Designer 1, India	Data visualisation
Designer 2, USA	Layout and structure
Designer 3, India	Interactions and forms
Me, lead	System governance

Each person was deliberately given work slightly above their current level, and the work was shown at company all hands rather than in a design review nobody outside the team attended. Ownership that is never visible is just extra responsibility.

The objections, and what actually answered them

Every one of these came up, and none of them was answered with a document.

“We have seen design systems die before.” Answered with a question: what do you need from it. Then a deal on those terms, so the first version served engineering rather than the file.

“Designers kept adding duplicates.” They did, and the count crept from fifty back to sixty five. Answered with a component proposal process and a locked library. A request had to name the screens that needed it and what it would replace. Most requests resolved into an existing component used correctly, which is the cheapest possible outcome.

“This is a black box.” That one was about the product, and the fix was the same shape: show the reasoning and the confidence level rather than the conclusion.

Silos and ten and a half hours. Answered with Friday Fundamentals, which is the only item on this list that is a calendar entry rather than an argument.

Two calls from before the playbook existed

What it changed

Engineering adoption went from twelve percent to eighty five in three months, and almost none of that was drawing.

Design to development handoff went from two weeks to two days. Fifty components now run across five or more regional products, and Proton became the template the other regional teams started from rather than a thing one team had. Two other teams adopted Friday Fundamentals. Engineering adopted it too, which was the moment it stopped being a design ritual.

From the docs

This is the first design system we have actually used.

That is Lucy Chu, a senior engineer. It is the one result on this page I did not have to calculate.

The product it was built for

None of the above would have been fundable on its own. It was paid for by Panorama 360, which had its own problem: a portfolio dashboard that product managers opened about once a month, to compile a report, and then closed. Four hours a week went into assembling that report by hand.

Before · the monthly report

After · Panorama 360

1. A monthly reporting screen becomes a daily landing page, scannable in about thirty seconds.
2. Portfolio totals move to the top, so the first glance answers what changed since the last visit.
3. Every AI recommendation shows its reasoning and its confidence, because nobody acts on a black box.
4. Use moved from roughly once a month to about five times a week.

Product managers did not want more data. They wanted to stop feeling stupid in front of their own portfolio, which is a design problem rather than a data one. Recommendation acceptance reached eighty seven percent, and the weekly time spent assembling a picture fell from four hours to two.