There should always be a little cross-training in every industry. It improves communication and mutual respect. A serious UI/UX designer isn’t trying to just make something “pretty.” More like, “pretty awesome.” (Heh!) But experts should be left to do what they do best: design experiences or code the backend. Very few can do both equally well. One of the complications is that on the web, there are no decent design tools. On the Web, design is CSS. The code is the design control. Instead of a paint bucket with red as the color, you have to create or specify an HTML object and give it this property:
background: #c00000;
And in order to “paint” on an HTML canvas, a designer needs to know some code to get it done. I don’t think anyone should expect a UX designer to code advanced queries and JavaScript. But he should be able to clearly describe the user’s needs and expectations, and understand the capabilities and limitations of every technology — just as an established print designer knows some paper types have better color reproduction than others.
When I interned at the Naples Daily News in 2006, I designed newspaper layouts as a copy editor. The layout software we used was code-based. Every headline, byline, photo caption and article text had to be set with special codes not unlike HTML. I had an epiphany later on, thinking back on this experience while I was dabbling in advanced CSS: Programs like QuarkXPress and InDesign merely removed the coding aspect from design. It replaced markup with buttons and toolboxes.
Today, when I “design” a website, I often think in desktop-publishing terms: image boxes, text boxes, headlines, paragraph styles, all of which have either CSS or HTML equivalents. A “div” for example can be practically anything, either a text or an image frame, depending on the CSS. Similarly, when I draw a box in InDesign, almost anything I can imagine can be placed inside of it. Because I understand how a CMS works, I can also imagine divs and other objects as “placeholders” for dynamic data, like a list of headlines.
It is therefore not hard to imagine better design tools built for the web that are as powerful as InDesign is for print. In fact, Adobe Muse strives to offer this very thing. All it’s missing is the ability to integrate with content management systems, which can’t be too far away. After all, InDesign itself has XML import/export capabilities and can do simple data-driven documents out of the box (a glorified mail-merge), but even more is possible with InDesign plugins.
In other words, someday soon, designers can get back to strictly designing* and coders back to coding.
*Of course, another roadblock is browser compliance with HTML and CSS specifications. Browsers need to be as predictable as a PDF reader. A document creator should be able to use standard tools and create something that he is reasonably certain will be represented the same way across all browsers, operating systems and devices, just like today’s PDFs.
