Ten products, no shared vocabulary
The company had just been acquired by Gemspring Capital, and the new CEO came in believing design could differentiate them in the government market. The products worked and the customers renewed. Underneath that were ten products built independently, each solving its own problem well and none of them sharing anything, which is a reasonable place to arrive and a hard place to grow from.
There was more to do than one person could do at once. I needed to start with something that would produce a result fast enough to justify the next thing. I started with a design system, because it was the fastest route to something measurable: ten independent codebases meant every new feature rebuilt its components from scratch.
The system
Figma first
The fork was whether the system lived in Figma or in code. Code-first would have been true, and it would have meant waiting on engineering capacity I did not have. Figma-first meant I could start alone that week, and it meant the file and the product would drift apart the first time engineering hit a constraint I had not anticipated.
I went Figma-first and corrected the drift in weekly reviews with the engineering lead. Every session we reconciled what I had drawn against what was buildable, and the file changed more often than the code did. This is the general shape of how I work: something real now, corrected as it meets reality, over the right answer arriving too late to matter.
- 01AuditI catalogued every UI pattern across all ten products — 47 button styles, 23 validation variants, 15 table implementations — and wrote them all down.
- 02DefineEngineering told me what was feasible, product told me what users expected. We picked the best implementations and documented why.
- 03BuildEvery component in Figma with variants for all states, plus accessibility requirements and implementation notes.
- 04GovernAnyone could propose a change, but changes went through design review before entering the system.
Accessibility, designed in
Section 508 is law for our customers, and a federal agency that procures non-compliant software can be sued over it. Accessibility went into the components at the start instead of into a remediation backlog later. Contrast, focus order, keyboard paths, and screen reader behavior were part of each component’s definition, which meant the defects that used to surface in production mostly stopped being written.
The other half of that job was answering for it. Customers raised lists of suspected violations regularly, and I took those calls and went through them line by line: which items were not violations and why, which ones were, and when the real ones would ship. Most lists were mostly false positives. Being the person who could say so on the call, with the standard open, kept those conversations from turning into procurement problems.
Applied across the suite
The year it took to adopt
One product family did not want the system. Their engineering lead thought most of what I was changing was cosmetic — button styles, shared color, common branding — and that their customers had not asked for any of it. When a customer remarked on the new color, he brought it to me directly and he was not calm about it.
He was half right. The customer did comment, and one comment is not a signal. People notice change and say so, and then they stop noticing. The question was never whether anyone would remark on a color. It was whether defect rates, build times, and support volume moved, and those take a year to answer.
They answered in favor of the system. Development time came off 10 to 15% in the first few months and settled near 30% about a year in, once adoption was complete across the suite. Developers stopped waiting on specs and the interface became consistent across products.
Getting the company to wait for that answer instead of reacting to whoever was loudest was harder than building the components, and it changed how decisions got made afterward.
The constraint underneath everything
Engineering capacity was the permanent problem. Every design I finished sat in a queue behind work that had a revenue number attached, and mine did not have one. Engineering hours were quantified down to the sprint. The return on what I was asking those hours to build was not quantified at all, so it lost.
That is most of the reason I ended up building product analytics, and why I worked with revenue operations to connect it to Salesforce. A proposal that arrives with a dollar figure gets ranked against the other proposals. A proposal that arrives with a rationale gets ranked last. The full account is in the feature-to-revenue work.
The bottleneck was not in our software
With the tactical work absorbed by the system, I started the company’s first research practice. That meant sitting with FOIA officers and watching them work: intake, finding documents, review, approval, release. Several conversations a week across more than seventy agencies.
The biggest problem was not our software but getting documents out of record custodians, who mostly sit outside the FOIA office entirely. They are scientists, lawyers, and policy analysts with their own deadlines, and a FOIA request is rarely the most urgent thing on their desk. That single step consumed 60 to 70% of total response time.
The bottleneck was organizational. FOIA officers depended on colleagues they had no authority over, and most agencies had no mechanism to change that.
I documented it across agencies and presented it at the company town hall, sales kickoff, and customer summits. The research was cited in the Senate Judiciary Committee’s hearing on the Freedom of Information Act, and it became the argument for the portal in the public records portal.
What I took from it
I picked the boring project on purpose
I arrived with a list of roughly fifteen things that needed fixing and capacity for one. The design system was not the most interesting problem on that list. It was the only one that would produce a number inside two quarters, and that number is what paid for the research practice, which produced the custodian finding, which shaped a product and an acquisition thesis. I still choose first projects this way, by what they unlock instead of what they are.
I let the reasoning live in my head
We shipped fast and I did not write down why we made most of the calls we made. Engineers who joined later undid intentional decisions because the rationale was not anywhere they could find it, and I had to relitigate choices I had already made once. The documentation I skipped to move faster cost more time than it saved within about eighteen months.