Ever-Evolving Systems Thinker

Like many large platforms, McGraw Hill’s Learning Management System had accessibility problems. The stakes were unusually high. Texas state vendor eligibility required a documented ACR, and without it McGraw Hill couldn’t compete for contracts tied to one of the largest education procurement cycles in the country. A third-party audit was cataloging surface findings. What nobody had yet done was figure out what those findings meant at a system level, and what it would take to fix them properly.

Several teams were working through the backlog. Ours happily handled the tickets requiring the deepest systems-level understanding. Our triad was a dev lead, a TPM, and me. I was the only UX designer on the effort and what I kept finding, working through tickets with the dev lead, was that the surface findings were symptoms of deeper systemic problems. One example was a collection of tickets separately flagging inaccessible tab panels. These all turned out, on closer inspection, to be something else entirely. The real issue was that a tab component was being used as a secondary navigation menu. The auditors had read the visual appearance and missed the semantic failure underneath.

Rather than refactoring the tabs and their panels, the simpler solution was to replace it all with a more appropriate pattern. I wasn’t just resolving tickets. I was reading the system underneath them.

I was able to do the remediation and implement the new pattern myself. I took the opportunity to build a scalable secondary nav accessibly from the start, including a documented addition to the Figma Library, designed to work at 400% zoom and across viewport sizes, with its styling fully separated into the theme layer. This was not the first time that I pulled work from the backlog to lift some weight off the team.

That pattern repeated throughout the project. I was noting where design decisions made in a vacuum years prior had compounded into a dozen failure points. The right answer was to rebuild or replace appropriately rather than add gum to spider webs.

Because I write HTML and CSS at a working level, I didn’t have to wait for developers to implement my proposals before finding out if they worked. I wrote the production-ready markup directly. Developers could take that markup, attach logic, and move quickly. For more significant rebuilds, I worked through the design simultaneously in Figma, validated behavior in code as well as with product owners, and then came back in after developer implementation to further optimize the markup. This became an efficient cycle for us.

One such example involved complete deconstruction of a nested content player used by teachers and students across the platform.

The remediation effort concluded with a delivered ACR and McGraw Hill maintained Texas state vendor eligibility. From there, the contracts are understood to have been in the tens of millions of dollars, with compounding potential from other states that follow Texas procurement decisions.

After that accessibility remediation effort at McGraw Hill concluded, I returned six months later as a contractor. The role was supporting a completely different area of the company as they were forming their own internal UX team. When the new manager started, they learned that during my previous tenure embedded in the platform teams, I had been trying to build a real design system infrastructure, the kind that actually closes the gap between design and production. They wanted to pursue it with me again but from this new angle.

The project that was funding my contract went quiet early and that became our opening. I was able to use the available time to build a technically complete proof of concept. We were driving a Design System Ops initiative.

One of the problems I was solving existed for all too familiar reasons. The frontend Web Components encapsulated some curmudgeonly CSS. Theming across Shadow DOM boundaries is genuinely difficult and the standard answer is to refactor the components.

That would be a long and expensive project that nobody could justify. I found a different answer.

With one file of targeted CSS and custom properties per component, I had essentially created trusses and could connect a bridge over the Shadow DOM boundary. I introduced CSS @layer to the devs and extended it for additional sub-theme management. I demonstrated that meaningful theming progress including modes for High Contrast, Extra Wide Space, OpenDyslexic support, and more could proceed without an expensive effort to simultaneously refactor the Web Component code itself. Perhaps most exciting to some was that we could cleanly bandage all the little annoying brand and theme missteps across the library. These missteps are representative of the drift I love to solve.

Beyond that, the demo was set to improve the theming infrastructure and connect with Figma. Standalone component libraries in this monorepo fed a new Storybook instance and could more efficiently access new purposeful wardrobes of styling. I included a Design Token pipeline to parse Figma Variables in both directions. Both from Figma Variables into tokens that map directly to production CSS as well as syncing that token map back into Figma. Both directions with PRs and a typical path to production. Every piece had been proven against a local instance of the actual codebase.

A full-time role was created around the demo and its concepts. What I built this time became the most complete demonstration of Design System Ops thinking I’ve produced.