This interface-first approach makes a lot of sense. As Jared Spool of User Interface Engineering argued, "unintentional design" is design that happens on its own. In the context of whether design or coding comes first, what design could be more unintentional than that which is applied after the engineering effort has already happened? It should be obvious that thinking visually before building will help to confirm the validity of a design direction. A design-first philosophy does not preclude an iterative process, it just sets an expectation that the designer should direct the project and then coordinate with the programmer for implementation. An open source KDE hacker explained the following:

Coding before design: Software tends to be much more usable if it is, at least roughly, designed before the code is written. The desired human interface for a program or feature may affect the data model, the choice of algorithms, the order in which operations are performed, the need for threading, the format for storing data on disk, and even the feature set of the program as a whole…But the more code has been written, the harder it is to fix a design problem — so programmers are more likely not to bother, or to convince themselves it isn’t really a problem. And if they finally fix the interface after version 1.0, existing users will have to relearn it, frustrating them and encouraging them to consider competing programs.

Bret Victor has been a fierce advocate for the industry producing better design tools. He proposes that designers should draw "Dynamic Pictures," in other words art, design and interfaces that are produced visually as opposed to in code. These dynamic pictures would react immediately to the designer's needs, no longer needing to be compiled. In Victor's apt words,

With today's tools, dynamic design requires creating pictures by writing text. It is only because we are so accustomed to this situation that we don't recognize how bizarre, even barbaric, it is.

Unfortunately, it appears that Bret Victor has reversed his position and holds his former perspective in low esteem. Where before he argued design should be "approached initially and primarily as a graphic design project," now he expresses his disapproval of those interface designers who do not implement their designs in code:

I spent a few years hanging around various UI design groups at Apple, and I met brilliant designers, and these brilliant designers could not make real things. They could only suggest. They would draw mockups in Photoshop, maybe animate them in Keynote, maybe add simple interactivity in Director or Quartz Composer. But the designers could not produce anything that they could ship as-is. Instead, they were dependent on engineers to translate their ideas into lines of text. Even at Apple, a designer aristocracy like no other, there was always a subtle undercurrent of helplessness, and the timidity and hesitation that come from not being self-reliant.

He continued:

It's fashionable to rationalize this helplessness with talk of "complementary skillsets" and other such bullshit. But the truth is: An author can write a book. A musician can compose a song, an animator can compose a short, a painter can compose a painting.

Victor's argument misses the mark entirely. Authors require editors, and benefit from the help of publishers. Musicians benefit from mixing and mastering specialists, let alone the fact that musicians often play with a "complementary" band. Animators on feature films work as part of a vast pipeline requiring hundreds, if not thousands, of specialized practitioners. Even most painters rely on the skills of others—those who make canvas, paint and brushes.

As it stands today, the only way for Victor to make the dynamic tools and designs he prefers is through code. He does not here explicitly advocate for code first—that would certainly be against his philosophical ideal. But in the interim between now and when better tools arrive, Victor has chosen to malign the contemporary practice of UI design and its practitioners by labeling them as 'helpless, timid, hesitant and dependent' and described their rationales for producing the work they do as "bullshit." By denigrating said designers, he is in effect elevating those designers that implement their designs in code.

Victor is right that tools are not where they could be. And he is spot on that code is a backwards and temporary barrier to approaching design as a visual project. One might argue that Victor castigates visual designers merely out of frustration for the limitations of the medium at the moment. However, making better dynamic visual design tools is not mutually exclusive from encouraging and supporting visual design as it is and will continue to be practiced after the onset of his paradigm shift.

The fact that designers are not currently producing dynamic pictures does not mean what they are doing is not of value, and it does not make them "helpless." Designers are simply focused on other design problems, problems that will still need to be solved should Victor's utopian vision of design practice arrive. A glyph will still be a glyph in a dynamic UI tool. A hierarchical layout will still need to be arranged in a fashion somewhat related to how it is approached today.

Putting code first in the design process makes for an alien environment in which to prototype, because code is inherently abstract by nature as opposed to visceral WYSIWYG visual design tools. In a profound way, this makes design engineers conservative in what they make because they must tailor their creations to the nuances of code and be "boring" in the Cap Watkins sense, rather than even considering the possibility of innovating or experimenting. In addition, the feasibility of any given design is always in flux, and should not be limited by what could be built on yesterday's technology.

Victor is a strange bedfellow with those promoting code first approach, because this promotes the very type of inertia-plagued conservative designs that Victor is ostensibly against. Yet today more than ever, the primacy of code continues to be used to push visual design further from the drawing board. In this environment, visual design is most readily accepted when proposed and produced by engineers.

Still, just as no single developer can be an expert at native, web, front-end and back end coding, no single designer can design for every scenario, let alone simultaneously take on the entire spectrum of development roles. Specialization to some degree is a necessity in both fields.

Some companies can afford to have specialists keenly focused on one area of design or development. For these companies, specialists are an asset, because they can distill any particular need to its essence. Other companies require polymath-like generalists who can easily shift between unrelated mindsets in their work. Regardless, there should be no reason to castigate the specialist visual designer.

Rian van der Merwe of Jive put it well when he said,

Once every designer can code, who’s going to make sure we build the right things? Heaven help us if we become a community of executors at the expense of all the planners out there. We need both…It’s really, really dangerous to tell people they’ll be "left behind" if they don’t become part of a homogenous group of people all focused on the same thing.

It would be ideal if both visual and interaction design tools could export directly and seamlessly into code—things are moving in this direction more rapidly with each passing day. Improving tools is a noble and necessary goal. But until we have such an integrated design environment, those with an aptitude for visual design should not be siphoned away simply to satisfy an anti-intellectual bias towards aesthetics.

Prototyping: When is a Design "Real" Enough?

The role of any non-engineering interactive designer is being responsible for prototyping designs. By definition, a prototype must necessarily be incomplete in some way. If a prototype were complete, it would cease to be a prototype. Prototypes can range in their fidelity, but they are meant to operate as a legible communication of the design direction.

As should be evident by now, there is a prevalent notion that what designers make must be 'real,' with 'real' most often being defined as 'being the result of code.' However, this standard for designers has not being applied equally to all specializations.

Since the onset of flat design and the concurrent renewed emphasis on coding, static visual designers have experienced an incredible loss in prominence in the field of software. Their pixel-perfect mockups are today the object of ridicule.

Getting animation correct using precisely placed keyframes and easing is seen as the mark of a craftsman when it comes to interactive motion design. Unlike static prototypes, these motion prototypes are considered real, because they simulate the appearance of a particular interaction with a sense of dynamics. As such, motion designers are the one class of visual design specialists that has been spared disrepute in the move towards flatness and the primacy of coders.

However, upon further examination, one finds that non-native animated prototypes are just as far away from being real products as static prototypes. Their realness and tangibility is illusory in the same way as a static mockup. They must still be implemented and finessed in code by a specialist programmer. The industry has just arbitrarily decided that static mockups must not be assigned to the 'prototype' category.