🔥 Hot Take: designing for the web is still new to us.

Designing for the web is a unique form of design that’s unlike anything else that designers worked on prior to 2000. Before then, there was no such thing as a web “design,” as much as there were just “websites,” and this is evident if you look back at early websites (anybody remember the glory days of GeoCities?).

Put into that context, it’s not necessarily surprising that design for the web is still a challenging arena: designers have only had < 20 years to get accustomed to it. Thinking about how to design for a medium which is fluid (it can be viewed on any device with varying screen sizes), interactive (you don’t just look it, you engage with it) and interpretive (not every browser behaves the exact same way) has been a seismic shift in the approach that designers must take for their work.

Since web design is a meeting of form and function, it can be challenging for designers and developers to execute the vision without compromise, as opposed to say, sending the PDF to the printers. Elements of the design that seem easy are sometimes not so simple to make happen across all browsers and all devices and there can be more factors than you would think that have to be considered for something as minor as a background image! And there’s no real way for a designer OR a developer to know all these scenarios, thus it should be a collaborative process. This speaks to the unique nature of the web; as there aren’t that many mediums out there that require such intimate collaboration and interaction between the design and the technology.

How does a design become a website?

When you provide your design to your development team, in whatever format you choose to do so, the developer is going to begin breaking it into pieces that will be re-purposed in the development workflow.

These elements will fall into three main categories:

One of the more challenging aspects of web development is that there can be many paths that can lead to the same result, and there’s no “right way” necessarily to do this. Every design is different, and a strategy that a developer uses on one design, might not work for another design. The process, though, is the same: we review each section of the design and use something from one or all of those three main categories to “re-create” the design in the browser. I affectionately refer to this as the “interactive design process”.

We’re going to look at each of these categories a bit deeper, and give some context and examples of what it means to make web-oriented design decisions.

How does a designer affect the code?

This is likely the question on every designer’s mind at this point. We’ve established the unique challenges of designing for the web and how a developer will translate a design…but where does this process break down ending in a disorganized mess of “spaghetti code”? While the developer has a leading role in the end result, there are significant ways that a designer will set the developer up for success (or not). Let’s dive into the main areas, along with some examples, that can make the goal of clean code clearly attainable or increasingly impossible.

Using a Grid

The use of a design grid is the foundation of a solid web design, and actually goes back far before web design was even a thing. While not required by any means (and we’ve developed plenty of sites without them), using a grid can start the design off on the right foot, establishing a baseline for the designer and the developer.

It does this by:

Establishing the dimensions of the layout and the content (which is often more narrow than the width of the overall design)

Providing the developer context of each element (e.g. this single element is two columns wide) and have that equate directly to a written line of code (below is actual CSS Grid code!) grid-column: 1 / span 2;

Allowing the designer to have creative freedom, without worrying about disregarding the medium they are designing for

Helping the designer to understand that almost all items in web design are rectangular or “blocks”, unlike print (which allows for placement of design elements without restriction)

How It Helps:

While CSS Grid Systems have been around for a long time, CSS Grids are now natively supported in all major browsers and as far back as IE11. Using a grid will allow the developer to use the latest and greatest tools for layout, will reduce code bloat and ensure a much higher likelihood of a pixel-perfect match of the finished website to the design.

Creating a Style Guide

While using a grid is a great first step, using one doesn’t guarantee the design will be web-ready. It’s still very important to establish consistency around the width of the content, spacing between elements, typography attributes, etc.. Occasionally we come across some designs where each page design/template has different spacing between headers/copy, random content widths, random selections of font sizes and generally a lack of any kind of “reusable” elements. In the print world, this would not matter, as every page of a brochure could be entirely unique and there’s no additional considerations. In the world of web design and development, this approach prevents the developer from creating a “system” out of the design and requires each page to contain unique code. At the most fundamental basis, there’s nothing inherently “wrong” with this, and designers want to have that creative freedom to style the layout however they think is going to be the best fit for the design’s goals…but if clean code is an additional goal, this can be counterproductive.

When approaching a web project, designers should try to create a “style guide” that will establish the design’s global styles, which can include all the various elements around the site, along with their variations and attributes:

Typography Hierarchy (Headers, paragraphs, block-quotes, list items etc.)

Buttons and Links (and hover effects, too)

Paragraph and Headers Attributes (margin, leading, tracking)

Misc. Design Accents (additional illustrations, icons, graphics, or typographical treatments)

How It Helps:

Developers have a term for this approach in the industry: DRY (don’t repeat yourself) and it’s something that any solid developer should be striving for. If you use consistent dimensions for all the various design elements (and the style guide will help establish this), the developer can create a “formula” for the site, as well as make things modular, reducing the amount of repetition in the code that we need to write to bring the design to life. This formula also can easily accommodate global changes that might happen down the line, such as a header style being changed site-wide. And the double win is that while code will be clean, the design will also be more consistent, as well.*

*And while it’s expected that parts of the design will sometimes veer outside of the established style guide in certain areas, using one will ensure that it doesn’t veer too far or too often, where the consistency (and the code integrity) would be sacrificed.

Using Web-Ready Images

It’s well established that good (or bad) imagery can make or break a design. To complicate matters, responsive web design has now been a factor to consider when incorporating images into the design. We’ve come across many instances where the designer:

Didn’t use high resolution images (which resulted in stretched and pixelated images on large, and Retina, screens)

Used images that worked great in the desktop design, but didn’t consider how they would look on mobile devices

Used rasterized assets (such as icons and logos), rather than their scalable counterpart, SVG

To avoid these problem areas when incorporating images into your design, here are some guidelines that should be followed:

Source High Quality Images

Don’t skimp on the sourced images, and pay for them if you need to. Obtaining the highest quality images will ensure the developer is furnished with what they need to ensure the images look good across all screen types. The rule of thumb is that you can always scale down an image without any quality loss, but you cannot scale up.

Think About Your Images Responsively

When placing images, we’ve seen designers often consider the desktop design and the responsive views as an afterthought (or sometimes, not at all).

Consider this example:

This layout is designed solely with desktop in mind: the copy is placed to the “dead area” of the image on the left. What happens when the copy can no longer fit in that space because image has become too small for that? If the copy goes full width, it will become hard to read and cover the person’s face. When we bring it to everyone’s attention, the quick remedy is the designer will create a “mobile specific” image to simply put in place of the desktop image for smaller screens. What they might not realize is two things: 1) that means double the bandwidth (two images) is now required to load that single element and 2) there is additional code that needs to be written for that specific section to make that happen*. There’s no real silver bullet on this point, because it’s so subjective to the design, but the gist is: be aware of the fluidity of the design when it comes to incorporating images into it. Ideally, the goal is to create a design that scales with the images, hopefully without the need of swapping image files.

*While there are ways to circumvent the first option, and only serve mobile images to mobile devices, it comes with a number of layers and caveats to consider.

Use SVGs

Scalable Vector Graphics (SVG) is a file format that allows the image file to scale without any loss in quality. In addition, it also allows for a lot of opportunity for animation and interactivity (such as hover effects). Using SVGs instead of rasterized image file formats (JPG, PNG, GIF) allows for smaller file sizes and out-of-the-box Retina support. Proper use of SVGs will enable faster load times and richer interactivity, and prevent the use of specialized code that would normally be needed for Retina/high DPI screens.

Making mindful choices about the imagery used in the design, and how that imagery is going to eventually be translated across the multitude of form factors and devices, can reduce the need for duplicate images. In addition, using SVGs for logos and icons wherever possible will ensure that the graphics are scalable and “Retina-Ready”. In both cases, the ideal goal is to avoid additional layers of code that would swap images. While it still sometimes has to happen, it should be a last resort.

Bonus: Picking a (Web) Design Program

A common question we are asked is what the best format is to receive the design artwork in. We’ve used everything from Illustrator to PhotoShop to InDesign and someone once even sent us a static JPG only! For many years, PhotoShop was the de-facto standard that developers wanted and expected. Over the last few years though, that landscape has changed dramatically, as web design has become a more prominent form of design, and with the acknowledgement that developers are integral to the process of web design. Newer design programs are far superior to Adobe’s original Big Three (Photoshop, Illustrator, InDesign). We now have a host of new platforms that were created with the developer in mind:

Adobe XD

Sketch

Figma

WebFlow

Macaw

Since these programs were created with the intention to be used specifically for web-oriented design projects, they come with an array of features that developers thrive off of: quick asset exports, developer spec previews, font and color variables, built in measurement tools, integrated grids…the list goes on. If you are a designer and still using PhotoShop or Illustrator, this is a great time to review your design process and consider switching to one of the more contemporary platforms that will provide the developer(s) the tools they need to translate your design into a functioning website, without the struggles of trying to use the original print design programs for the web.

Collaboration is Key

A common theme that we hope is apparent, is that designing for the web works best when designers approach it with a sense of ‘modularity’, as inconsistency tends to result in convoluted code, and convoluted code creates problems when making future modifications to the code…and a potential nightmare scenario if another developer ends up inheriting it! Coming up with a consistent design approach and formula, thinking about how components can be re-used and re-purposed, and approaching the design with an understanding that eventually everything will have to be turned into a line of code, will help mitigate these situations. This mindfulness about the medium can enable the developer to come up with a matching formula when it’s time to code it.

We’re not suggesting that a designer sacrifice creativity in exchange for clean code, just as a developer shouldn’t have to sacrifice their coding standards just to meet a design vision. It needs to be a collaborative process between design and development. We recommend having developers review the designs before clients see them, as to identify potential problem areas that could begin to unravel the code even before it’s written. You could go one step further and bring the development team in as the design comes together to ensure the direction being considered is going to meet everyone’s standards (we’re often brought into wire framing and prototyping meetings before design starts, so we can help guide the process with technical direction).

The web, despite it’s ubiquitous presence in our lives, is still relatively new in the landscape of design. The Internet Of Things is now a reality and responsive design has elevated an already complex design process to a level that produces a staggering amount of variables to consider. But, we have the tools, and the processes are evolving, that will help bridge the gap between the form and the function – the designer and the developer – and that will aid in the collaboration of both.