As tends to happen with experience, my convictions have morphed over the course of my career. As a graduate student studying interaction design at Carnegie Mellon University (CMU), I was of the opinion that designers shouldn’t need to know how to code. We should have tools that give us complete freedom to create without requiring knowledge of the technical bits that are necessary to realize our visions. Looking back at my younger self, it seems hypocritical. I had already learned the technical process of offset printing—not enough to set up and run a press, mind you, but enough to know the difference between process and spot colors, how to specify them, and how to design a brochure with only two colors to keep the cost down. I knew that I had to include an extra margin if I wanted an image to bleed off the edge of the page. As it turns out, I had to learn a lot about the production process to be an effective graphic designer. Why did I not expect to have to do the same to effectively design for the web?
I was quickly disabused of the notion once I took a job with a software development firm where I was expected to hand over HTML that developers could cut and paste into their Java server pages (JSPs). My screens may have looked fine, but the what-you-see-is-what-you-get (WYSIWYG) editor I was using generated terribly ugly code. So it was that I began down a path that resulted in the book you hold in your hands now. But it isn’t just a book about code. More important than learning how to write clean Cascading Style Sheets (CSS) is learning how to integrate with your development team.
You see, when I was first hired by that small software development firm, I was set to work on a complete, ground-up redesign of their flagship product. This was to happen in parallel with the development team rearchitecting the product. The company was young, and I was inexperienced. I was advised by another designer who had been with the company since its inception to not show my work to the developers until I had polished it to perfection. I’m sure you already sense the train wreck that was coming. Sure enough, after months of brainstorming new features and iterating over pixel-perfect screen mockups, I presented my work to the developers, only to be told, “Hey, that looks great, but our architecture assumed the same functionality and a similar interface to what we have now.” They were too far down their side of the tunnel to come back for me, so my fully designed and specified user interface (UI) was shelved. I learned a valuable lesson the hard way, and since then, I’ve worked diligently to integrate myself tightly as part of the development team. Doing so has paid great dividends, and I’d very much like to share them with you.
I’ve now been working for that same company over 13 years, during which time I’ve been able to merge my design process with that of the developers. I use many of the same tools they use for task assignment, issue tracking, version control, and documentation. Where once upon a time I would hand over my designs to the developers for implementation, I now participate in implementation, ensuring that every detail of the design is translated correctly by contributing directly to the production code base. And that brings us full circle. If you want total control of your design, from its first inspiration to the day the finished product ships (not to mention future revisions), you have to participate in the entire development process. That means you should be able to write production-ready HTML and CSS. That’s why I decided to write a book that is one part down-and-dirty code tutorial and the other part ideological process and collaboration. Both parts give practical advice, some of which you can put into action immediately, and some you can begin to plan and build toward.
One person who has the skills of a visual designer, an interaction designer, and front-end web developer is often referred to in our industry as a unicorn—a magical, mythical creature and the object of many a great hunt. If you look at natural history, you’ll find many plausible origins for the legend of the unicorn. You’ll also find a number of creatures that, while not matching our perfect envisioning of a unicorn, are nonetheless creatures with four legs and a single horn. I posit that there are actually quite a few designers in the workforce who meet the base-level description of a unicorn; they just don’t have the opportunity or direction necessary to meet their full potential. Perhaps you are one of them? My sincere hope is that this book will be the incentive that leads you to take that next pivotal step in your career.