Web design is a bit like architecture in that it usually takes two teams to complete a project: architects — a.k.a. designers — and engineers. Construction projects are completely beholden to their materials. No wooden skyscrapers ever make it to production. No highway bridge is made from unarmed concrete. As such, architects must know the strengths, weaknesses, opportunities and pitfalls of most building materials, even if the material responsibility lie with civil engineers. 

So it is with web design. We are at the mercy of HTML, CSS, and browsers. Our best work plays to the strengths of this material, and we would struggle to produce anything that fundamentally contradicts the native properties of the web (though God knows we try). Web designers have a tremendous advantage over architects, however, in that their materials are equally accessible to them as they are to their engineering counterparts. Architects simply cannot build full-scale prototypes using any material at their desk. Web designers, on the other hand, have the whole catalogue at their fingertips — for free.

This immediacy results in crossovers. Whilst most of us are more or less one thing – either a designer or a developer – the boundary between the two is blurred, not only in terms of practical skills, but in delegation of responsibilities. Some things are obviously design, like typography or colours. Some things are obviously engineering, like APIs or databases. Other areas are less clear cut, and it's sometimes difficult to define where one profession ends and the other begins. Take performance and accessibility, for example. In all but larger projects with dedicated product owners and specialist evangelists, these considerations fall somewhere in between designers and developers. 

Clearly, designers have a responsibility to make decisions that are mindful of load times, like the number and size of images and fonts, and to address accessibility concerns like contrast, type size, and affordance. At the same time, these considerations amount to nothing unless the engineer is not equally mindful. Images must be optimised and served at different sizes to different devices at different bandwidths. Fonts and assets must be loaded correctly. Structures must be semantically coherent for people using assistive technology. The list goes on. So where does the responsibility of all the in-between bits lie? 

It's easy for designers – myself included, I shamefully admit – to wash their hands of anything outside of Figma and point to the developers, since they are in charge of implementation. The final delivery is code, ergo the final responsibility is with the coders. It is equally easy for developers – as I've also witnessed many, many times – to avoid responsibility by pointing to the specification or design sketches. The spec said nothing about srcset! The design file didn't include hover states! 

The truth is, of course, that the responsibility is shared. There is and will always be a host considerations that are neither design or development considerations, but web considerations. Perhaps, if we focused on how to collaborate on those considerations instead of delegating them, we would make better things.

Illustration by Lulu