This is the second installment of Fall of the Designer. If you've missed the first part of the series, head over and read Part I: Fashionable Nonsense.
The most interesting phenomenon emerging from recent trends is not the silence of developers in the face of conflicting interests with operating system makers. Developers should be expected to bend towards the present incentive structure. What has been surprising is the response of designers, particularly visual designers: their eagerness to follow the trend toward flatness. A trend that ultimately goes against their interests. Even those few who have criticized flat design (who have rarely been rigorous in their critiques) generally bought the operating system makers' line of thought that UI design needed a radical rethinking. These visual designers lacked conviction in the integrity of their craft's history.
Strangely enough, the very makers of tools built explicitly for visual design hold negative opinions of the practice. Jeff Veen, the then VP of Product at Adobe on Typekit, was asked about his thoughts on design leadership. He responded: "Does leadership mean the people who use Photoshop are leading companies now? No, I don't like that at all."
Similarly, Pieter Omvlee, the CEO of Bohemian Coding, the maker of visual design tool Sketch, wrote: "The color of the UI is of absolute indifference to me…Doing all the essentials right is an enormous task and many apps never even make it that far. So let’s focus on that first, okay?" Omvlee continues, "The unfortunate (for designers) fact of life is that most people don’t give a shit about how well something is designed…What I mean to say is that the shape of your buttons, or the bounciness of your animations are details, not selling points.” His conclusion: "You’re running a business, not doing the adult version of playing with Lego."
It is beyond confusing that the collective marketing strategy of executives at design tool companies is to call their customers superficial and claim they are not solving "real" problems.
Bradford Shellhammer, the cofounder of failed fashion ecommerce site FAB, has a similar mindset when it comes to visual designers. In an article that would make Jeff Veen proud, entitled You’re a designer. Not the CEO. Shellhammer degrades designers:
Designers get to make things! Making things is fun. Grouchy designers, GO AWAY! The world does not need you. If you’re a curmudgeon designer seriously think of a new career…Your job as a designer is to solve a problem…to SUPPORT the business. You’re support staff just like the receptionist.
It is unsurprising that designers have trouble arguing their value to companies. Only a rare company could see through all this disparagement and find the essential need for design. Given the circumstances, the fact that any company pays for design at all is a testament to its value. Ultimately, only designers themselves and the industry at large can prevent the further devaluing of the craft.
Given the state of things, today we have companies boasting about the fact that they hire fewer and fewer visual design specialists. Softfaçade, a company known for its elaborate icon designs, today proclaims their new modern minimalist rethinking. "We want to design and create, not decorate and illustrate." They proudly explain that they are no longer focused on the field of visual design: "by the end of 2013 there were no pure icon designers left on our team as more and more UX designers and software developers came on board."
This celebration of the sacking of visual designers is a result of Softfaçade's disdain for their former output, that which they now understand to be an infantile obsession with aesthetics. They explained, "Today, we are launching a new website and identity that most precisely reflects our matured philosophy." Their position of self-described maturity is quite common today. Visual design is now seen as a superfluous, naïve triviality in comparison to the serious work of development coding.
This move towards the design engineer has excited designers like Cap Watkins and 3000 of his supporters who advocate for an ideal "lazy" and "boring" designer who never experiments and "Chooses obvious over clever every time." A perfect designer who compromises their vision to fit what is easiest to produce, not what is best to produce. Most of all, as a manager, Watkins reveres supplicatory designers who "rarely stand their ground."
Design in Code
More and more, we are seeing a convergence toward a universalized front-end developer role in design, with the ostensible visual designer becoming an abstract coder, thus renouncing any ties to the graphical nature of interface design. We see this movement in both web and native application design, with new and popular courses like Design then Code by Mike Rundle, and Design + Code by Meng To, both encouraging designers to learn programming languages like Objective-C and Swift to implement their designs through development. Taken on their own merits, these courses provide help for designers looking to integrate into a larger product pipeline. They are actually quite useful. But they are illustrative of a larger movement that expects interface design to come a distant second to development.
In fact, in a move that must make executives at Adobe and Bohemian Coding quite happy considering their opinions on visual design, there now emerges a movement called NoPSD. The "PSD," in NoPSD, refers to the Photoshop documents designed in mockups of websites and applications. More generally, it refers to prohibiting prototypes built in any static visual design tool.
Traditionally, designers would build a mockup visually, and depending on their role, translate that into HTML and CSS, or for more complex websites pass their specifications to a developer. The NoPSD Movement rejects the entire idea of prototyping a design in a static visual design tool. For those in the movement, the idea of planning out a design visually is a bastardization of the purity of the code.
In 2015, Dribbble hosted an event with their sponsor Adobe Photoshop. Their headline speaker was Susan Kare, one of the key inventors of modern icon design. During her talk, she "explicitly" argued that design should not be described as an art form. Dribbblers apparently agree wholeheartedly. One commenter felt the need to denigrate the sponsor, Photoshop: "uh? People still use photoshop here?" Six thousand Dribbblers saw the comment and not one had something to say in response. Who knows, maybe it has something to do with the fact that Adobe does not want designers as CEOs.
In 2008 the Founder of Basecamp, Jason Fried, expressed his position on mockups: "HTML/CSS is real in a way Photoshop will never be." For him, "You can’t click a Photoshop mockup. This is probably the number one reason we skip static mockups. They aren’t real." One wonders if Fried would tell an architect that their blueprints similarly "aren't real."
Ironically Fried and his team at Basecamp just two years later in 2010 produced their own app for making and sharing static mockups on iPad called Draft. One wonders whether Fried truly believes mockups have no value because "they aren't real" or if he was just saying that to utterly annihilate the competition. Either way, he has since canned the app and it is no longer available for purchase.
Unlike those promoting NoPSD, Marc Edwards, the Director and Lead Designer at Bjango, argued, "I hate using code to make design changes. It slows feedback and exploration, ultimately creating a worse product."
It should go without saying that everything designed on computers relies on a foundation of code, and a responsible designer should be aware of the performance limitations of the code they are working with or depending on. Yet, in order for a designer to be wary of the current limitations of code, they need not be an expert programmer, as many in industry would demand. The solution is for greater communication between the two complementary practices. Edwards' position on the topic is "involve developers when designing. Involve designers when developing."
In an article encouraging designers to learn to code, Meng To argued that designers "work tirelessly to provide the most perfect assets until the developer is happy. Unfortunately, some designers still just dump the PSD and call it a day. Those should be fired." He later clarified that he was "not trying to be hostile but giving a harsh reality. We need to be able to at least deliver the assets if asked."
To continued, "expecting developers to open your PSD without offering help in return is irresponsible and will lead to many issues." This is undeniable. Of course a designer should provide guidance and explanations to developers for their designs. But this is anything but a design problem, it is instead a problem of inflexible pipelines and badly planned organizational structures that separate the fields into silos.
If the issue with visual design tools like Photoshop and Sketch is that they do not integrate well with a development workflow, then there is no need to throw them out categorically, but simply to build better ones. Ideally, we would have design tools that export directly to code. Indeed, Marc Edwards believes that "We need a clean slate. A tool that’s built from the outset with software design — and only software design — in mind." Edwards is putting those words to action, building his own tool, Skala, to attack the problem. Duncan Wilcox's Sparkle also attempts to bring a sense of immediacy to visual design for the web.
Still, it should not be forbidden for designers to prototype and mock up concepts, or even produce full designs outside of the native medium of the final product. Because the native medium from the perspective of the computer is not the same as the form that is presented to the user. From the perspective of the user, what the computer interprets is irrelevant. The practice of visual design must ultimately be a concern for what faces the user, above all else. The media for delivery, in this case code, should grow and evolve to meet the needs of design, not the other way around.
Theoretical designer Bret Victor once suggested that "the design of information software should be approached initially and primarily as a graphic design project." This is an incredibly wise approach, to see design not as an afterthought, but as the basis and justification for the construction of the abstract coded system behind it. In fact, it is very similar to the philosophy held by the inventors of the graphic user interface at Xerox PARC back in the 1970s. From their methodology:
We have learned from Star the importance of formulating the fundamental concepts (the user’s conceptual model) before software is written, rather than tacking on a user interface afterward. Xerox devoted about thirty work-years to the design of the Star user interface. It was designed before the functionality of the system was fully decided. It was even designed before the computer hardware was built. We worked for two years before we wrote a single line of actual product software.
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.
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.
Allan Grinshtein, formerly of LayerVault, put it bluntly:
Designers who don't use Origami/Framer/Form and have no engineering chops are unemployable. Dinosaur today. Tomorrow a fossil. Get on it.
This isolation of static visual design and elevation of motion design has predictably led to the suffering of interface design aesthetics and usability. Today, motion designers are forced to compensate for the lack of communicative potential in flat design by making distracting motion stand in where static graphical elements would have performed better.
There is one thing that is made perfectly evident given the inconsistently applied standard of 'realness' when it comes to motion and static prototypes: an industry-wide disdain for what static visual design has to offer.
In the not too distant future, there will be tools that allow any stripe of designer to fully prototype their designs only to hand them off to an engineer to iron out small kinks. When these tools arrive, perhaps there will be a renewed emphasis on specialists—even those who specialize in static design.
It should go without saying that visual design has an immense contribution to make in the field of interfaces beyond mere implementation. At the same time, design and development should be seen as complementary, not opposing viewpoints. Instead of elevating developers and coding at the expense of designers and visual design tools, or elevating motion over static visual design, we should encourage whichever design practitioners and design tools produce useful, beautiful and enjoyable experiences.
Here is the full quote from Veen's talk:
It’s about how you make decisions about your company. Design led leadership…I actually think 'design' is a red herring in that context. It’s a redirection. Oh so the people who use Photoshop are the ones who are leading companies now and that’s…I don’t like that at all. It’s about that decision-making, problem-solving process. Design is pushing leadership in that direction. Culture comes down from that in the companies.
From the quote, it appears to read as 'design is so much more than mere pixel pushing, it's about strategy.' I agree that strategy is clearly important. My argument is that the design-act taking place in Photoshop is in fact an act of strategic engagement. That in this way it is not a red herring.
To be clear, Veen has made a significant contribution as an advocate for design. In a later conversation I had with Veen (a part of which he has permitted to be posted publicly), he clarified that he pushes for designers, visual or otherwise, to be seen as engaged in strategy:
All levels of design can have a deep impact on overall strategy. Thinking design is just pixel-level contributions to a product is what we need to push back on.
Here he makes clear that his position is not that pixel-level details are non-strategic, simply that pixels are part of a larger picture. The question that remains is whether anyone of significance was asserting that was not the case.