Ten products, nothing shared
The products worked and customers renewed, but each one had been built on its own. Inside a single product there were dozens of component styles, taken from different libraries by different developers over the years, and engineers rebuilt buttons, tables, and form validation from scratch for every new feature. Many customers used more than one product, and a person could meet ten different primary buttons in the course of a single task.
Where to start
I started with the design system because the cost of rebuilding components was being paid on every feature in ten codebases, and the saving would begin to show within two quarters. There was more to fix than one designer could take on at once, and an early, measurable result would make the case for the rest. A working system would also take routine interface work off my desk and leave time for research.
Components
I audited every interface pattern in the ten products and found 47 button styles, 23 kinds of form validation, and 15 table implementations. Engineering said what was feasible, product said what users expected, and for each pattern we picked the best existing implementation.
Figma first
I built the system in Figma, where it could start that week with one person. In code it would have matched the products exactly, but that took engineering time we did not have, and the AI tooling that would have let me make it myself did not exist yet. In Figma it would drift from the products whenever engineering met a constraint I had not anticipated, so I met the engineering leads regularly to compare what I had drawn with what could be built. I have a computer science degree and started as a front-end developer, which let us have those conversations in their terms. Today I would make it in code, as components an engineer could copy, and I think development time would have come down sooner.
The system covered buttons, color, type, icons, forms, tables, navigation, layout, loading states, and modals. Each section began with written rules for using the component, and each component was drawn in every state, with its accessibility requirements and notes for the engineers who would build it. Anyone could propose a change, and design review decided whether it went in.
Patterns
The questions that came to me most often were about behavior, such as how a field reports an error, which button a screen leads with, and how a page with a given purpose is put together. I followed atomic design, and the layers above the components held the answers: the rules for using each one, the patterns several of them make together, and the pages made from those patterns. I published all of it as a style guide alongside the components, because the engineers I was delivering to were not used to working from a design system. When a question came up a second time I could point to the page that answered it, and product managers who had learned the building blocks began to write their requirements in those terms.
Search worked the same way in many of the products. The screen opened on a form of about twenty parameters, a person had to consider each of them, if only to leave it blank, and nothing was listed until the form had been run.
Results first
I argued that most people came to the screen to see what they were working on, and that it should show them something before it asked them anything. I ran workshops with customers and watched what they did in Pendo, and found the ten things they searched for most often.
The new screen opens with a person’s own requests already listed and those ten searches one click away, so the results are in front of them before they have had to choose anything. Filters narrow the list from there. I put the ones that did not serve a common search behind one button, where a complex search can still be made, and kept a clear way to the searches that are rarer and matter most. Anyone can save a set of filters as a view of their own, which sits above the list with the others.
I also renamed the item in the navigation, from Search to the thing being searched for: requests, documents, cases, requesters. It was the first time I had been able to work object-oriented UX into the products, and I kept to it in the components that followed, so that each pattern belonged to an object and each action was scoped to the thing it acts on. The new search was itself a set of small patterns, and after a pilot they went to all the others.
How an action feels
The patterns also say how an action should feel, a part of design systems that gets little attention. Finishing something should feel good, and closing a request ends with an animated checkmark. Where the system is unsure, the person should have every fact it has: a request flagged as a likely duplicate is shown with its score, the language the two requests share, and both of them side by side. Anything destructive should feel as if it can be taken back. A merge can be undone, and the release of a record, which cannot, is held for a few seconds first, as a sent email is.
Accessibility
Federal agencies are bound by Section 508 and can be sued when their software falls short of it, and accessibility matters to me apart from the law. It went into the components at the start: button and error states, color contrast, reflow, focus order, keyboard paths, and what a screen reader says at each stop. I reviewed features again before they shipped, and changed the component when a review found something.
I was the company’s Section 508 subject matter expert. When a customer ran an audit of its own I joined the call and went through its findings line by line against the standard. Most of them were false positives, and I gave dates for fixing the real ones. Over three years the products went from barely meeting WCAG level AA to meeting level AAA.
Across the suite
The ten products belonged to three lines: public records (FOIA), offices of inspector general (OIG), and workforce management (WFM). One system served all of them. They already worked together, and with the same components and patterns in each they came to look as if they did. A person who crossed from one product into another knew how to use it, because the patterns were the ones they had already learned. The sales team could show in a demonstration how the products fit together, and selling a second product to a customer who had the first got easier.
The public portal
The public records portal was the first use of the system outside case processing. Its users were the general public, and I added to the system for them, among other things a tile button, borrowed from IBM’s Carbon, that makes the next step plain and gives people a large target to touch.
I treated a request as a search. A requester wants documents that an agency holds, and most of the agency’s work on a request is looking for them, so the portal shows what has already been released before the form is filed, as the search screens show results before filters. The form interrupts once with the released records that match, and blocks nothing. That interruption went into the system, and I used it again for case officers in intake, where a new request is flagged as a likely duplicate or as belonging to another agency. The rest is in the portal case study.
Adoption
The workforce management line was the hardest to bring into the system, because much of it was custom-built and run as a managed service. The engineering lead for one of its products did not want the system at all. He considered most of the changes cosmetic, such as button styles, shared color, and common branding, and pointed out that his customers had not asked for any of it. When a customer remarked on a new color, he brought it to me as evidence.
What to measure
I did not think one comment was a signal: people notice a change, say so, and stop noticing. At my request the company agreed to judge the system on defect rates, development time, and support volume once every product had adopted it, about a year out, and to reverse nothing on individual reactions in the meantime.
Development time fell 10 to 15% in the first few months and settled near 30% about a year in, once every product had adopted the system, and the products looked and behaved alike.
Checking what shipped
Each quarter the engineering teams and I went through the features they had shipped and compared them with the system and the style guide. Where they differed we talked it through, and either the feature changed or the system did.
Between audits I checked the products myself. We had nothing that could read an implementation against the system, so I used Pendo, the analytics tool then running in every product. I tagged the features that did not follow the system, which gave me a record of where each one lived and how much it was used, and with that it was easier to make the case for changing it or removing it.
I presented the method to Pendo at Pendomonium, their conference, and it is part of how I came to my current work at The Home Depot, where each quarter we use AI to audit how teams follow our measurement standards.
One designer, ten products
I was the most visible sign that the company was changing from developer-led to product-led, and a large part of the work was teaching. I wrote the guidelines, taught the teams that would use them, and spoke at company events and at customer summits about what design is worth in government software. By the end people knew what to use and how to use it, and they knew why the system mattered.
A contractor or an intern helped at times. With the components and their rules in place, engineers could build most screens without a specification from me, and my time went to the work that needed a designer.
I set out how design work would run with product and engineering in eight stages, from the brief through implementation, each with an owner and a document it produced. Customers took part in two of the stages through working groups. The company’s three product lines shared a UX roadmap, planned by half-year.
Engineering hours were measured to the sprint and the return on a design proposal was not measured at all, so design work waited behind anything that came with a revenue figure. That was one reason I brought in product analytics, which is described in the research case study.
What I learned
Positive conflict is essential
I met the engineering leads regularly to hear where the components I had drawn could not be built. One of them did not want the system, and he was right that his customers had not asked for it. After he objected, I got the company to agree on how it would be judged a year later.
Delight is always a differentiator
FOIA software is expected to be boring. To make people feel good about the work they do, I added motion where someone finishes a task. The animations began in FOIAXpress, as the portal case study describes, and went into the system. They took little effort to build, and UX-Lite scores rose 10 to 20% after they shipped.
What I would do differently
We moved quickly, and I did not write down why most decisions were made. Engineers who joined later reversed some of them, because the reasons were nowhere they could find, and I had to argue for them again. Within about eighteen months, skipping the documentation had cost more time than it saved. I would record the reason with each decision as it was made.