Client University of Michigan, ICPSR Role Sr. UX Engineer (Contract) Period January to August 2022 Stack Semantic HTML, Dart Sass, Bootstrap, Parcel, React, Next.js, Figma

Say you have a design team producing polished work in Figma, and an engineering team that is good at their jobs but new to component-driven frontend. Both are doing what they should. The designs still come out wrong.

That was ICPSR when I got there. It is one of the largest social science data archives in the world, and the site is not marketing. It is the tool researchers use to find and request restricted data, so the details matter.

The problem was not skill on either side. Nobody had written down what a component actually was. Without that, every handoff turned into a negotiation, and every negotiation produced a slightly different button.

I was hired to sit between them. In practice that meant three jobs at once: I was on the design team, I built working prototypes, and I wrote code alongside the engineers. Being accountable to both ends of the handoff is the only reason any of this worked.

What was actually breaking

The design team worked in Miro during sprints, then moved everything into Figma for discussion and sign-off. That part worked fine. When I started they recruited me to join design sprints to help the researchers refine their designs and ideas. this gave me great opportunity to meet the departments administration and researchers. The director told me he was impressed with my ability to adapt and perform th steps of the exercise.

The problem was the step after. The NextJS developer team could not use Figma. So design was being reviewed and approved in a tool that half the team could not open, and then handed across anyway.

That constraint is why the component library had to be a website. Not a Figma library, not a spec document. A page an engineer could load, look at a component, and copy the markup out of. Almost everything else about the project followed from that.

I was brought in for the JavaScript and Node side. The library needed to compile SCSS into a CSS file that could be attached to projects as updates shipped. I had used Webpack and Grunt for that kind of work before. I picked Parcel because it needed almost no configuration and handled cache busting on its own, so the engineers could consume the library without learning a build system first.

An odd problem I discovered was that designers spent a huge amount of time understanding what they were building, but spent very little time naming layers in Figma. This was a challenge, as I was working against a deadline; after explaining, the designer was able to deliver layers with descriptive names. We could still work on the language together, but it saved a great deal of time.

Write the vocabulary before you write the components

I built a library of 50+ reusable components from the design team’s Figma files. Semantic HTML, styled with Dart Sass, Bootstrap underneath as a base layer. I built on top of Bootstrap rather than overriding it, because override chains are how a stylesheet turns into a haunted house. I set the library up with Parcel so it could be built once and consumed by any application that needed it.

Two decisions did most of the work.

Markup first, styling second. Every component was defined by its HTML structure before anything about how it looked. That sounds pedantic until you notice what it does: it turns “is this right?” from an opinion into a check. An engineer could look at their own markup and know whether they had built the component correctly, without waiting three days for a design review to tell them.

Documentation shipped with the component, not after it. That decision did not land the way I expected.

Most of the web team came from Drupal and WordPress. They had never worked with compiled CSS or a JavaScript build step, and Parcel’s cache-busted filenames looked like noise. They wanted plain CSS they could open and edit. Which works, right until the files get large and the site gets slow.

I picked the cleanest bundler I knew. I come from a startup background where efficiency and performance mattered. Leadership approved my solutionI wrote and maintained all documentation and trained the team how to set it up and use it.

The library was the easy half

Here is the part nobody warns you about. You can build a perfect component library and watch it sit there unused.

The engineers I needed to adopt this were University Java developers who were already learning a new framework. Handing that team a rulebook from the design side would have landed as one more thing on a full plate, from someone who had been there five minutes.

So I did not hand them a rulebook. I worked the tickets. Over the engagement I went through more than 125 Jira issues inside their own Agile process, translating Figma prototypes into semantic React and Next.js components alongside the people who owned that code. Same queue, same standups, same deadlines.

That is the whole trick, and it is not a clever one. If you want a standard adopted, be the person who makes following it cheaper than ignoring it. Nobody adopts a rule because it is correct. They adopt it because it saves them an afternoon.

The accessibility standard that changed how I work

ICPSR already had a strong accessibility practice and a team behind it. I did not introduce it. I inherited it, and it changed how I build permanently.

I learned that Product Managers might ignore accessibility if the Owners were no invested in it. That’s where I determined if the developers were aleady coding with accessibility in mind, I would not have needed to fight for it in our weekly sprints.

What I contributed was moving it earlier. Semantic structure and keyboard behavior went inside the components themselves instead of being checked at the end of a project. That distinction matters more than it sounds. Accessibility enforced against a deadline is a negotiation you usually lose. Accessibility built into the component every team already uses is just what the product does. It mattered most in the dense data views, which are where accessibility falls apart first and where a research archive spends most of its time.

The advocacy came later, after I left. In 2023 I spoke at Ohio DevFest and Michigan DevFest, telling new and self-taught developers to pick up audit tooling and learn semantic HTML early instead of bolting accessibility on at the end. In 2026 I gave “Eight Surprising Facts about Web Accessibility” at the Detroit Pride Innovation Summit. The talk I am writing now is “The UX Cost of Security: When Authentication Breaks Accessibility,” about what happens to real people when CAPTCHAs, short session timeouts, and custom OTP fields get between them and the thing they came to do.

I showed up at that contract as a developer who knew the rules existed. I left it as someone who argues for them in public.

TODO Links or slides for any of these. A talk is checkable in a way a resume bullet never is. If the DevFest talks have recorded titles, use those instead of my description.

What changed

  • 50+ documented components in the shared library
  • 125+ Jira tickets worked in-sprint
  • 67 into the 90s on Lighthouse performance, after finding and removing 12 bottlenecks

The numbers are not the interesting part. The interesting part is that the design team and the engineering team finished the engagement using the same words for the same things, with a library that made the correct build the easy one.

TODO, read this one. Your resumes also claim an 80% increase in frontend velocity. I left it out on purpose. A resume bullet gets skimmed. A case study gets interrogated, and 80% is exactly the number someone asks you to derive on a call. If you can show the math, put it back. If it was an estimate, leave it out. The other three are stronger without a soft one standing next to them. Same test for Lighthouse: know which pages, know what changed.

What I would do differently

TODO, do not skip this. It is the section experienced hiring managers read first, because it is the hardest to fake. Two candidates from what you have told me: pull the engineers into defining the components earlier, instead of handing over a finished library. Or build the system in Figma alongside the code, so both teams edit one source of truth instead of one team translating the other.

The second is worth real thought. It is honest, it shows you know where your own practice is thin, and it turns a limitation into something you have already diagnosed.