I spent a good chunk of my career in various, let's say lone wolf, roles trying to advocate for the importance of design and accessibility--trying to advocate for the technical importance of some thing or another. But I think Heather's blog post really spells out why splitting front end design and development into separate disciplines with little communication was a bad idea.
- An understanding of the DOM and how the positioning of elements visually can be impacted by their position in the DOM (or vice versa)
- Accessibility in general, from the basics of color contrast, which has grown more nuanced with the introduction of the APCA to an understanding of common ARIA patterns.
- An understanding of native browser controls. It's important to understand when you're designing something that should use a native browser control and is just styled differently, or when you're designing something that requires a completely custom control which can greatly impact engineering complexity. "Just put it in a tooltip" is not always a simple remedy.
- An understanding of design systems. How to maintain visual consistency, and create patterns, and when it's ok to break those rules.
These are some, not all, of the core concepts of web design. We don't call it that, anymore, but that's what it is. These are all things I would sum up as deeply technical knowledge and someone needs to know it if you're going to build a good website. If you're a front-end developer, you've probably experienced one of these gaps in a design you've been given. And if you're unfortunate to work in an org that throws design over the wall, you've probably experienced quite a bit of churn trying to rectify those gaps. So now the thing that is built is based on a poor design.
- "We would have caught this sooner if engineering was more involved in the design process".
- "We would have designed this differently if we knew engineering couldn't handle it"
At what point do we stop and realize that we are setting our design teams up for failure?
This isn't even covering some of the other more misogynistic reasons Heather outlines for why the discipline was largely sidelined by other engineers to begin with, but the above are some of the things I found frustrating over the years.
The article hits close to home for a good chunk of my early career journey. Part of the blame is on me for my inexperience and not effectively communicating why some of these needs and ideas were important, but it also wasn't without someone up the chain wanting to ignore my concerns in favor of speed.