Seven years ago I was making the transition from a general graphic design and art direction background to web and UX. I had taken a UX certification course, complete with capstone project and mentorship from a veteran Product Designer, and I was sharpening my HTML/CSS skills. Since then, I have been managing a robust and custom design system for a large and highly-regulated B2B company, developing scalable landing page and email templates for marketing campaigns, and designing interfaces for the web experience. Knowing what I know now, there are things that could have made my work better earlier on in my journey.

Accessibility goes beyond the visual—and it’s a shared responsibility.

When I started out, I thought my job was to handle the visual side of accessibility: text size, hierarchy, color contrast, semantic structure. I knew it went deeper than that, but I assumed the rest was development's problem and something that would get handled after spec handoff. I was wrong about that, and it cost us more back-and-forth than it should have. 

What I know now is that designers who understand every level of accessibility — not just their basic responsibilities — dramatically reduce the margin for error. In my specs today, I outline ARIA labels, all semantic elements, keyboard navigation order, and screen reader behavior. I explain why each decision meets compliance and what to avoid. To some that might seem like overkill, but it aligns design and development expectations from build through shipment. Accessibility isn't a handoff problem. It's a design problem first.

Take initiative early on in learning interactive motion design.

Working on a lean team (1-2 designers including myself) meant a relatively high volume of work and the pressure to move onto the next project. The first thing that tends to get cut in these situations isn’t quality, but rather anything that feels like a nice-to-have. For our team and organization’s objectives, that was interaction design beyond the basic UI feedback. Our elements respond when a user clicks, hovers, or tabs to them, but not much beyond that. 

I would tell my younger self to make exploring interaction design in my personal time a priority, so that when the opportunity did arise that I would be ready. The tools available now make it easy. I was already using Figma prototyping to show animations and interactions in my specs, but that’s not the same as being able to execute. I’m currently learning how to create Lottie animations on Lottiefiles.com (they have great education and onboarding resources) and I’m planning to dig into WebGL next using Unicorn.studio.

Learn more about what happens in your designs after handoff.

There’s the saying: you don’t know how much you don’t know. That feeling has surfaced for me repeatedly over the course of the past 7 years. Each time I think I’ve caught up and I’ve optimized my work processes, I would discover there was more to be done.

In my experience, a large amount of friction comes from the design-to-development handoff process. I would constantly search for ways to improve my spec files, annotations, handoff presentation, etc. but still felt as if there were things I was missing. Well, a major cause of that was that I would create these incredibly detailed spec files without a deeper understanding of the developers’ needs. I was arrogant in my thinking that I was leaving out any room for ambiguity. In reality, I was still making decisions on their behalf, just invisibly. 

What changed things for me was using AI in my spec workflow to audit for accessibility gaps, edge cases, and interaction states I might have missed. What surprised me wasn't how much I'd been missing, but how easy it was to catch those things once I was looking for them. My specs started including ARIA labels, keyboard navigation order, screen reader behavior, and explicit notes on intent, not just instruction.

The result, even early on, was a noticeable shift in the quality of the questions I got back from engineering. There were fewer of them, and the ones that did come in were already addressed somewhere in the spec. That's a small thing on the surface, but it means fewer misinterpretations making it into production, and fewer rounds of back-and-forth eating into build time. I had known that spec handoff was an ongoing collaboration but I now know that I needed to continue learning their language and adopt a better understanding of how they build the designs.

But the deeper shift came from actually learning how our developers build. Our website is built in React, and while my early components followed the basic principles of component architecture (variants, usage states, constraints, and tokens) I didn’t quite fully understand why from the developers’ perspective. Now, I’m properly using boolean values to signify props that reduce CSS complexity, naming all the layers properly, and structuring tokens correctly within components using the [category]-[property]-[variant]-[state] convention.

Some of these things probably seem pretty obvious in hindsight. But every time I’ve discovered an area where I can improve or optimize my processes, I dive into it. That’s shaped how I tackle problems more than any single skill has. There is an advantage to working on a larger team where people push one another to grow. But there’s also something to be said for self-directed growth and the discipline of staying curious when no one is requiring it of you.