Moving beyond the idea that the designer and the developer on a web project are different people, and that somehow those are different things.
For a long time, websites got made with one person designing how it should look and one person developing the code that made it look that way.
A lot of times, this is still how things get done - one team makes static Photoshop comps, and hands them off to a team of developers who know stuff like whether React or Ember or Node or Ruby is the best thing. This can sometimes cause friction. The designer expects the website to look exactly like the comp, the developer writes a bunch of custom CSS and HTML to fit the design, and whoever needs to make sure the whole thing is WCAAG compliant spends weeks hating both of them. When the next comp comes down the line, it all happens again. For a big site, this leads to design drift, and a hugely tangled codebase that’s a nightmare to try and untangle.
This splitting of systems is an artificial one that’s sustained by organizational assumptions: we need designers, and we need developers. The thing about Design though - capital D design - is that it’s simply a method of deciding on a structure to accomplish a purpose. The design tools and methods one uses to accomplish good design is always in tune with the thing being made. A building doesn’t go from painting to construction drawings, nor does a car go from modeling clay to racetrack. The clay and the paint are very useful steps to start the process of design. They help us to be creative and loose and explore new solutions to the problems at hand. This exploratory work helps us to understand how a thing will feel in the world.
These initial drawings and sketches get translated into their final structures, and translation is a process that can enrich both what is being translated to as well as what is being translated from. Every precise moment may not align directly, since differences in context can have deep implications for meaning.
We turn our drawings into objects with all the considerations of the final materiality present. We can’t ignore the shape of the engine or structural code requirements, although our models and paintings certainly can. Design is provisional until the point at which it exists in the world, and when talking about the web even this isn’t any sort of ending. A website is its own sort of thing, with its own structure and requirements that need to be present and known throughout the entire process of design.
A drawing and a website will never look the same. This is mostly because a website isn't static. Because of this, what a website looks like is just a small piece of what a website is. A website is what it enables its users to accomplish, what its developers have to do to keep it stable and moving forward.
The best way to meet our goals as people who make good websites is to focus less on those drawings right away. Instead we should think more about simplicity and elegance than the detail oriented perfection of a jpeg.
Don’t get me wrong - the jpeg can be important. It shows us how we think we can solve our problems, a glimpse of how we want our website to looks and feel, and the tone we want to communicate. Through all this it needs to have to room to change and breath as it comes to life and become a real thing. Our drawings should not be on the level of “what does this look like” but “what problem does this solve and how”. At every step in the process we can work to make the real thing better, to solve new questions that arise as we move through the process of design / development – a process where there is no gap between those two ideas.
To design a website is to develop it - and as we develop a website we are constantly making design decisions. A designer cannot abdicate their responsibility to design by saying “well, my jpeg looked great.” A developer cannot abdicate their responsibility to a codebase by saying “well that’s what they wanted in the comp.”