Rants From An Engineer: Design & Engineering — We Need Each Other
I’ve worked as an engineer my entire career (with some engineering management in the last few years). But I don’t fit into the category of people who were exposed to technology at an early age — I had to play catch up in college. As a child, I did, however, have an affinity for visual aesthetics. I can recall the very satisfying feeling I got when aligning or centering physical things—shoes, pencils, furniture, etc.—not on an OCD level, just an appreciation for patterns and symmetry in general.
I suppose that might also describe my love of software engineering, but there was always something else there — something that, on the surface, seemed superficial, but was extremely important to me. The perfect hue of blue…a well arranged coffee table — not too cluttered and not too bare. In hindsight, I realize that thing was design. Given this context, one could see why I have difficulty seeing a fundamental difference between data and how that data is perceived — context is everything. I think of it as two sides of a balanced equation.
I don’t think my love for design has anything to do with making things look pretty. For me, it’s about the human connection.
Design holds a special place in my heart. Ultimately, I don’t think my love for design has anything to do with making things look pretty. For me, it’s about the human connection. I’m an introvert. One misconception about introverts is that we don’t like people. Nothing could be further from the truth. Introverts value close relationships — the type of relationships which are forged from intentional conversations. These conversations help to construct cognitive wormholes — bridging inconceivably distant perspectives and folding them together in time and space.
In the professional realm, meaningful relationships lead to comfort and trust amongst colleagues, which in turn, reduce the friction associated with communication. So as an introverted, relationship-loving engineer who’s valued design since childhood, I see a disconnect between design and engineering and believe there are things we could do to deepen our relationship that will benefit our work, the product, and our users.
Transforming Canyons into Crosswalks
Currently, there are vast canyons dividing too many engineering and design teams. Sure, there’s some communication there, but we’re screaming at the top of our lungs and waving our hands about wildly. We’re each expounding way more energy than is ideal or necessary. Imagine if designers and engineers could consider each others’ goals and challenges from the start and share a deep understanding our of our users’ true needs.
Design, more than almost anything, requires a great deal of empathy. The ability to glimpse the beauty (and horrors) of the world through someone else’s eyes is how we transform canyons to crosswalks.
The Role of Empathy
I’ve seen talented engineering teams produce beautifully written software — only to have that same software never see the light of day, simply because for all of its beauty and elegance, it didn’t address any problems faced by the end user. We’ve all had the experience of navigating counter-intuitive processes to achieve a goal. Many times, the process itself completely undermines the very thing it’s supposed to enable.
We must establish a foundation of understanding and empathy to serve our users best. By “we” I mean everyone involved in the process of creating products and services—and here’s where engineers could benefit from stepping into the design side of the process, or at least making a deliberate effort to learn what insights design decisions are coming from. Only through this understanding will we be able to hear what our users ask for, and give them what they actually need.
If you understand people and the problems you’re working to improve, you’re more likely to achieve the latter. Steve Jobs once said that “…people don’t know what they want until you show it to them.” I believe this is a widely misunderstood statement. The presupposition here is a deep understanding of your users — that’s where most organizations fall flat.
As an engineer, I often find it difficult to get many of my colleagues to internalize this. Although there is certainly a degree of creativity to designing and building software, there is also a great degree of correctness. Creativity and correctness are not mutually exclusive, but it is much harder to strike the right balance. I’d argue it’s one of the most challenging aspects of the job of a software engineer. That balance is achieved only through truly understanding who the software is meant to serve, and good, human-centered design revolves around understanding just that.
A Case for Developers Learning Design
There’s a lot out there about the importance of designers learning to code. I can smell the dead horse in the next room over, so I’m going to put down my bat and close the door slowly. Now, let’s assume for the sake of argument that this is a pretty good idea and roll with it. What tends to get less attention (although is not entirely unexplored) is the idea that developers should learn more about design.
Engineers stand to gain a lot from learning to view the world through the lens of a user first.
One could argue that the designer should have some understanding of how things get implemented in order to better inform the design, and that the developer implementing the design doesn’t need insight into the design process to better execute their job. Abstractly, this makes (some) sense. You could even devise a clever mathematical argument for this point-of-view, complete with diagrams of one-way hashing functions! But in doing so, you’d miss the nuances of real life. Engineers stand to gain a lot from learning to view the world through the lens of a user first. Imagine how much insight could be gained if an engineer was engaged in user interviews. For instance, if a user indicates that he doesn’t realize a call-to-action button is clickable, a designer might consider ways to make it “pop” more, whereas the engineer might think to simply change cursor symbol and do a small 10% zoom on hover to indicate click-ability. I’m not advocating for one method of the other, the point is, it creates options that may have otherwise never been considered in the design process.
We Need to Learn Each Other’s Language, and Communicate Our Goals
Picture this fictional, but frustratingly common scenario: Tracy, a front end engineer sits at her desk at 11:30 p.m. Tracy’s had a long day. Her head hurts, she’s hungry, and she’s been making changes to the design of a product since yesterday afternoon. The product launches at 8 a.m. sharp. To her left, sits Deven — a handsome mustached designer who has been carefully observing Tracy write CSS for what feels like her entire life, but in reality, “only” seven hours or so. Deven sits there, twirling his mustache while sipping his homebrew and says, “Let’s try 10 pixels to the left.” Then, “Hmm, no, it looked better the other way — change it back. Oh, I’ve changed my mind about the hue of the colors can we tweak this? Finally, let’s adjust the typography.”
Tracy is understandably frustrated. She wants to do right by the product, but emotionally, she has nothing left to give. Resentment begins to fester as Tracy begins to believe Deven has no respect for her personal life and is only concerned with his design reputation. Deven, while a bit more patient, feels as though Tracy is not committed to delivering a great product and is only concerned with getting home so she can connect with her fellow developer friends and play fancy online games. Tensions are high; they talk at each other rather than converse. No one’s going home anytime soon.
The above scenario isn’t uncommon at all. Deven doesn’t seem to be fully aware of the scrupulous (and dangerous) nature of making one-off changes to a product that’s hours from launch. However, Tracy is equally at fault in that she did not utilize the exact hex values from the color palette, or the correct typography spacing settings supplied by Deven, which led to a significant decrease in the accessibility of the content. Things don’t have to be this way! The scenario results in a culmination of missed opportunities by both Deven and Tracy to truly understand the challenges of the other.
How to Learn from Each Other and Shrink the Canyon
If you ask around the tech field about what the next big computing revolution will be, you’ll hear a lot about Machine Learning (ML). I’m not one for predicting these sorts of things, but there are good reasons to believe the hype. One of the big enablers of the ML revolution is the ubiquity of data. Data is king — that’s where it all starts. If nothing else, design and engineering can converge on how we view and think about data and its importance to our users. This can help inform decisions about what’s actually important — a signal versus noise type of discussion. One need not be technical to talk about data, nor does one require an eye for aesthetics. Data is the very soul of a system — outliving the majority of refactors and redesigns. It’s the core.
Cross-discipline learning is also immensely valuable. Designers, attend front-end code reviews. Learn how you can help optimize the UI through performance and reusability. Images, fancy typography, animations…they call come with a price. Work with your development team to understand the trade-offs and do what’s right for your product. Developers, attend design reviews. Wireframes structure content. As a developer (especially a back-end developer) you have first-hand knowledge of how data is (or should be) structured at its source. Use that knowledge to help inform decisions early on.
I’m hopeful that communication barriers can begin to be overcome through increased interaction and feedback. Separate, our view of the world is fragmented, incomplete and naive — our data is incomplete. Together, we can better construct an accurate image not only of the world as it exists, but as it should be. Our users are counting on us to get this right. Let’s not let them down.
Into this stuff? We’re hiring! Check out our open positions here.
