A magazine about programmers, code, and society. Written by humans since 2018.

The Impossible Dialogue, Revisited

During the preparation of this edition of the magazine, I realized that we have talked so often about design, that we might as well advertise ourselves as a design magazine. The reason is that design is a broad concept, encompassing various meanings, definitions, roles, and ideas. Or maybe that is because, well, software developers are designers.

In the pages of previous editions we have directly covered subjects such as web design, desktop app design, computer game design, design by contract, algorithm design, design patterns, test-driven design, object-oriented design, programming language design, platform design, organizational design, skeuomorphism, hardware design, cross-platform app design, design processes, and even fashion design. So why another issue about “design” itself, and even more importantly, what do we mean with the word “design”, anyway?

In a now classic interview published in Wired Magazine in February 1996, Steve Jobs, still CEO of an ailing computer company called NeXT (just months away from a historic return to Apple) said a now famous phrase:

Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it’s really how it works. The design of the Mac wasn’t what it looked like, although that was part of it. Primarily, it was how it worked. To design something really well, you have to get it. You have to really grok what it’s all about. It takes a passionate commitment to really thoroughly understand something, chew it up, not just quickly swallow it. Most people don’t take the time to do that.

This quote, put in context by the events that would follow his return to Apple merely 10 months later, have been repeated once and again by a whole generation of graphic and industrial designers. Mostly because before the 2000s and the rise to prominence of Jony Ive, the role of designers in the world of software was, at best, derided. The iMac G3 released in August 1998 is today considered a major historic milestone in the story of personal computing; but at the time, it was widely ridiculed, starting with its “bondi blue” color.

Even today, among software developers, the best we can say is that designers are tolerated, but not much more.

It is difficult to know how many software developers are working today on user-facing software, involving usability and visual constraints. Many of them are working “behind the scenes”, providing APIs and databases and other “low-level constructs”, not meant to be seen directly by the eyes of the profane. Those developers are those more prone to dismiss visual design considerations as frivolous or useless.

The truth is, those same software developers have a different meaning of the word “design”, akin to that found in expressions such as “Test-Driven Design” or “Object-Oriented Design”. This kind of design is close in spirit to that explained in “The US Army / Marine Corps Counterinsurgency Field Manual” by U.S. Army General David Petraeus. (I bet you never thought we would mention this person or this book in this magazine, now, did you.)

In section 4-2 of this otherwise surprisingly interesting book, “design” is defined in contraposition to “planning”; while these two words are closely related, they are very different upon closer inspection:

It is important to understand the distinction between design and planning. (…) While both activities seek to formulate ways to bring about preferable futures, they are cognitively different. Planning applies established procedures to solve a largely understood problem within an accepted framework. Design inquires into the nature of a problem to conceive a framework for solving that problem. In general, planning is problem solving, while design is problem setting. Where planning focuses on generating a plan—a series of executable actions—design focuses on learning about the nature of an unfamiliar problem.

In short, while planning deals with the known, design deals with the unknown. Design is the process by which the unknown becomes known.

And guess what: visual designers and software developers (both at the backend and frontend) are, essentially, designers. The design of algorithms and the design of user interfaces are not much different from one another, a fact that might enrage hordes of snob software developers, swimming into the waters of their own hubris and scoffing at such claims. So be it.

Different software developers have to deal with different constraints. For example, DevOps engineers busy stuffing code inside a Docker container might not realize the amount of design they have to deal with at any step of the way: should they base their work on alpine:latest or scratch? Can they? Should they include all libraries, or can they strip a few to slash some megabytes? What programming languages would be better suited to make this container run faster and smaller?

Mobile app developers might have to deal not only with similar considerations of code size and efficiency (particularly when those apps are downloaded through questionably slow mobile networks), but also with the whims of Cassowary linear constraints that define how their user interfaces spread over the screens of devices with various sizes.

Web app developers (or, as they are known nowadays, “full-stack developers”) would in turn tweak their CSS stylesheet endlessly, until their responsive designs adapt properly to most mobile and desktop platforms alike.

Machine-learning developers, arguably one of the most sought-after professions at the time of this writing, will try to build their large language models in such a way that they can make sense of the highest possible amounts of data minimizing GPU time (and as a consequence, dollar spending in cloud resources).

There is, however, another common issue between software developers (particularly those involved in the creation of user interfaces, such as mobile, desktop, or web apps) and graphic / industrial designers. This problem is not dissimilar to that existing between software developers and their managers, one that we described in detail in our June 2021 article titled “The Impossible Dialogue”.

In this particular case, it is not uncommon for software developers to not only ignore, but even dismiss the required understanding of design language and primitives. At the same time, designers often lack the knowledge required to understand the various constraints imposed by software and hardware platforms.

Hence, the impossible dialogue appears once again on our radar. Just like between software developers and their managers. (The fact that so many impossible dialogues surround software developers should raise some concerns among my readers, if you ask me.)

I have witnessed (and documented) many such clashes in the past, where UI and UX designers sometimes miss the mark in their visual creations, either forcing software developers to create inefficient software solutions, lengthening the development process, and enforcing a misguided perception of the craft of visual design down the road.

Such conflicts usually end up resolved through the mediation of some higher placed member of management: either by privileging one or the other camps, but seldom by bringing them together in a healthy interaction that benefits everyone as a team, and also the end product (and the riches that might come with it).

The rise of the iMac, the iPod, the iPhone, the iPad, and the iWhatever, raised the perception and status of visual designers in the software industry to a status never before seen. In less than 15 years, we went from a world of 16-color Windows 3.1 apps to Web 2.0 shiny buttons. “Design” became a force to reckon with. Unfortunately, the rise in importance was also followed by a rise of hubris, and that clearly does not help anyone.

Thankfully, however, some designers denounce this state of things:

Design is expected to produce “new” or “beautiful” or “special” things. When we look around with this mentality, things outside of “design” are seen as “normal” or “ugly” in contrast. (…)

Meanwhile design, once an almost unknown profession, has become an important source of pollution. (…)

Design is vulgarly interpreted as temporary entertainment, which however loses all value as soon as the show ends, when the initial emotion fades. And when everyone wants to be unique, everyone ends up being the same.

Mike Monteiro is more worried about the social role of designers, and the need to regulate their profession. We agree, and this magazine has argued for similar regulation in the past.

This roomful of designers, however, was quite taken aback by the idea that our industry, an industry which now regularly designs devices that go inside human bodies, or control our medication, or is writing logic for putting driverless tractor trailers on the street, should need professional licensing. (…)

There’s no longer room in Silicon Valley to ask why. Designers are tasked with moving fast and breaking things. How has become more important than why. How fast can we make this? How can we grab the most market share? How can we beat our competitors to market?

We do not need to return to a time of crappy Windows 3.1 software, nor we need the current state of things, with beautiful yet broken software in eternal Beta, busy deconstructing society and democracy left and right. To revert the current state of things means that we must find a healthy equilibrium between the needs and capabilities of both visual designers and developers. But I hate giving good people bad news: this equilibrium requires making this impossible dialogue possible, and it requires a middle point, to which both parties must travel, humbly and consistently.

Besides stating the obvious, that is, that beauty sells, many a software company would be wise to integrate the more visual-oriented brains of a graphical or industrial designer in their teams, to compensate for the algorithmic mindset, characteristic of most software developers out there. Even worse, we could fall into the trap of misapplication of the concept of lateralization of brain functions, a classic analogy that has been misused by sociology and management; but if such an exercise works to reduce the gap between software engineers and visual designers, it might serve its purpose after all.

Bringing some much-needed neurodiversity to our teams is something that has been proven time and again to be a beneficial and healthy attitude, yielding better software; not only looking better, but also with better-working features.

Cover photo by Med Badr Chemmaoui on Unsplash.

Continue reading Gary Hustwit or go back to Issue 068: Design. Did you like this article? Consider subscribing to our newsletter or contributing to the sustainability of this magazine. Thanks!
Back to top