Architect vs Engineer
“An architect’s dream is an engineer’s nightmare”
Engineers tend to hate architects. I don’t blame them.
What I think most engineers don’t realize, however, is that it has to be this way. An architect’s job is to push the limits of design and creativity, not to compromise with engineers to make their lives easier. An engineer’s job, then, is to implement the architect’s design, no matter how hard it might be. This tug-of-war between the two roles is necessary, because without it we’d all be living in boring concrete cubes, or whatever design is easiest for engineers to make. Engineers do enjoy solving hard problems, they just don’t care much for aesthetic or usability, or any problem that an architect would care about.
The idea that design and engineering should be separate functions seems like common sense, but I think a surprising amount of people don’t understand it. If the roles are combined then it’s a lot easier to take shortcuts, since no other party is pushing for their priorities and keeping you accountable for your work. Projects without a clear separation of roles tend to end up mediocre – unremarkable in both design and engineering.
An enthusiastic, visionary architect can push engineers to achieve feats previously thought to be impossible. When the Sydney Opera House was designed in 1957, engineers didn’t even know if the futuristic structure would stay up. It took 4 years of experimenting before they found a workable solution, and another 10 before the opera house was completed, but it did work [1].
However, it’s not enough that design and engineering be separate. Architects need to be naive.
In an ideal world, an architect should have no knowledge of engineering constraints. If they do, it corrupts their creativity. Granted, we don’t live in Minecraft world, so we can’t design floating houses – there are some constraints. But many constraints aren’t actually real, so working within them is a sure way to stunt innovation.
Software
The architect-engineer dynamic extends to all areas of product design.
Different user interface frameworks make it easier to create certain UI components. Apple’s UIKit has built-in components for card-like modal screens, date pickers, tab bars, and plenty others [2]. Material UI for React has “navigation drawers” (aka side bars), which you often see in SaaS applications.
These components were created to make software development easier. They can and should be used in certain situations, since it doesn’t make sense to develop every component from scratch. But at the same time, built-in components aren’t fully customizable and may not fit the needs of your product.
If a designer is overly aware of built-in components, they may instinctively default to using them in their designs, even when a different design might be better.
Taking the naive approach, you might come up with designs that are unconventional or difficult, but are actually much better for the user. Take this screen from Zenly:
The half-modal chat window here is impossible to create with a built-in iOS modal component. However, it makes more sense for this window not to take up the full screen, so users can see where their friends are before they chat with them. A full-screen modal would be disruptive. The custom component certainly took more effort, but it paid off in creating a better app.
I don’t mean to imply that constraints aren’t a meaningful part of the development process. Not everyone has the resources of Google, especially not early-stage startups. There is a time to make compromises based on cost, efficiency, and difficulty, but that comes after the initial design is finished. The initial design serves to set the ideal vision for the product, and that vision can’t be corrupted by constraints. Even still, a designer shouldn’t be easily won over by impatient engineers. They need to continue to push their vision all the way to completion, breaking through false constraints along the way.
Physical Product Design
Here’s a story about Steve Jobs and the NeXT Computer. Steve decided the NeXT Computer should be shaped like a perfect cube. This posed a nightmarish problem to his engineering team, due to the constraints of the cube’s manufacturing process.
The computer case was to be manufactured by die-casting, which injects liquid metal into a mold, then cools it down and ejects a completed part. Straight walls make it nearly impossible to eject a part from a mold, which is why most die-cast products have a slight taper (called a draft angle) on their faces. Jobs wouldn’t compromise on the perfectly straight edges of his cube, so the part had to be custom-made (for a lot more money).
If Jobs had accounted for the manufacturing process in his initial design, he would have settled for a slightly angled cube as “the best we can do”. But being the design purist that he was, Jobs envisioned a perfect cube and wouldn’t be satisfied with anything less. Because of that, he made a better product [3].
It’s probably true that 99% of NeXT customers wouldn’t even notice that level of detail. But design in its purest form doesn’t compromise on anything, not even the slightest details. Others will argue which details actually matter – whether you can skimp out on some and obsess over others – but there’s really no way to meet in the middle. You can’t pick and choose which details are important; you have to treat every detail like it’s absolutely essential. This isn’t like raising prices or running a search ad campaign, where you can immediately and accurately track success. But design purity does matter, even if it seems invisible. Some of your users will notice, and they will adore your product, and become your biggest evangelists. Others will notice the overall design quality, but won’t be able to pinpoint it to a specific detail. And how do you determine which details will have the greatest impact on which users? [4]
Jobs had an exceptional ability to not only design naive visions of the future, but also to champion that vision all the way through to completion. Some called it his “reality distortion field”. He didn’t compromise, because he knew the constraints were fake and that pure design would always matter more.
I’m sure that Steve’s engineers loathed him for his obsessive standards, and I probably would have too. But you don’t make big leaps in innovation without insisting on the best design, even if it seems impossible.
Consumers
People always complain that consumers are ungrateful. That they don’t appreciate the hard work needed to make a great product. Consumers demand ever-better technology, without stopping to think how hard it is to actually build it. I see this as a feature, not a bug.
Consumers have zero knowledge of the engineering process. All they know about is whether the end result works, and solves their problem. If you think about it, designers actually act as a proxy for what consumers want. So if consumers are naive, then designers need to be naive as well.
If consumers knew about the herculean difficulty in building products, then they’d subconsciously demand less of them. They might think it’s fine if amazon.com crashes every once in a while, because they understand how hard the employees work and how hard network engineering is and how hard it is to serve millions of customers every day. And yes, it’s really fucking hard.
Instead, they demand perfection, for everything to “just work”. Consumers are an unrelenting forcing function for creators, and this leads to a lot of resentment between creators and consumers. But again, that’s a feature, not a bug.
Watch this clip from a Louis CK comedy special. The clip is from 2011, when in-flight wifi was just beginning to appear on airplanes. Louis was on one of the first flights with wifi, and was amazed that such a technology even existed. Halfway through the flight, however, the wifi broke, and the guy next to him was pissed. Louis complains to him, “dude, how does the world owe you something that you didn’t even know existed 30 seconds ago?” His point: technology is a miracle, so don’t be so pissed if it isn’t perfect.
But if everyone thought like Louis CK, then our wifi would suck. Forever. (In-flight wifi still sucks, but not nearly as much as it did in 2011). Nobody cares about the billions of dollars and technological breakthroughs needed to make in-flight wifi a reality. People just want to watch Netflix on their way to Mexico. If you can’t make that happen, then they’ll get pissed, nobody will pay for your wifi, and you’ll go out of business.
This is why people who work in engineering/technology also tend to be early adopters. We know “how the sausage is made”, so we’re more tolerant of buggy products. However, it’s a mistake for us to think that everyone else should see it this way.
What makes it extra hard for designers, unfortunately, is that they also tend to fall in the early adopter camp. Designers are involved in the product creation process, so they know how it works. That’s why it’s especially important to erase these biases in the design stage. If you don’t, then your users will notice.
Early Stages
If design and engineering should be entirely separate processes, then how do you accomplish that in an early-stage team, where there isn’t a clear separation of roles? It's not as easy to do, but I've found a few ways to practice naive design in small teams or independent projects.
Design first, then implement: Never try to flesh out aesthetic design details (spacing, corner radii, accent colors) in code. This drastically increases iteration time, and subconsciously forces you to compromise on design quality. If it takes me a minute every time I need to tweak the spacing between two elements, I might stop after a few iterations, rather than taking the full amount of time to perfect my design.
Push yourself: When designing, try to erase all engineering limitations from your memory. You can’t fully erase your knowledge of a UI framework’s pre-built components, but be skeptical of your design choices. Does that sheet really need to be a full-screen modal, or should it be half? Do we really need to add a 2-degree draft angle to this part? When you question your decisions, you may find that you aren’t thinking big enough.
Final Thoughts
Let design push the limit and have engineering work to catch up. Naive design may feel like an excessive and ridiculous process, but it works. When designers know too much about constraints, it corrupts their creativity.
There's some limit to the level of perfectionism you can demand in the design process, but I don't know where that limit lies. I think it ultimately comes down to the individual's personal conviction and risk appetite. My point is more against letting constraints dictate the design process, rather than pushing for the utmost design purity. The reality is that it's much easier to let engineering limitations guide the process – to build around what you know, rather than what users want. Sadly, this ends up being the default in too many teams.
Naive design can be more broadly applied to startups as a whole. The boldest startup ideas usually attract the most vocal doubters. The doubters argue that the idea will never work given current constraints, but they usually don’t consider if those constraints are actually meaningful. In the case of successful startups, they aren’t meaningful.
So someone can suspend disbelief and start a futuristic company, even if it’s not entirely clear how they will do it. Being naive definitely helps here. If you’re too much of an “expert”, you get caught up in current limitations and defer away from bold new ideas.
Notes
[1] Their work involved one of the earliest known uses of CAD for structural analysis. In other words, these engineers resorted to unproven, cutting-edge technology in order to make this design a reality.
[2] I’m surprised that tab bars are the de-facto navigation scheme for like 99% of apps. It’s a good interface, but I figured there might be some other way to handle navigation. Every tab bar looks the same.
[3] I know that the NeXTcube was a commercial flop, but I’d say that Jobs’ sweat-every-detail design philosophy served him well in the long run.
[4] It’s true that some wildly successful companies (Amazon, Microsoft, Craigslist) didn’t devote this level of attention to design. Design is a very strong differentiator for success, but it’s not necessarily a prerequisite, if you have strengths in other areas. There’s also design in the utilitarian sense (give people the stuff they want), vs design in the aesthetic, “delight the user” sense. This might deserve its own post…