Designing through Development – Should Designers Code?.

Should designers code? It’s a question as old as time. Or at least as old as the early 2000s, when web and digital design started to overtake print.

Full disclosure: I don’t have the answer. I only have my own experience as a designer and developer (who grew both skills alongside one another) to go by. But I am convinced that my ability to empathise with users, to create flexible and consistent visuals, to design for easy maintenance and future flexibility, and to collaborate with teams would not be what it is today without learning development.

Thinking Inside the Grid

The first thing I realised back when I first put fingers to keyboard many years ago and started writing (bad) HTML and (worse) CSS was how everything, whether explicit like a card UI element or implicit like a paragraph, was a rectangle.

Non-coding designers certainly do understand the grid, but learning how the pieces fit together, nested within one another, and how I could use CSS to force things outside of the grid taught me the value of working with the browser’s building blocks when I made design decisions. By making some daring design decisions, I discovered first-hand when it was reasonable to push something outside of the document flow or when I’d designed myself into a coding nightmare when a more build-friendly solution would have worked just as well. It made me respect why we should design the way we do.

Practising Dynamic Design

I no longer had total control, but eventually the realisation was liberating.

In print design, a designer can be precise. A two-page magazine layout will always look the same no matter if the consumer is reading it in London or NYC. This world of absolutes was my first experience with design, so coming into digital was very frustrating at first! Internet Explorer, Chrome, Firefox, and Safari all had their own ideas of how to render things. And let’s not even think about what happened with email newsletters when they hit Outlook. Furthermore, different screen sizes squished everything together.

I no longer had total control, but eventually the realisation was liberating. Instead of designing layouts, I was designing experiences. It made me more conscious of how layouts changed between screen sizes and how I could keep things as consistent as possible across different browsers and platforms. As I became more attuned to the transition between different states of a web page, this way of thinking morphed into an interest in interaction design and helped inform my wireframing and my designs for different page states.

Some Love for the Devs

Now, back to how bad my HTML and CSS used to be. Getting better at both of these, and then learning and improving my JavaScript, has increased my appreciation for the hard work that developers do. I can empathise with their difficulties and restrictions, not just sympathise. This shared experience of coding challenges, skill growth, and in-group language has brought me closer to the developers I’ve worked with over the years, as well as my fellow creatives.

From a more practical perspective, when there are technical constraints that impact the UX or UI, I can participate in discussions with developers. Moreover, I can suggest alternative solutions that keep our restrictions in mind while still looking out for what’s best for the user. In other words, I can evaluate the technical and user experience trade-offs simultaneously.

Reusability and Repetition

There’s a core software development principle known by the acronym DRY: Don’t Repeat Yourself. As the name suggests, it aims to reduce redundant code, creating a leaner codebase that’s less bug-prone and easier to maintain. I’ve found that DRY can be applied to design in a couple of different ways, making it just as useful in this part of my work as it is in development.

File Management

Using Sketch files with logically organised symbols that correlate with tidy, component-driven SCSS files and reusable Angular components, means that everything is engineered for seamless design and development and, most importantly, a consistent user experience. A DRY Sketch file improves consistency because it’s easy to see which components already exist and how they’re used in different contexts. Consistency is one of the pillars of a frictionless user experience.

User Experience

Taking the DRY approach to user experience means designing experiences free of any cruft—overcomplicated or superfluous elements—that interferes with the user’s journey. It means questioning every decision and asking whether a solution is redundant or visually unclear, or perhaps whether a design pattern that already exists could be used instead.

And So On…

I could go on about how my appreciation for accessibility has increased the deeper I’ve gotten into coding, or how the big picture of crafting the user experience from start to finish helps me make decisions, or how I just really love doing both design and development, but perhaps I’ve already answered the question.

So, should designers code? Well, that depends on the designer. I know this designer should.