But Shouldn't Push Code to Production
In the 1970s, AT&T commissioned Matthew Carter to design a typeface for their phone book. They wanted a typeface that could fit more characters per line without a loss of legibility, especially at smaller sizes. This would save them money by reducing the number of pages needed to print the book.
Carter knew that phone books are printed on cheap newsprint paper that doesn’t produce high-quality text. He also understood that ink spreads when applied to this cheap paper, especially at smaller sizes, which decreases legibility. All of this posed significant challenges for creating a legible typeface for AT&T’s phone book.
But instead of giving up in desperation, Carter embraced these constraints and designed for them. The resulting typeface, Bell Centennial, maintains legibility by having a tall x-height and large, open bowls. His true masterstroke, however, was designing “ink traps” into the letterforms. Ink traps are small notches in the letter that anticipate the spread of ink on newsprint. When the ink is pressed onto paper, the ink spreads into these traps. The result is a filled in letter that’s easy to read, even at small sizes.
Closeup of Bell Centennial by Matthew Carter. Source: Wikipedia.
Carter embraced the constraints of the medium and turned them to his advantage. His deep understanding of the printing process allowed him to make this leap.
The best designers understand these constraints, and design for them. To gain this understanding, you must know how to code.
But this comes with a caveat: designers shouldn’t write production code. They’re experts in the user experience, not frontend technology. They should be solving customer problems, not trying to write scalable, maintainable, and performant code. That’s a full-time job that requires dedicated professionals.
So learn how to code. Ink traps don’t design themselves.
Update 12/12/15: This article sparked a lot of questions about designers not writing production code on Designer News. I responded to a lot of them and attempted to clarify what I meant by that statement.
In summary, I wasn’t trying to draw a hard and fast line on what designers should do, or what they’re capable of doing skill-wise. Writing production code on occasion is fine. But what I have a problem with is if designers are expected to code everything they design. Those are separate jobs that should be handled by separate people.
Thoughts? Reply @jlzych