Developers—that is, those who spend most of their time on back-end code rather than front-end—often say that they’re no good at design. Sometimes they put things together that end up looking rough, and they take it as proof of their lack of design talent. Of course lacking experience is a major reason for this, but I don’t really buy it that developers can’t design. I think there is something else at play here.
When you write code, the end product either works or doesn’t. There is no sort-of-works stage. Yes, the software as a whole may have bugs which put it in the sort-of-works box, but its individual components either work or don’t work. Recently we’ve got the whole test-driven development movement which advocates writing tests first, and then the code.
Design is very different in that respect because it’s not black and white. There are no tests. The outcome will probably sort-of-work, and will have both, good aspects and pain points all around it. Scientific approaches such as A/B testing and user testing give you indications of how well your design performs, and will highlight the pain points for you, but the results are never as precise as they are in a code test that will return either true or false.
Design is a process of stone carving. With each hit of the hammer, the chisel chips away a small piece of stone. Many hits later the face of the stone begins to take form. The form is rough, so it will take more time to carve it down to the required shape. After each little bit of stone is chipped away the craftsman compares the result before him to the image in his head. Is it closer to this image—is this closer to what I want? Is it finished? Have I gone too far?
Good design won’t happen in an instant. A test won’t be run that will award the design a pass. Good design takes time and countless number of small updates that chip away pieces of rough stone one bit at a time. With each update, you ask yourself whether the outcome is closer to what you want or not. At the basic level, you run the test of: is it better than before—or closer to what you want—or not? If it’s better, you proceed, if it isn’t, you revert back. Again and again you make the small changes until everything begins to fall into place: fonts, colors, spaces, alignment. Pixel by pixel, color by color, you make the selections, you make the choices that influence the outcome, one little step at a time.
Developers may say that they don’t have an eye for design, so doing this sort of evaluation is difficult for them. But aesthetics isn’t the only thing you should think about. Ask yourself: is this font size easy to read? If not, what’s the problem? Maybe it needs to be larger, so you increase the font size. Maybe the color doesn’t have enough contrast with the background, so tweak that. Try and use your own product and see what annoys you. Chances are, things will. These pain points are what you should focus on. Once each little annoyance is under control, the end result will start to become beautiful simply because it is functional. What’s easy to use is good design, and this is also what the eye appreciates.
Unlike code, which must pass a test, design must pass thousands of tiny, subjective tests. It’s up to the designer to guide and form the end product, and for good design to take shape, countless ideas and iterations need to be tried and trashed. Can you go too far? Certainly. There will be a point where each iteration becomes to feel strained and tired, and you keep going back. At this point you should stop messing around with your work and let it be. But this stage isn’t reached quickly, and once you reach it, you will know.
Those coming from the development world should embrace the subjective nature of design and trust their own instincts on what they like and don’t like because this is the very thing that will be the test for your work. Don’t settle on the first draft, or the second, or third…iterate until the product begins to feel right, focusing on one thing at time. A good design will only get closer to being “right”, and there are a hundred “rights” that will all work. Learn the techniques that work, learn the fundamentals that will help guide your decisions, but the only way to move the work in the right direction is to put in the time by burning a thousand iterations.