Designers Should Code; So Should Other Communications Professionals

Designers should codeIn a recent blog post, designer Josh Seiden offered a rebuttal to a friend’s argument that designers shouldn’t code because being influenced by implementation needs would compromise their design. I definitely side with Seiden’s view that designers should code, and I particularly agree with this section of his argument:

The “coding” that I see lots of designers doing these days is HTML+CSS+Javascript. … The designers that I see doing this typically have a workflow that goes from paper to a drawing tool to a pixel tool to a text editor-browser combo, then back again.

I don’t see this workflow as especially pernicious. It seems to me that it’s just an extension of where we used to be 15 years ago when designers had to learn PhotoShop. There’s a geeky, technical tool in this workflow, and some people get good at using it. In my experience, just as many good and bad design ideas come from this workflow as from a “pure” workflow in which roles and responsibilities are segregated.

Designer’s Intent

The difference for me is that more good product comes from this workflow. In my experience, having designers in control of the presentation layer results in a presentation that more closely conforms to the designer’s intent. I imagine that most designers would think that’s a good thing.

I’ll also approach this discussion from the perspective of a communications professional: To me, not only should designers code (for the reasons that Seiden cites), but other communication professionals should code as well. I’ll explain why by drawing on my own work experience, which has included full-time employment as a writer, editor, and designer, freelance work coding websites, and dabbling in photography as part of my current job.

Doing code makes it easier to work with (or manage) coders

Seiden’s friend argues that a designer shouldn’t try to reinvent him or herself as a “part-time, mediocre coder.” I’d be the first to acknowledge that the coding I’ve done isn’t on the same level as the work of a professional programmer who does this for a living. I’m familiar with HTML and CSS and tinker with Javascript. One of these days I’ll become more adept at JS and crack the mystery that is PHP. Still, even when that happens, I know that someone who does this day in and day out will be able to do it better and faster than me. At my current job, I work with a couple of freelance programmers to maintain our website, and I know that I can’t hold a candle to what they do.

So why do I still put in the effort to not only learn new code, but also stay fresh on what I’ve learned? It’s not to reinvent myself as a “part-time, mediocre coder.” Instead, the point of all this is to make myself, to channel Seiden’s friend, the “Pegasus” of project managers.

Code is now the building block of significant components of communication — presentation, dissemination, and increasingly, parts of the content. Therefore, as a communications professional, knowing code should be as natural as knowing how to use Photoshop, Twitter, Word, or The Chicago Manual of Style.

Of course, knowing code is not the same as slinging code for a living, but because I know code and have actually built stuff with it rather than just understanding the basic concepts in a 10,000-foot-view fashion, I can communicate much better with the programmers I work with. I can speak some of their language. I understand how to explain our needs to them. When I report a bug, I know what kind of information they need. When we’re writing up specs for a new feature, I know what needs to be clearly spelled out.

In my experience, web development works best when someone who has actually done some web development is involved to facilitate communication between the clients and the programmers. Often clients have a nebulous idea of what they’re looking for in a new website or application, which is exacerbated by the fact that they lack the technical know-how to clearly verbalize that idea to the programmers. This often results in a lot of revisions and do-overs later in the development process, leading to increased cost, time, and frustration, all of which could be easily avoided with better communication at the outset.

Someone who has done some coding and thus knows the challenges and potential pitfalls of the process can help avoid such mistakes by making sure both sides are on the same page. That person can also help clients understand why a seemingly simple feature might be more labor-intensive and thus more costly than they thought, as well as protect the clients’ interests by pointing out when a quote seems higher than it should be. Having done code, then, helps me do a better job of managing projects that involve code.

Being the ______ that’s available

There’s another reason why someone in my position should know code (and for that matter, know something about design, writing, editing, photography, and as many other communication-related skills as possible). As part of a small in-house communications team, I have encountered many projects that simply would not have been outsourced to an expert in the particular skill required because of budget or time constraints.

A couple examples:

  • I serve as the “official” photographer for my organization. I’ve never had formal photography training. What I know, I’ve learned on my own and through trial and error. I’ve gotten to the point where I can take decent photos with a DSLR. Of course, put my photos next to those by an experienced pro, and you can tell the difference. However, I have multiple photo assignments of varying levels of importance almost every week. It would be unrealistic, in terms of money and deadlines, for us to hire a staff photographer or to outsource all of that work to a contractor. So either I learn how to take solid pictures or we end up with cringe-inducing point-and-click shots.
  • I’ve already discussed the limits of my abilities as a coder. Yet those abilities were sufficient when we needed a way to feed rotating content to a video bulletin board. I spent a day throwing together a simple HTML+CSS+JS package that met the need. If I couldn’t do that, it’s doubtful we would have spent the money to hire a programmer because this was a relatively low-priority project. If I didn’t know code, we might have gone with (shudder) PowerPoint.

In these cases, had I not possessed a degree of competence in the necessary skills, the choice would have been to either spend a lot of money hiring outside help (unlikely) or settle for a significantly inferior in-house solution (very likely). Because I had some level of competence in those skills, we were able to deliver a much better in-house solution than what we would’ve ended up with otherwise. Sometimes, it’s not about being the best coder/designer/whatever, but rather being the coder/designer/whatever that’s available.

Jack of all trades ≠ master of none

As you can tell from this post, I’m a big believer in versatility. One attitude that has always annoyed me is the assumption that because someone has a certain level of competence in a wide range of areas, they are not good at any of them. The “jack of all trades vs. master of one” idea seems to view people’s potential in a very confining manner:

competence graph-01

To me, this view underestimates the human capacity to excel at one or two skills while learning new ones, particularly with the self-learning resources now available. I think it’s very feasible for someone who puts in the time and effort to become this:

competence graph-02

What’s more, the toughest part about mastering a particular skill is often the steep initial learning curve. That means if someone has already gotten over that initial curve and attained a degree of competence, then 1) they’re that much closer to the level required for a project, and 2) it’s much easier to “level up” as needed. Also, someone who has the curiosity and drive to learn new skills is more likely to put in the effort to level up.

Put it this way: If your project requires a certain piece of Javascript, who’s more likely to figure out the solution — someone who has done some coding or someone who has never written code and has no interest in code? Carrying out a successful communications project requires using a number of different skills or working with people who are masters in one of those skills. Which person do you think would be better positioned for success in that situation?

competence graph-03

That’s not to say there won’t be times when you need a master, someone who can kick ass in one specific area. However, at a time when communication projects touch on an ever-expanding array of disciplines, versatility is indispensable for someone in my position. Sure, there might be some risk of being seen as a unicorn, as Seiden’s friend suggested, and you need to be able to recognize when you’re at the limits of your own capabilities and need to bring in a master. However, if you’re trying to become Pegasus, at least in the communications field, I think you need to be more than a one-trick pony.

2 thoughts on “Designers Should Code; So Should Other Communications Professionals”

  1. I agree that versatility is a valuable asset. Having worked at five startups, I definitely fall into the "whatever it takes" camp.

    However, the point of my original article (goo.gl/eb9vGd) was to encourage UX professionals—those with the aptitude and desire—to become proficient in product management and business strategy, to fill VP Product and Chief Product Officer roles in the future.

    Do you disagree?

    1. Hi Wayne. Thanks for reading and commenting. No, don't disagree with the call for UX professionals to become proficient in product management and business strategy if that's a path they're interested in. But I am curious: Would a designer worrying about, say, business-strategy concerns face similar potential conflicts of interest as a designer worrying about implementation challenges?

Comments are closed.