The problem
In 2018 PGi sold about six products, and each one had been designed by a different designer. You could tell which. Quality varied by author, and so did the answers to questions every product had to answer anyway: what a button looks like, how a dialog behaves, which side a panel opens from. No designer was being held to a standard, because there wasn't one to hold them to. Leaders in the company found that frustrating, and they were right to.
The cost landed in three places. Nine designers made the same interface decisions separately, over and over. Five front-end teams, roughly 75 engineers, built their own versions of the same controls. And a customer who used two PGi products got two unrelated experiences from one company.
I had just finished the GlobalMeet redesign. The VP of Design asked me for a UI Style Guide the other designers could use. He wanted the rest of the suite upgraded on the back of that work, so every app would feel like it belonged in the same ecosystem.
What I did
Turned a style guide request into a system
I started by defining components, and while I was doing it I found other companies publishing what they called design systems. It was the work I was already doing, with a name and a shape.
So I took that back to the VP of Design and asked to come off app design projects entirely. My argument was that a style guide is a document you consult, and a system is components, the rules for using them, and a way to add to it. A document gets read once. A system gets built with. He agreed, and I moved to it full time.
I also moved the design team off Photoshop and Illustrator and onto Sketch, because a library of shared components needs a tool built around shared components. One designer wasn't comfortable in Sketch at all, so I gave her dedicated time until she was. A migration that leaves one person behind has told that person their work matters less.
Started from decisions that had already been tested
DIG's first decisions came straight out of the GlobalMeet redesign: colors, button sizes, text styles, gradients and elevation, iconography, side panels, header bars, and modal dialogs.
I took them because they'd already been measured in two rounds of usability testing. That matters when nine designers each hold a defensible opinion, because a designer arguing with a tested decision is arguing with a result rather than with me. Most of them were glad to have it, because there was real appetite for updating the apps.
An engineering team owned the Angular library, and they didn't report to me. My design files shipped first, and when a designer used a new component in a screen, a developer added it to the library. I had no authority to require any of it, so every component that reached code got there because we agreed it should.
Kept each platform's norms instead of overriding them
The obvious reading of "every app should belong to the same ecosystem" is one PGi look, applied everywhere. I rejected that.
Users learn conventions from the platform they're on, not from the company that made the app. PGi's web apps ran in Angular in a browser, so the web system paid attention to Material norms. Later I built PGi's iOS and Android systems, and I kept each one distinctly iOS and distinctly Android.
That choice cost me a single library. Three platforms meant three sets of decisions to make and maintain, and the products would never be identical side by side. I'd rather pay that than charge every user for relearning a control their own device already taught them.
Wrote the rules only after they were broken
For the first stretch I designed components and shipped no guidance with them: no usage rules, no behavior, nothing about when a component was the wrong choice. Skipping documentation is fast, and I had about a dozen components ready quickly: buttons, dialogs, side panels.
Then I watched what happened to them. Designers used components in places they didn't fit, and developers built behaviors I hadn't considered. A component with no written rule isn't a decision, it's an invitation to interpret, and everyone interpreted.
So I wrote the guidance: what each component is for, when to use it, when not to, and how it behaves when things around it change. Documentation slowed the component count down. It's also the reason the system held, because a developer who knows what a side panel does at a narrow window doesn't have to invent one.
Two designers pushed back hard, and their objection was that the system took their authority to solve problems their own way. That was a fair reading, because a system moves some judgment out of an individual designer's hands and into a shared standard. I met with them and argued consistency on the merits. It didn't fully land, and design leadership had to step in. Several of them had never worked inside a system before, and I'd underestimated how much of the resistance was unfamiliarity rather than disagreement.
What changed
The clearest change was in how the company talked about its own products. There was energy around redesigning PGi's apps that I hadn't seen before, and sales and product teams were reporting good things back. Six products started reading as one company's work.
The second change was in how three functions worked together. Design, engineering, and product had been negotiating each app on its own terms. After DIG they were building off the same decisions, so handoffs got shorter and more structured. A designer handing off a side panel wasn't introducing the idea of a side panel anymore.
For customers, someone who used two PGi products no longer had to learn the second one from scratch, because the controls behaved the same way in both.
I don't have figures for any of this. Nobody at PGi measured the system's effect while I was there. The percentages in my other materials come from a 2024 survey at Apple, and they have nothing to do with DIG. The evidence I'll offer instead is what happened after I left in 2020. DIG was alive, still being worked on, and led by the designer I'd hired to support it. A system that outlives its first author has been adopted by somebody other than its author.
What I'd do differently
I'd have built a contribution path in the first quarter. Governance stayed loose for the first year, and I was the only person submitting component designs. Product designers sent me requests, I ranked them in my backlog, and I decided what belonged based on whether more than one product would use it. The judgment was right and the queue was wrong, because six products' needs were waiting on one person's priorities. It also taught designers that the way to get a component was to ask me, which is the opposite of what a system should teach. A rough contribution process with a review step would have beaten a well-managed backlog.
