Design and Dev Workflow
Throughout my ever-present research into design systems, I have come across several writings about the divide between design and development. Continuing to iterate on an internal design system at work, I have been going back through some of these and this is a collection of the parts that stuck out to me. The common thread that most of these articles discuss is the fact that historically design and development have usually been separated but with the way that the web has evolved there are benefits to trying to close that gap.
Part of it is that designers and developers are often organized into separate departments (sometimes with differing project management philosophies), but another part is that the concept of static mockups doesn’t quite cut it in the modern era of the web. Static mockups were never a perfect representation of webpages even in the early days but as the web has grown more powerful it’s gotten even worse.
The Gulf of Execution & Evaluation
Bert Bos describes this very well in an essay on W3C’s design principles:
If there are tools involved, as is the case when the world is the world of the Web, then the intentions have to be translated into actions that the particular set of tools is capable of. If the way a person thinks about a problem is different from the way the tool maker did, then this translation can be difficult: think of it as trying to move from one square of a chess board to an adjacent one when all you can do is make jumps with the knight. Norman calls this step the gulf of execution.
He then goes on to explain the other half of the process, the gulf of evaluation, where someone must try to translate the results of those actions back into their own mental model. Design tools like Photoshop and Sketch are a quite different way of thinking about two-dimensional design and while they can produce a result that can look similar to a single snapshot of a web page, there are many other factors that they differ on.
One handy practical resource for getting designs closer to the real product that is built in a browser is Front-End Principles for Designers, which is a nice little checklist for getting familiar with things like source order, performance, managing variation, etc.
Development is Design
Brad Frost talks at length about this idea in the fourth chapter of Atomic Design. In browsers you have so many other things to consider that are not possible to represent with a static mockup and really should be a part of the process from step 1: all manner of screen sizes, performance, interaction, motion, color/text rendering, device quirks, etc.
When you show stakeholders only static pictures of websites, they can naturally only comment and sign off on pictures of websites. This sets the wrong expectations. But by getting the design into the browser as fast as possible, you confront stakeholders with the realities of the final medium much sooner in the process.
I’m gonna stop myself here and summarize my thoughts on this chapter as “100% yes”, otherwise I would probably have to quote the entire thing. His whole Atomic Design book is worth a read, but especially this chapter.
Content & Display Patterns
Dan Mall has similar thoughts in an article about Content & Display Patterns. It can be very important to differentiate between these two types of patterns and front-end developers are a natural bridge for bringing them together, so it’s a great idea to get them involved as early as possible.
This allowed both developer and designer (TJ Pitre and me respectively) to work simultaneously, assembling all the parts in our own ways and riffing off each other’s work. Watching this process unfold revealed another important insight: when thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
As Brad mentioned, a front-end developer will be thinking about these things from the perspective of how it will work in the browser (how we might construct HTML snippets, manage CSS complexity, performance, etc). It makes a lot of sense to begin thinking about these things earlier on in the process.
It often falls to the developer to see through the pixels of a comped element to find the actual design pattern. This is why development is design. When I’m coaching agency and product design teams, I often recommend that they move their front-end developers on to the Design team instead of the Engineering team, because I need them to act more like architects than construction workers. (I even recommend ditching “front-end developer” as a title and starting calling them “designer,” but that’s a story for another time.) For most of my projects, I allocate way more time for writing HTML/CSS/JS than I do for in-Photoshop (or -Sketch or -whatever) time, because that’s where the majority of the work—the decision making —happens.
This matches up pretty closely with my experience doing front-end development on various projects over the years. The benefits of a shift towards more closely aligning design and development are pretty apparent for the modern web landscape; the main question is how can a move towards a process like that happen successfully?