John Maeda: If You Want to Survive in Design, You Better Learn to Code | Hacker News Reader

John Maeda: If You Want to Survive in Design, You Better Learn to Code

wired.com

96 pointsallenleee60 comments

I don't know. One of the best things about working with someone who's a great visual designer, but no interest or real understanding for code, is that implementing their ideas pushes the envelope. Maybe celebrating hobbling visual expression to a square (rather than the golden ratio, for example) is a great success -- maybe it's just mediocrity.

I do think "everyone" will need to "know code" (just like we expect everyone to know basic mathematics) -- but I'd much rather work with an expert visual artist, than someone who hides under his desk for fear of "implementation constraints".

Sure, sometimes you'll have to say: rotating UI is one thing we can, and should cut at this time. Other times you'll cut something else. But my main point is that you most of the time do not want to cut ideas early because your designer(s) are too familiar with the status quo.

I totally agree. If architectural design was left up to the construction crew, you'd never see a building like what Frank Gehry designs. Did everyone working on his projects curse his name and wish they could just build something with nice straight lines? Yeah, probably. But like you mentioned, a great designer pushed the envelope and now there are some amazing new buildings in the world.

People with understanding can also design things that push the envelope, why do you think the term 'sadist' exists ;)

I want to improve on your metaphor-- I think that architects/construction crew is a bad one. Architects design on a house, but they also are very aware of the engineering constraints of how a building will stand, resist earthquakes, and generally is structurally sound. They learn how to do it in school, but when they work they tend to just use cheat sheets they get from wood & concrete suppliers. (source: my uncle is an architect)

I work with some designers who have _no idea_ how CSS works. Or they only have the vaguest of ideas. That's an architect who is handing off pretty drawings and the construction foreman is also doing structural engineering checks on the fly.

I don't need a designer who can write code full time, but I wish that all of them were forced to do a course in layout with css. Obviously flexbox is solving a lot of this pain, but I think it would still be beneficial.

> I don't need a designer who can write code full time, but I wish that all of them were forced to do a course in layout with css. Obviously flexbox is solving a lot of this pain, but I think it would still be beneficial.

Right. My point is that designers (and coders) that push designs that generate the pain - is the reason why now get things like flexbox. If we were all designing to fit within, say absolute positioning, no-one would create, implement and refine flexbox. Browsers wouldn't include it.

This is an extreme oversimplification, but it illustrates the point I was trying to make.

On the subject of CSS - I was a big fan of the idea of CSS-regions - based on simple design ideas from classic desktop publishing packages. But I also see how they were a bad fit for the corner w3c and friends have designed themselves into with CSS. FWIW Håkon Lie did a good job pointing out problems with integrating the idea into the html/css paradigm:

https://alistapart.com/blog/post/css-regions-considered-harm...

I'm not entirely convinced CSS columns are super-good and regions couldn't be made to behave/have a responsive fallback - but I see how laying out text with regions would be yet another different layout model -- and that it would break with the "HTML for semantics, CSS for presentation"-idea that is now being more-or-less thrown out in favour of "JavaScript all the things until it looks like we want".

On a similar note, I just (re)discovered that CSS Shapes are a thing - although (still) not supported in Firefox:

https://alistapart.com/article/css-shapes-101

https://bugzilla.mozilla.org/show_bug.cgi?id=1098939

In my previous career in structural engineering drafting (possibly different in other countries), architects that understood that stuff were by no means the majority. I observed plenty of heated arguments between Architects and Engineers over seismic bracing requirements getting in the way of having windows everywhere, and even a few over basic understanding of gravity ie somehow expecting windows around corners being able to hold the roof up.

Of course, the architects that did appreciate this stuff were highly respected by the engineers. I think the divergence stemmed from having two architecture schools in the country - one started off with a Building Science degree that dove-tailed into an Architecture degree, while the other larger school was very 'design' focussed and IM(unfair?)O seemed to churn out glorified interior decorators. Things might be different now though - I've been in tech for nearly 20yrs now.

The flip side of that is my business partner is an amazing designer but he has no UX/software background and that can be an issue.

Stuff that we'd take for granted in terms of designing to expectations becomes a battle.

"This works better" vs "This won't surprise the user".

I like it though since it does break the box sometimes as well.

I hear this argument whenever there's a discussion of 'should designers learn to code'. I have two problems with it.

First, it's an argument for a very select set of design+engineering projects. In almost all real world situations, designing something that is possible to build without 'pushing the boundaries' means a design that might actually get implemented. Not everyone works on the bleeding edge of engineering, nor should they if they want to focus on all the other obstacles to creating a successful product. Most organizations have technical debt and UX debt as it is.

Second, why does understanding the engineering side of the equation mean an inability to come up with boundary-pushing design solutions? If anything it would seem to mean an informed pushing of the boundaries when it's actually necessary for a design. It's like the advice English teachers give out -- learn the rules before you break them.

I fit into the niche skillset described in this article and disagree with this argument in part (I actually attended RISD as a graphic design student during Maeda's somewhat short tenure as president, and now run a small web dev shop).

It's not that code literacy is wrong per se, but the assumption that this literacy has to be applied to whatever the core product is that is being produced is suspect. Though it seems more and more true that knowing how to write computer programs (in whatever form) is transformational to the role it is applied to, the common argument that designers should jump into collaboration with front-end developers misses a much larger opportunity.

Where are all of the code camps teaching designers to compose books with Racket, or beginner level blog posts for building an image processing pipeline in Ruby? There are tons of inefficient processes (in most industries) that would benefit from the person in that position having the ability to solve a problem by writing a script or program.

EDIT: edited for wordiness, spelling

Yeah, automating simple image transformations could really save a lot of time and effort.

Not sure if this is sarcasm, but I have looked over the shoulder of many designers that spend days doing manual repetitive tasks. Perhaps not so reductive as direct image transforms, but making small variations of a single image, SVG, PDF, etc., certainly.

No, I was serious. I'm often surprised that even at my company where the 75% of us are engineers, people are still reticent to spend the time automating repetitive tasks. I have a coworker who manually runs sql queries and compiles an excel doc with the results twice a week. I wrote a script that produces the same results 100% of the tim, and he doesn't use the script.

> the assumption that this literacy has to be applied to whatever the core product is that is being produced is suspect.

I think what he's saying is that if you're a designer and you don't want to be unemployed then you should learn to code. Whether or not you should actually write code for any given project is a separate question.

My read was references to JavaScript (largely a codeword for web development, even if it can now be used in a larger context), and repeated references to building a product (which in context seemed to imply working directly on shipping code).

The argument for designers learning web programming skills is more explictly made elsewhere, and I am picking up enough hints of the same here.

In the end "you will need to code to do your job" is just not as hot of a statement, because this is broadly true in any industry.

I too pursue this niche, personally and professionally (SCAD alum here – I have chosen to take my career down a more design-centric path).

One of the best products in this space is Framer Studio[0].

Framer has quick visual feedback and added GUI around a specialized flavor of CoffeeScript. Creating a UI, prototyping the UX, exploring the motion design aspects and mirroring to device is all done by blending design sensibilities and very basic coding. This has been an incredibly valuable tool for me, personally. Sometimes I kind of view it the same way I view Google Translate... it won't make you fluent in the language but you can communicate ideas in a quick way.

I do not currently see many (if any) design/code tools today that match Framer's accessibility, extensibility, community and quality of output.

0. https://framer.com/

Pfft. Companies can want unicorns all they want, doesn't mean schools will magically gain the ability to start churning them out. Design and engineering are completely different ways of thinking. Anybody trying to wear both hats at the same time surely won't be able to do it well.

I actually know a designer that does his own engineering. He's amazing, but he's one in a million. Kinda reminds me of Brian Eno.

What we need are better ways to collaborate.

Who's talking about engineering? There is a large space between being able to write code well enough to be useful and being a bonafide software engineer. Hell just knowing enough about programming to have a general gist about what is possible and not is a huge upgrade.

Knowing what is possible and what's not possible is the responsibility of whoever is dreaming up the features.

Bad managers pass the buck here to the designer. Unfortunately, this is my experience.

Only if "dreaming" is an individual endeavor and not part of a group effort of specialists working together.

I don't need a designer who can literally sit down and code with the best of them; I need a designer who knows enough about coding to know what is practical.

Just like I don't expect an building architect to pick up a hammer, I expect them to know enough about the process that they don't create something that can't be built or but can be built but for a few tweaks could be built 10x more efficiently.

Knowing the tools shouldn't elevate anyone to unicorn status. That's just the job.

Emphatically this. We had hired some print designers to design our sites for a while (for some stupid reason that was beyond my control) and it was pure pain until we fired the ones who couldn't grok web and I trained the rest to design for web.

> I need a designer who knows enough about coding to know what is practical.

This sounds sad to me. I would prefer a designer who would collaborate with engineering (who best know the constraints) rather than one who would guess what engineering can do (and therefore temper their designs). I guess it depends on the product you are working on, however. If you have a huge communication firewall between engineering and design (e.g. engineering is being done in India), I guess it is the only practical option that the designers be able to know what engineering can do.

>If you have a huge communication firewall between engineering and design

There is a natural communication firewall when a designer knows nothing about code in the form of language and vocabulary.

I've worked with lots of designers before (I used to be the only programmer prototyper in a design studio serving a bunch of product teams). I never had trouble communicating with designers. In fact, they were much clearer in communicating designs than any SE-background project manager could ever describe in a spec.

The product teams, however, would often come back and say "this is too hard", and my job was to code something up in a few hours and say "no its not".

Whether it is a coder that knows how to speak design or a designer that knows how to speak code, that translator role is absolutely crucial. Without you there to bridge the gap, product creation might have ground to a stop.

I definitely wasn't versed in design before I joined; what made me useful is that I was working "with them" rather than working at an arm's length in another team. Usually, it's the PM's job to coordinate, but design-skilled PMS are rare.

Designers embedded in engineering teams can also work out, but lose the peering benefits of working with other designers in a studio setting.

I actually spent a lot of time with John Maeda IRL. Your sentiment is close to what he's talking about. Designers need to be able to write code and math to describe patterns they envision and connect system of information together. E.g. scanning a biometric database to design furniture that fits peoples' bodies. And of course for making media such as complex web pages that merge multiple frameworks and information sources.

Is there any evidence that design and engineering are really oil and water?

In my experience most of my work has cross-over between the two with a continuum of how much design skill is needed. For example in previous jobs we have had many cross-discipline roles like Technical Artists, Technical Designers, Gameplay Engineers and Rendering Engineers. Various art positions like Lighting Artists will even get in on the act writing shaders alongside engineers. Level Designers will very often be required to write scripts. In general the closer you are to the squishy human stuff the more design skill and knowledge its useful to have and visa versa. In my current role I'm engaged in experience design and engineering.

More generally it feels like there is a lot of gate-keeping between design and engineering. Neither is too keen on the other muscling in on their turf. I think this notion of the designer-engineer being a unicorn is mostly bunk promulgated to this end.

Designers having a working knowledge of programming and programmers having a working knowledge of design really does help collaboration and project resilience. Specialization will remain a thing but it should be looked at in shades of grey rather than black and white.

>I actually know a designer that does his own engineering. He's amazing, but he's one in a million. Kinda reminds me of Brian Eno.

No offense to you or your friend, but you may be overstating the rarity of that type of person. The visual effects industry, for example, has an abundant supply of people that are simultaneously highly artistic and yet have deep technical knowledge.

Not buying it. Hackers and painters. Its all the same at some point. Larger items from atomic pieces.Its not that its a different way of thinking, it just requires twice the time.

I'm a coder and a designer. Been doing both for 40 years. Since when design was all analog and coding was machine language and c language. To do what I did was necessary at the time. But it was not always a great idea.

While it's very, very useful to have feet in both disciplines, I try to segregate the two activities as much as possible. A coding mindset is not really good for design and visa versa. If I'm worrying about implementation that can hamper coming up with good visual solutions. If I'm worrying about what it looks like I may be missing something in the code.

These days I try and focus on one or the other for a project. If I have to be involved in both, I try to find someone to check my work. Each discipline is hard enough as it is.

Having said all that, it _is_ nice to be able to talk to both coders and designers and to know when they are bullshitting me about something. Being able to code a little and design a little would probably be a very good characteristic for a manager. At least for certain size projects.

I think it depends.

If we're talking about certain mediums that require complex code then I really don't know if a designer can gain a lot from that experience over simply talking with an experienced developer to gain a high level understanding of what's possible.

I'm mostly a designer and I did Paul Hegarty's Developing iOS 9 Apps with Swift course out of curiosity. I've also done courses on Ruby and Python. And I worked on Rails and Coffeescript for a number of years. While I appreciate the experiences, I don't consider myself a better designer from it over say, those who spent that time getting stronger at illustration or user testing or color theory. The person who spends 40 hours a week doing Swift/Ruby/Python is clearly going to be much more proficient than some asshat like myself who dabbles in it once in a while. Sure, it's helpful in a situation where you and a friend want to experiment with testing a startup idea and you divide the roles, but for most situations the clear division of labor is much more efficient.

However, I don't think there's any reason why designers, specifically those who produce work for the web, shouldn't learn basic HTML/CSS or if a bit more ambitious, React and Javascript. All those languages are fairly approachable and can help with prototyping and experimentation.

Seems to make sense to me. When I worked with designers the handover was often odd. I always thought "if he can draw up this whole thing in Zeplin, why doesn't he just give me an HTML doc that a coder can then generalize? And then you'd end up having to ask about a bunch of cases like mobile sizes.

There's also the problem of knowing what can be done in HTML/CSS/JS easily and what cannot. If the designer just made the page without the variable parts it would solve this issue. You don't need to know a hige amount about coding, just enough to make your page look the way you want, and to know when it can or cannot be done.

Of course everything that's at the interface between two roles can be argued to be on one side or the other.

I'm building a tool that does exactly what you said -- it creates all the HTML and CSS from designs, saving immense amount of time doing the rote work of transcribing the designs into code. With design tools supporting reusable abstractions (Symbols in Sketch), we're even able to create reasonably factored React components straight from the designs. https://protoship.io/tools/uipad.html.

There are quite a few challenges in this approach. We have to work with a static snapshot of the design and infer things like whether a container is auto-width (fit to content), a percentage of the parent, or fixed width container. Unifying multiple states of a component is another problem. Designers draw the same component multiple times to show different states (disabled, focussed, active etc.).

The way we're approaching this is to identify the extra information required to take a static design into a responsive representation and ask the user to annotate it before generating the code.

You're not the only one wondering why handover is so limited! I worked on React Studio, which is another tool that tries to solve this:

https://reactstudio.com

It's a designer-oriented front-end tool. Three big features are responsive mobile device previews, easy creation of components, and data-driven design (e.g. filling out lists based on real data from a server or mockup data sheet). You can design in place, and there's also a Sketch plugin for easy import.

The tool outputs very clean React+Webpack projects using Facebook's "create-react-app" toolchain, so the code is actually useful. Going the other way, developers can control and augment React Studio's output using plugins -- thanks to these hooks, it's actually more like a metaprogramming utility, a "design compiler", rather than just a WYSIWYG prototyping tool.

The problem with these kind of tools is that as soon as the generated code has been modified, you can not bring it back into the visual tool.

Well, that's a problem that is being worked on, e.g. see

https://www.microsoft.com/en-us/research/publication/its-ali...

https://arxiv.org/abs/1507.02988?context=cs

I don't buy it. All the good designers I know make excellent mock-ups and have a good understanding of css, pixel widths, etc. It is also my experience that a good designer will talk to the coder during the course of making their design to make sure what they are doing can actually be coded and makes sense.

Coding and designing are 2 very different disciplines. I do forsee more tools like spectra to come out that help merge design and coding - but this doesn't change that fact that designers have to think about sooooo many other things besides the actual implementation of their design.

Coding and playing guitar is also two different disciplines, but for some reason a lot of programmers do enjoy playing music. I do not believe that different disciplines are at odds in the sense that single person cannot learn to do them well. I am more inclined to believe that learning different stuff actually helps to be better at each one.

I'm not saying you can't be good at two things. I'm just saying that if you spend 8 hours a day specializing in one thing, you will be really good at that thing.

Designers think about all sorts of things that aren't on programmers brains. I haven't studied the history of design and UX experience and theory. I also don't want to sit around in adobe designing mock-ups all day, that's why I am a programmer.

Meh. It's nice for my designers to "understand" code and rendering issues... just like it's nice for me to understand the basic vernacular of typographical concerns, but it's invariably annoying and poorly done when they try to do it. Specialization exists for a reason.

Does every company really think it's economical to hire Da Vinci like minds. If tech companies want people that can art and math (or think natively in both artistic and structural terms), they're going to have to change K-12 education. which isn't going to happen since tech has barely gotten their feet wet politically, and tend to blunder about when they do (Uber and Trump being one of the most recent examples).

As someone who'd professionally identified as a UI Designer for over a decade, now turned developer, I have mixed thoughts.

I think coding has made me a better designer. It's honed my priorities and made me realize a lot of my design aims in the past were motivated by ego, sometimes at the expense of getting a product out there quickly and getting real user feedback. Now in designing software UIs, because of the internet, I think taking the time to design and spec out premium UIs, with all the whiz-bangs, comes with immense risk, especially for startups that don't have the room to fail. We can iterate at a pace other industries cannot. But that also means our direct competitors can as well and they are moving quickly to meet their users' direct needs.

I have also come to appreciate simpler UIs for their reliability, accessibility, and responsiveness. In my opinion, a lot of the design problems of screen-based UIs are solved. Browsing design-oriented forums nowadays, I see a trend I appreciate (back to simplicity) and a trend I think is misguided ('innovation' that strokes designer egos).

The latter I don't think is going away. There's no doubt that the world is moved by art, brand, and image. The companies that wield those forces successfully, and not at the expense of functionality, will get the attention they want.

The former, however, I think, is an argument for standardization, which I think means the need for fewer designers. The alarms were ringing a few years ago for me and I jumped ship. I'm glad I did and quite frankly, I now enjoy backend work much more than I do design; but it is very satisfying to take a project from start to finish. Something I missed out on when I was 'just' a designer.

I don't think this is true at all. The best designers I have worked with wouldn't know an HTML tag from a line of JavaScript. They are two completely separate skills in my opinion. I think a lot of the confusion comes from the ego involved. Designers see developers actually building things and it can create a feeling of inadequacy. They forget that developers have the same feeling of amazement watching them come up with some beautiful new design.

I would much rather work with a fellow specialist at the top of their field, helping them to realize their vision, instead of battling over implementation details with a generalist. Anyone who claims to be equally good at both is self deluded.

I won't comment for software developers, as I'm sure there are plenty of options other than JavaScript for that type of work. This comment is specifically for designers and web developers who work on websites and web apps:

Five years ago I would have said: "There is enough room in web development for designers who don't know code at all, people who only know HTML/CSS, and people who can use JavaScript to find work" but I'm not sure that's as true today as it was then. When I look at the market today, what I see is that if you're doing anything in browser, you need to be familiar with JavaScript.

JavaScript is the language of the browser. It was designed to work in the browser, and it does some pretty amazing things there. I think it will be increasingly hard for anybody who doesn't know JavaScript to keep finding work in web design & development, even if previously you only used Photoshop, or previously you only did HTML/CSS. It's not going to be enough in the market of today and tomorrow.

Personally I've been taking this advice to heart. 3 years ago I couldn't really do much with JavaScript on my own, but I've been focusing a lot of energy on trying to learn enough JavaScript to stay employed. Workers who don't pick up JavaScript soon may find their work options disappearing in the near future.

On the plus side, JavaScript is an easy language to learn, even if it's your first real programming language, and because you can write and test it in any browser, any time you have your smartphone, a tablet, a computer - basically anything with a web browser, you can be coding and testing JavaScript.

"Take Instagram, which from the start had to balance engineering and design constraints. In its infancy, the company was too computationally expensive to allow for both landscape and portrait mode; instead of limiting the interface to one or the other, Instagram’s designers decided to make every photo a square."

Source on that? What was computationally too expensive? Casual Googling indicates that the intention behind square was an aesthetic one - setting the pictures apart, and tapping into the vintage instant camera vibe.

E.g.:

"First, it’s worth reflecting on why Instagram photos were square in the first place. Instagram CEO Kevin Systrom has said Instagram wanted to be different, to find a way to do photos in a way that stood out. And the square format looks good; it’s consistent and visually appealing"

https://unionmetrics.com/blog/2015/08/instagram-update-squar...

In fact, Wired's own article from a few years back talks about design decisions behind the square, and makes no mention of any thing being "computationally expensive":

"There are logistical reasons for shoehorning photos into the shape: Squares look great in a grid and feed format. They provide a consistent visual experience for both photos and the little interface details like username, likes and comments. It relieves us of having to make yet another decision on yet another app, and that lightening of the cognitive load is not insignificant."

https://www.wired.com/2015/08/instagram-says-goodbye-square-...

I made the mistake of hiring a designer that had no idea how to code. It was a special little hell.

It does not help you get a job, ie survive. In my experience companies are not looking for unicorns, they want you to be very good at a specific thing (startups under 5 people are maybe the exception).

My thoughts exactly. I'm good at many things, but no expert in any.

I'm currently in a start-up though and it is very useful: I forbid the programmers to write any CSS or Android Layouting and than really quickly do the design. Probably a lot quicker than going back and forth for every tiny change or having rigid pixel perfect designs (I only occasionaly make balsamiq mockups).

This seems hard to believe from my experience. I am friends with around 15 UX designers, and acquaintances with around 30 more, many of which are at top companies like Uber, Google, Microsoft, Amazon, and IBM. None of them know how to code to my knowledge, other than some basic HTML, CSS and jQuery, which they primarily use to build portfolio websites for themselves. Anecdotal and small sample size, yes, but these people are certainly having no trouble "surviving" in design.

Also it's not clear from the article that the headline matches John Maeda's actual position, so perhaps the point is moot anyway.

Here's another article on the same report, with a contradicting headline:

https://www.fastcodesign.com/3068938/forget-coding-writing-i...

I like working on beautifully-designed (by others) projects. I can code and write, and love doing both. Not feeling an urgent need to start designing.

A good friend -- advertising-focused designer with lots of Photoshop and Flash experience -- has been exploring this transition. I also have a "unicorn" title myself (data scientist, lol), and think this would be an interesting transition for him. He doesn't know where to begin though.

If he wanted to move to "tech-friendly designer," what should he pick up? Sketch? React?

Sketch 1000% and then for basic prototyping Marvel.

The idea that design is primarily done inside tech companies is wrong. Netflix has a series called "Abstract" that profiles notable designers and none of them work for web/tech companies.

Just another way for corporations to cut "costs" while they piss money away on bad management.

With increasingly popular tools like React, you can't isolate the design from the code anymore.

If you want to survive in Coding, you better learn to "design".

Reply on news.ycombinator.com