It’s a very common sentiment nowadays that designers just have to learn to code if they care about their work. Even businesspeople are being encouraged to learn about code. But much more rarely are engineers told to pay attention to design.
At coding conferences and events you’ll hear a lot about the importance of test-driven development or other similar strategies to create better software. This is all great—it might make your code more maintainable, easier for yourself or colleagues to read, less buggy for the end user, etc. However, all of this is assuming you have a user to begin with. Much like this article will have accomplished nothing if nobody reads it, your flawless code is useless without someone to use it. If they’re turned off by ugly visual design, they might close it and forget it ever existed. Or if the user experience is poorly executed, they might become confused and either use the software incorrectly or give up and do something else.
User error is never just the user’s fault.
Something I hear far too often is, “if they use it wrong, then it’s their fault.” This is about the worst way to look at it. I’ve come to learn that user error is never just the user’s fault. It’s your fault, too, for failing to make it clear to the end user how something’s supposed to be used.
This brings me to Apple. Apple is known widely for their focus on design, but a common myth (one that Apple perpetuates) is that they’re successful because they have the best designers in the world. Their designers are incredibly talented, no doubt, but Apple’s success comes from a design-centric company culture. Engineers, managers, QA analysts—every person on every project is thinking about design.
Being a better
A final software product is a reflection not only on the skill of those who made it, but also on the communication abilites of everyone on the team. The job of a software engineer is not solely to code and the job of a designer is not solely to design; both need to communicate. A Photoshop mockup is one way of communicating. A screenshot of an implemented website might be another way of communicating. A personal favorite technique is to simply sit next to the designer until we’re both happy with what we’re making. Those are some examples of positive communication.
Some negative examples of communication that I see far too frequently include making dismissive comments like “it looks good to me,” or, “as long as it works.” If you’re an engineer, while your feedback can be helpful, it doesn’t really matter if you think the implemented product looks good if the designer says it’s not there yet. Even worse than this is to flatly refuse to finish a design-related task or resolve bugs relating to the design without actually communicating the reasoning for this. Sometimes, the only real reason for skipping these final steps is that on some level design-related tasks aren’t seen as being a “real” engineering task.
Those of us who care about design are willing to do whatever we can do to help make our product better. If I can spend half an hour adjusting margins, colors, and font sizes to make my product better, that’s what I’m going to do, because it’s not that hard and it will make it more inviting to the user. The return on investment from the user’s perspective is probably much higher than it would be for fixing some edge case bug or a small code refactor.
Other benefits of caring about design
Aside from creating a better product there are some other benefits to caring about design. It enables you to collaborate better, because the all-important communication level will increase as you begin to share technological advances to your designer. For example, you might make known a new CSS feature if you create Web applications or new design guidelines in an iOS release if you make mobile apps.
Design is, in some sense, about empathy
More generally, design is, in some sense, about empathy. Typically this is framed as empathy for your users, but this way of thinking—putting yourself in someone else’s shoes, considering how someone else who doesn’t have the same context as yourself might think about something—can be incredibly useful in life as well. How might this email I’m writing be perceived by someone other than myself? Would another programmer be able to understand this code, and should I restructure it to be more obvious?
I’m not asking you to go back to school for design or to spend all your free time reading design blogs or anything like that—changing your attitude is enough. But instead of maintaining the attitude that “I’m an engineer and the only thing I care about is if it works because that’s my job,” stop suppressing the part of your mind that says “this doesn’t make sense,” or “this is ugly.” If you’re having trouble figuring out how to use some software, even if just for a second, make a mental note of it.
On the other hand, if I’ve piqued your interest, here are two great online resources that any coder could use as a jumping-off point: