What I cannot create, I do not understand

- Richard Feynman

When I first started my career in the 1990s, with training in the visual arts, I thought of myself as a “designer” (a very general term, which I don’t actually like, due to its vagueness). What I could bring to a project was my keen eye, craftsmanship in the graphic arts, and ability to problem solve. It being the 1990s in the Bay Area, I naturally became involved in various software projects, starting with CD-ROM development and quickly moving on to the World Wide Web as that wonderful platform exploded on the scene.

My role as a designer was shaped by the expectations of my employers and peers as much as my own ideas about what I was all about. Most software teams require certain degrees of specialization. There’s the backend engineer, the frontend engineer, the database engineer, the cloud engineer, the user experience designer, the user interface designer, the user experience researcher, et cetera. When you are filling one of these roles, it is easy to think of yourself as having a special job that only you can do. And the inverse of this is of course, that other jobs are not your responsibility. So, the designer works hard, focused on the end-user experience without really caring at all about whether the data is stored using SQL or NoSQL, or what a controller is, and whether it is written in Java or Go. And why should they? Does it actually matter? Well, no and yes.

No, It Doesn’t Matter

The end user doesn’t care what technology you actually use to provide them with the application or tool that you are designing for them. The only thing they care about is their experience with it. Is it doing the job they need to be done? Are they enjoying it? Do they love it?

They don’t care if you wrote the app in Swift or Go. They don’t care what chip architecture is being used. If that is true why should I, the designer, bother myself with these implementation details? A very good point if you, the designer, are content to work within previously established patterns.

For example, let us say you are designing for the Web around 2009. The Web is a very mature platform, with tons of frameworks and design patterns easily available. As a designer, you have the freedom to create an infinite variety of Web interfaces using the standard tools of the time, which would usually be a handful of applications provided by Adobe. This is all fine and good, and some really beautiful designs were created during this period.

However, one client of yours is a big fan of the iPhone, which by then had been around for only two years. They noticed that your beautiful design doesn’t look so great on the iPhone. Everything looks super tiny, and is hard to read. They ask you why, and you can only think, Well, that’s just the way it is. iPhones have small screens, so what is there to do? You might think that, unless you happen to be Ethan Marcotte.

Ethan is a designer who is not afraid of the technical details. In 2009 or 2010, he noticed some interesting things about the technical specifications for HTML and CSS. There was this new thing in the latest specification for CSS called “media queries”. Media queries allow authors of stylesheets to write different classes for different contexts, such as the printed page, or screen. They also allow authors to target different sizes of screen. With this knowledge, and several other concepts, Ethan introduced a new way of designing for the Web, which he called, “responsive design”. These concepts changed the way designers worked across the entire industry.

Yes, It Does Matter

If Ethan had settled for letting the engineers handle the implementation details of his designs, while he stuck to the world of Adobe products he would never have landed on his idea of responsive design. His curiosity and willingness to dive in and look under the hood allowed him to find solutions that had until then remained largely hidden to most designers.

The thing is, the way things work under the hood do have an effect on the end user. If you are truly interested in the end user experience, the more you know about how these experiences are built, the better designer you will be. An application that is slow to respond to user’s input is as much a part of the end user experience as the information hierarchy of the user interface. A search tool that can’t retrieve results relevant to the user’s request is terrible even if the display of the search results is visually beautiful.

Yes, software engineering is hard. I’ve been working at it for decades and I still feel like I have barely scratched the surface. I often feel like I am stretching myself too thin, going outside of my lane, trying to take on too much. Sometimes I feel like I am neglecting the visual design aspect of my practice too much. But I persist, because I truly believe that in order to truly master the art of software design, one must strive towards mastery of all of the components that make up a product.

The end user doesn’t care what was used to make the product go. But the more the designer does care, the better it will go.

Keep trying. It is hard, but it is also fun!