We’ve been tightening up some internal processes at work, one of them being the design-to-dev handoff process. This is just a brief collection of thoughts for designers from the developer perspective.

We’re using Understrap for a lot of WordPress projects, which means we’re using the Bootstrap library as the basis of our design. While there’s some criticism that Bootstrap can inhibit designers by providing so much of the design ahead of time, I would probably disagree. The very nature of what a website feels like is what inhibits the design. Grids, columns, cards, utility classes- these things exist whether or not you use Bootstrap.

We’re all using the same HTML elements and for the most part, clients want to see a website that feels familiar (i.e. a navigation bar across the top, big hero area, etc.). If we’re talking about a radical design that veers from the standard platonic ideal of a website, then that’s a completely different project (and budget).

The same thing would happen if we switched from Understrap to a purely block theme. We’d be using the component library that the Gutenberg team has been putting together which, again, is basically just a very light skin on common HTML elements and UI patterns. There may be some other considerations consider how Gutenberg handles certain blocks, grids, or responsive controls (i.e. it doesn’t), but it’s still a framework.

Either way, what you do to those individual pieces of content (perhaps from a mindset like Atomic Design) is what makes modern web design. So the fact that Bootstrap is thrown in the mix is sort of irrelevant to this discussion. Regardless of what UI library is brought in, there just needs to be some system that organizes everything in a common language between the designer and the developer(s) on a project.

So here’s a few quick thoughts:

Developers like consistency

The best way to get consistency is a style guide- one page in the mockups that shows exactly how every element (headings, buttons, gradients, cards, etc) should look across the site. And then sticking to it.

Bootstrap generally offers things in three sizes: the default size and small and large variations. Need a button? Regular, small, or large. Using a drop shadow? Regular, small, or large. Keep the options limited and consistent.

A style guide that shows the example of each of those elements means a developer can go into the Bootstrap variables file and lock these in before actually building the unique elements. Knowing ahead of time what the “options” are and sticking to them is key to cutting down on custom CSS.

Developers are very literal

Imagine you have a 12 column grid and a pretty typical layout: a block of text on one half of the screen (6 columns) and an image on the other half (another 6 columns). Pretty common.

Now imagine that the image doesn’t fit exactly into the grid’s columns but sort of stops in the middle of the column. This is essentially a decision-point for the developer. Instead of matching the design, they’re now tasked with interpreting the design. Why doesn’t this line up? Is it intentional? Where does the extra space come from- padding, margin? Is it in pixels or more relative units? Is it only for certain screen sizes?

Something that doesn’t quite line up with a column creates an interesting problem with a number of solutions that the developer will burn time wading through- not to mention the extra code they’ll now need to write for an element that probably required NO custom classes or CSS at all.

Of course the best thing to do would be to go straight to the designer and get everything cleared up, but that’s not always possible. The better goal is to limit any vague decision points because developers are very literal and will often just… build something.

(Many) Developers are not designers

Clearly this is not always true. Many of the great developers I know are also great designers. I’m just not one of those developers. I’ve dabbled in design and quickly learned it is not my strong suit. So I leave the design up to the professional so I can focus on the things that are in my wheelhouse- efficient code, page speed, SEO, accessibility- all the things that swirl around the design process but need to be successfully executed during development.

If a developer has a “design suggestion,” they most likely have a “development suggestion” that needs the design to adapt to accomodate. So take it with a grain of salt and help us verbalize our questions in a way that brings us all together on the same page. Because a question about “why” something is designed a certain way is probably not a criticism, but instead a genuine chance to improve the final product and the overall process.

So that’s a few quick thoughts for designers to help out developers. I’m sure I’ll have more as we work through this process. On that note, I’d love to see the opposite article: Thoughts on developing for designers..?.. If one exists, send it my way.