Do You Need to Know How to Code to be a Designer?

Wired has published an article about John Maeda's annual 'Design in Technology' report, called "John Maeda: If you want to survive in design, you better learn to code" that's worth reading — and so is the report itself.

While I sometimes find John Maeda more the Don Cherry of design than the Warren Buffett (as argued in the article) this is all reasonable stuff to me. Rudimentary coding skills are key for any designer in the digital space. But then again, understanding users and being able to use that understanding in various creative ways to come up with ideas for, shape, and build new things are things that have always been asked of good designers. In some sense, this ability is design — it's not new by any means.

What's changed, I think, are two things. First, design has matured in business and is now a more integrated part of a wide variety of different kinds of industries. This integration is increasingly requiring designers to not sit by themselves in their fancy design studios but to be part of multidisciplinary teams of business people, marketing, and engineers. The challenge for design in this integration has been finding its way to operate, communicate, and making its voice heard.

This brings us to the second point, which is that most, if not all, of the products and services shipped today are digital in one way or another. Back in the day, designers used to make fancy wooden or clay models of their designs that everyone could gather around, look at, and critique. While this still happens, most designs these days aren't as tangible, physical, and fixed. How do you make a clay model of a service? So, while we're not primarily making physical models anymore, we're still making models — but we're now making them in what we in the more theoretically interested interaction design research community for about a decade have been talking about (and debating) as 'the digital material'.  

A problem design as a discipline has had — perhaps especially in a business context but also in its relation to engineering — when moving from shaping physical models to designing in the virtual and intangible space has been how to express and stand up for design ideas early on and how to make them tangible so they can be 'sold' to the c-suite, marketing folks, business people, and the engineers. What is the best language for design to communicate their ideas?

There are three main phases here. First, as noted above, back in the day design used to have an ace up its sleeve when it could invite everyone to an event where the model was to be revealed, preferably to a unison 'aooow!' As the physical aspects of design work became less and less important, design searched for a new megaphone through which to speak. We've made stumbling attempts in 3D modeling, coding, video making, animation, VR, AR, etc. However, I think in the end the fallacy of design was to lean too heavily on the business side of things and adopt Powerpoint and the deck as its main vehicle of communication.

If you're in a meeting and there is a deck, everything in that meeting will center around the deck, and a deck is generally a terrible way of presenting design ideas. I firmly believe that interesting design directions such as service design are currently being held back by having adopted a style of communication which is too linear, logical, fact-based and fact-driven, and just isn't a very designerly way of working. 

While decks might get some altitude with management and marketing, decks also don't speak to engineers. Engineers hate decks. Engineers generally want to see what the idea, what it should look like and how it should work so that they can figure out how it can be built. In siding with the business side, I think design is losing some of its strong ties to engineering. Historically, many product designers have teamed up with engineers to work closely together to make their ideas happen. In the last decade or so, some of the most successful design-driven businesses such as Apple have been good at teaming strong design up with strong engineering. For this to work well, engineers need to be equipped with a sense of why design is important and needed. Likewise, designers need to understand the engineers.  One way to do this is to learn to speak their language, literally.

Over the last 10-15 years or so, designers have tended to try to team up with business people rather than engineers to make design happen on a larger scale, and speaking through Powerpoint is just one aspect of that. This is all good and has perhaps helped move design up the food chain, but I think that one of the points Maeda is making is that design also needs to reconnect with the engineers to make their ideas come to life. This requires coffee script and C#, not sanding paper and scrapers.