“Should designers learn code?”

This question is equivalent to an existential crisis and is heavily debated in the design community. There are conflicting views especially with the #NoCode or #LowCode movement backed by powerful interface tools like Webflow.

Nonetheless, it is undeniable that many employers prefer designers who have knowledge of at least HTML and CSS, as they appear more often in job descriptions.

Code feels daunting and foreign to non-engineers. Coding knowledge is built in layers in which understanding the foundations is imperative to advancing to higher levels of abstraction.

I felt this discomfort, but knew that if I wanted to be competitive and improve my collaboration with developers, I had to try.

Baby Code Experience

At first, I took baby steps, learning HTML and CSS using FreeCodeCamp challenges and following the projects they offered. The projects were difficult to conceptualize as I had yet to understand how properties covered in the tutorials connected as a whole.

I decided that I’d just copy sample projects line by line in CodePen to visualize how properties displayed and worked together in a full webpage.

This progression quickly stopped as I still couldn’t conjure webpages from recall. Knowing that my learning would solidify with more practice, I decided to sign up for a volunteer project as a frontend developer.

The team I worked with knew my proficiency and was willing to teach me as the project progressed.

Knowing that I was responsible for all the HTML and CSS for this D3-focused web app made me incredibly nervous, but the team’s leniency and willingness to guide me cultivated the perfect learning environment to learn code quickly and more deeply than isolated challenges.

The established responsibility, social pressure to create quality work, and permission to fail propelled my desire to learn. My job was to complete five web pages as best I could: a landing page, sign-in page, input form, sidebar for the D3 map, and FAQ page.

I supplemented my trial-and-error work with articles, Learning Web Design by Jennifer Robbins, and endless questions to my developers and engineer boyfriend.

It was only when I wrote code when I learned how to ask better questions that informed my strategy and understanding of how web pages worked.

Improving designer-developer relationships

It is essential for companies to preserve “engineering hours” because of how costly they are in time, money, and effort. It is in the designer’s and the company’s best interest to optimize handoffs and communication to save resources.

Though my final code would still be considered novice, I gained valuable insights of what developers want, how they view and use design, and nuanced challenges that could be avoided in designer-developer handoffs.

Designers can preserve resources by considering developers as users, understanding their language, and collaborating with them at the beginning of the design process.

Here are a few key insights I learned from my experience.

1. Developers see in negative space.

When a designer creates a mockup, they are focusing on the elements like copy, buttons and components. If you are adding an image to your screen, you are manipulating the image.

However, when developers use that image, they are looking at the negative space around the image and thinking about where it falls in relation to the full page.

Does the image need to display at max-width or render 60% of the screen?
How many pixels from the top is this image?
How much padding is around the image?

These are questions that come up when implementing a design.

2. Understand responsive design and specifications to deliver assets efficiently.

As a designer, I should know:

What responsive web design (RWD) is
How assets change between screen types (Ex. mobile, tablet, desktop)
Specifications such as timeline, constraints, units and file formats

Responsive web design is,

“a web development approach that creates dynamic changes to the appearance of a website, depending on the screen size and orientation of the device being used to view it.” (Nielsen Norman Group).

Developers view RWD in the form of grids, frames, and pixel breakpoints, or exact pixels of when elements change with screen size. Designers need to be detailed in specifying what assets go with each screen and how they change per screen.

Understanding project specifications seem obvious, but it’s worth mentioning because of how costly its ignorance can be. Knowing what we have to work with allows us to be strategic to prevent mishaps and inefficiencies.

For example, images were the bulk of my headache when coding, because I didn’t understand that files needed to be a certain size and in SVG or PNG to render clearly.

For images to render responsively across screen types, designers should deliver assets that meet the file format and file size requirements.

Hard-coded anything does not produce responsive design. It is best practice to use relative units like SVG and PNG instead of absolute units include JPEG which can be pixelated when scaled. The same goes for typography where relative units like em and rem are preferred over hard-coded pixels.

Designers can add value by initiating conversations with their developer to establish these finer details before designs are deployed.

3. Focus on style consistency.

The more consistent the styles (colors, typography, and other UI elements) are throughout your designs, the better. Developers implement styles by specifying classes (or group labels) that are given visual properties shown in mockups.

For example, a form label has the color #7B7B7B. If your developer knows that all text related to the form has the same styling, she can implement this strategically by assigning multiple classes to those visual properties. This saves time because less code needs to be written.

If she isn’t aware of these patterns, then she may waste time writing separate code for each class. This inefficiency is equivalent to designing mockups without preset color styles, manually color-picking for each element.

The more apparent you make these patterns throughout your design systems, mockups, and notes to developers, the quicker and more efficient it will be to code.

4. Thorough documentation matters.

Documentation of button states, interactions, unique use cases, examples of when to use components…these all must be coded, thus made aware of your developer.

Though perfect consistency is the aim, there are times when designers need to break styling rules to fit nuanced use cases. Clearly communicate these styling outliers.

Providing information upfront will give developers the context they need to make design decisions that solve their own problems while aligning with your design vision.

5. Collaborate early and often.

Having an open dialogue early and often builds a camaraderie that is useful in times of need. I should have formed a better relationship with my team’s designer so the designs would reflect both our visions.

Though I was in charge of developing, I ended up fixing the designs myself because I felt uncomfortable reaching out to him.

As a designer, you are part of a team of experts contributing towards common goals. Understanding what goes into the development process, the needs and constraints of your colleagues, and how they see and speak is powerful knowledge that enables your effectiveness.

Though still early in my coding journey, I find code rewarding and empowering. I advise designers to lean into the discomfort and discover the magic behind coding a design to life.