Back to blog

Designing With Code

With an increasingly complex array of platforms and screen resolutions, it’s time to embrace the creative capabilities of HTML5 + CSS3 and make development part of the design process.

While I’ve spent most of my days in the creative department, I actually started my career as a developer. I was 16, and having discovered the WYSIWYG editor in Netscape Navigator Gold, I had taught myself the basics of HTML. I was inexperienced and couldn’t build much, but I did manage to make something that landed me a job building websites. I enjoyed those days working with code, but at night I found myself playing with Photoshop. Design seemed to come more naturally and I eventually moved into the creative department as a Graphic Designer.

That transition was a very binary move. If I was to be a designer, I couldn’t be a developer. There was never an option to do both. Instead, I’d spend hours designing static pages in Photoshop that would simply be handed to the developers for reproduction in HTML. There was rarely an opportunity to collaborate throughout the process. Hell, we barely spoke. Sometimes we weren’t even in the same timezone, let alone the same room.

That was 16 years ago, and not much has changed.

Throughout my entire career, every company I’ve worked at has separated designers and developers into separate departments, each focused exclusively on their discipline. And while this practice was understandable when HTML was unsophisticated and we were building static websites for 640×480, things have obviously changed. HTML5 and CSS3 displayed across a spectrum of resolutions, running on desktops and laptops and tablets and smartphones. Technology is continuously reshaping the canvas on which we design, and yet these two disciplines continue to be treated as disparate.

Methodologies like Agile and Lean, paired with tools like Pivotal and Basecamp have certainly helped close the gap between the disciplines. We’ve embraced each to varying degrees at Teehan+Lax, and last year we also reorganized the company into cross-functional teams, completely eliminating our creative and development departments. We greatly improved collaboration by making dramatic changes to our process and structure, but I don’t believe we’ve gone far enough. Our designers and developers may now be physically sitting closer together, but there is still a significant chasm between the two.

Photoshop

The problem with Photoshop is that what’s being created is actually a fiction. It somewhat resembles what the final product might look like, but it’s not real. Layout and typography decisions are made that often don’t translate accurately to HTML. We spend hours designing for a medium that’s interactive and responsive, but we start by producing mockups that are static and inflexible. If great design is not only aesthetics but also how it works, then it’s time to make development part of the creative process.

Of course Photoshop still has a role, but it’s now possible to move to working code much sooner. Instead of iterating through creative concepts in Photoshop, designers should increasingly be exploring their ideas in code. They need to be intimate with the technology they’re designing for, and they need to be comfortable working within it.

Which all sounds great, but from my experience, most designers can’t code.

Yes, some are indeed quite capable and others have at least a basic understanding of HTML & CSS, but I doubt many designers would describe themselves as being adept. We have an incredibly talented group of designers at Teehan+Lax, but if we’re going to have them manipulating code, we need to get them proficient with the technology, and we need to rethink our creative process.

Education

Starting today, all of our designers will begin a series of ongoing training courses for HTML & CSS development.

We evaluated a number of solutions (Lynda, Codecademy, etc.) but ultimately settled on Treehouse. With their group options, breadth of content and code challenges, it was the perfect fit. We’ll start with the basics and focus the presentation layer, with the goal of getting each designer as comfortable with box-shadow as they are with Save For Web. Of course, I expect the vast majority of education will happen on-the-job, but this will at least ensure we’re starting on common ground.

Development also requires a proper toolset, so each designer will be equipped with the following:

  1. A local development environment. We’ll keep it simple and install MAMP PRO on each of their machines.
  2. Access to our Git repositories (and a lesson on Git itself). I’m not expecting many will be clamouring for the CLI, so everyone will get a copy of Tower instead.
  3. An IDE of their choice (but I’m going to go out on a limb and say that most will start with Coda).
  4. A copy of CSS Hat to better utilize Photoshop in this new environment.

 

Process

Our current process is somewhat of a cocktail of tools and methods. Most projects begin a little like waterfall and end a little like Agile. But we always start by creating static mockups. Over the years we’ve made an effort to get to working code sooner, and today we’re going to further streamline this by having our designers & developers collaborating in a shared codebase.

On day one, I’m not anticipating a dramatic change to our process. We will still create high-fidelity mockups in Photoshop and our developers will still translate those mockups into HTML. But instead of providing visual feedback in the final stages of development, our designers will modify the actual CSS themselves. They will be responsible for tweaking and polishing the final product until they feel it’s perfect in Chrome. From there, the developers will still be responsible for ensuring cross-browser consistency.

Looking into the future, the gap between the groups will continue to blur. I suspect we’ll often still need to create a set of preliminary mockups, but our teams will be increasingly working through design challenges in the code itself. This will be a highly collaborative process, with the developers being primarily responsible for JavaScript and the underlying markup for content and structure, while the designers will be increasingly responsible for the presentation markup.

We believe great design fuses form & function to create things that people actually want to use, and Teehan+Lax is committed to making this philosophy a fundamental aspect of our process. It’s not going to be an easy transition, but I’m incredibly excited to see where this path takes us.


Jeremy is a Partner at Teehan+Lax, and can also be found at @jeremybell
Photo by Tamar Levine

Jeremy Bell More posts by Jeremy Bell