For the past two decades, the web has been a vibrant intersection of design and programming, a place where practices from art and engineering both apply. Though I’ve spent my career on the programming side – you don’t really want to see the things I design – I’ve loved the time I’ve spent working with designers.
Much of that time was frustrating, because I was frequently stuck telling designers that no, 1990s HTML couldn’t produce page layouts like QuarkXPress. The medium was different, with its own complications. However, as designers became familiar with the web, and found new ways to apply it, the conversations became richer and richer. Front-end web development became an amazing place where designers and technicians could work (and sometimes curse) together.
Lately, I’ve been enjoying shows that either span the designer-developer gap (like Artifact and Future of Web Design) or are primarily design-focused (like last week’s Create Upstate). Much as I love Fluent and OSCON, stepping into more design-centric venues sparks whole new categories of thought.
I like the puzzle-solving of programming, and the challenges of explaining how to identify and solve those puzzles. At the same time, I find that spending a lot of time programming turns my brain into a puzzle-solving machine, and changes the way I look at the world. Everything seems like an engineering challenge, to be reduced into smaller pieces and tackled with logic. Then that approach fails me when I have to communicate with humans or handle ambiguity, and I look for ways out of that box.
Design has some things in common with programming. Both have mathematical aspects, apply the word “elegant” to clean solutions, sometimes use component models, and use many of the same underlying technical tools. In both fields, the people most strongly attracted to the work often find themselves having to “scratch their own itch” and create projects that aren’t necessarily for work.
The differences, though, strike me as more important. Programmers spend their time trying to convince computers to understand or recognize something and in the end, do something. Designers spend their time trying to convince humans to understand or recognize something, and in the end, do something. That human audience gives designers very different priorities.
As a result, when I’ve worked with designers and gone to events dominated by design, I’ve found much greater willingness to look beyond a “problem”, narrowly defined, and consider broader context.
It’s not just context, though – it’s a bigger inclusivity. Designers and programmers alike complain about clients, but designers (in my experience) place vastly greater emphasis on conversation and cooperation. Designers are less surprised that readers and viewers may not understand, care, or like the results of a particular project, and more frequently recognize that response must be valued even if it doesn’t seem like “the right answer”.
Moving another layer beyond that, designers show far more enthusiasm for serendipity, for solutions that intrigue because they are broken, and for, well, fun. Even the most standards-obsessed hyper-modern designers seem unable to keep themselves from breaking out with an occasional rebus. “Surprise and delight” works far better with humans than with computers. Programming certainly can be fun, but it’s rarely a fun that reaches out to the user to join in the fun of interpreting a program.
In some ways, designers – particularly graphic designers – have it easy. Programmers have created a wide variety of tools that make it easy for them to experiment with visual forms, even animated forms. 3-D printing and similar tools are taking that to a whole new level. Even before that, designers had a wide variety of tools for analog experimentation.
Meanwhile, programmers lack general sketchbooks, tools that really let them play with code. We have reusable modules, component libraries we’ve assembled over time, but few of them are really set up for play. (Languages aimed at bringing kids in may be an exception, and perhaps Minecraft is an exception all to itself.)
There’s no shame in being a really useful engine. Programming does many great things. We shouldn’t all be designers, especially those of us (like me) with limited talent. At the same time, though, exploring a different practice can show us possibilities, driving us to reach for new opportunities.
Even without a sketchpad for programming, what might it look like to apply Sister Corita Kent’s 10 rules to programming?
I’m hoping we can create more vibrant intersections of design and programming, on the web and elsewhere.
Image by Dave Gray, used under a Creative Commons license.