I’m a seasoned hacker that is able to tackle immensely complex problems with aplomb. I’m able to untangle spaghetti code and weave it into beautiful patterns. I envision systems and code them with the same grace a jazz pianist improvises music.
But I can’t design for my life. Please help.
I’ve heard this story a couple of times in the ten years I’ve been working with programmers. Programming is a damn hard craft to learn. My mind is blown by the level of complexity software has achieved given the basic elements of programming—variables, conditions, loops, functions and objects. At times, it feels like you have a quarry, wood, rope, a saw, and a chisel and then an architect asks you to build a cathedral.
The programmers’ approach to building a cathedral would involve using his tools and raw materials in order to build more advanced objects. Let’s imagine the work of this craftsman: he’d grab some wood and stone in order to create a hammer, then he’d devise some pulleys to get rocks out of the quarry, he would build platforms and scaffolds to reach unaccessible places, he’d fabricate a crane to stack the stone, and so forth.
Our craftsman follows the architect’s plans religiously, and painstakingly chisels every stone so that every brick fits in perfectly. He polishes the wood into a huge sculpted door that would accommodate God himself. The massive columns wouldn’t fall in a thousand years.
Once finished, he steps back and mesmerized by the beauty of it all, he thinks ‘Hey, I built this cathedral all by myself, perhaps if I tried designing my own cathedral I’d get all the praise, instead of this lazy hack who just handed me the layout and waited for it to be built’.
Of course, when a programmer first tries his own hand at designing, he will likely notice that it looks pretty clumsy, there are a couple of reasons for this, but—all in all—the odds are stacked in his favor. It is absolutely necessary to identify the shortcomings of the programmers’ mindset in order to overcome these obstacles. Later on I’ll detail what works out in his favor.
1. Being familiar with the implementation difficulty encourages compromises
I’m a designer by trade, I have a degree in Information Design. But—as often happens— ignorance instills confidence, and I jumped into programming expecting it to be a challenging hobby, but it actually sucks you in and you come out a different person. I’m not a competent programmer by any measure, but it is an activity I enjoy throughly. I’ve built memela.com entirely on my own, you can also see my portfolio. Here is my StackOverflow profile. The paradox of learning is that the field is just so huge that you must admit you’re not able to master it in your entire lifetime.
When I first started programming, I’d start sketching a general idea on paper, and when I’d grow bored of it, I’d jump into Textmate and bang some code. Sometimes I’d encounter that a particular feature was difficult to implement, so I’d go back to my sketch and rework it so it was easier to implement, even if the user experience suffered in the process.
This, I think, is the biggest mistake programmers make when designing their own products. This is a form of technical debt that is incredibly expensive if done repeatedly, but it’s very tempting when you’ve been struggling with a particular problem for some time.
Nowadays I separate the designing and programming phases completely. I start by sketching on paper, then create a pixel perfect mock-up and then I finally start programming. If there is something that I find hard to implement, I ask for help, making me a better programmer in the process.
The equivalent of our medieval craftsman would be noticing that the doors of the cathedral are a lot of work, so he replaces it with a standard sized door. Soon enough the cathedral is inaugurated and there’s an unsurmountable bottleneck when the crowd tries to enter the cathedral.
2. Data modeling clouds your understanding of use cases and tasks
Nailing the data models is the hallmark of a competent software architect. It sets the foundation for clean, understandable code. Unfortunately, it also provides a data centric view of the entire project; and when the software architect designs the graphical interface, it looks a hell lot like the models with a CRUD interface slapped on.
Programmers get a lot of unjustified heat for designing these kind of interfaces. Very few people understand why data modeling shapes a very strong mental model of how the interface should work. This problem is often painfully obvious in backend administration systems, where the programmer is left on his own because designers are busy on the public side of the application. Often programmers rely on automated admin tools because—despite being a crucial component—clients don’t want to pay for it.
The key to escaping mental model contamination is thinking in terms of use cases and tasks. Whereas duplication and redundancy are the bane of good data models, it often is the opposite for use cases. In some supermarkets you will find mayo next to the tuna, a cereal island next to the milk refrigerators, and Clamato next to vodka (as well as in the usual places). Let me use information where I need it, not where the data model dictates it should be.
3. Most design is written about and taught from the perspective of art
When I was younger I would ask people how to dance, they would often suggest to “feel the music”. Once you feel the music you can start moving your body along with the rhythm, or so they said. “Just tell me how to move my feet and my arms”, this would invariably turn out wrong, because I’d just flail my arms at my own pace. A sad spectacle that I’d prefer to forget.
It wasn’t until the Rockstar type of games started coming out that I finally understood what they meant by feeling the rhythm. There is a bass that marks the predominant rhythm and some other instrument that marks a secondary rhythm. You pace a range of pre-defined movements to these instruments and boom, you’re dancing half decently. But alas, this revelation came too late and I’m still a terrible dancer.
Perhaps you have already asked a designer where to get started with design. I’m pretty sure his advice was to observe things carefully, notice the details, copy things you like to understand how they work. This is good advice, but it’s the same thing you would tell someone learning how to draw.
This is what I call art oriented advice and it’s the same kind of advice I was being dispensed when I asked how to dance. It’s useless to logical minds because when you like something you just don’t know what you’re supposed to be looking at. It comes naturally to people who have some art experience because they are used to observing proportion and balance.
People often make of design some sort commercial spawn of art. It is not. Design is a discipline in itself, related to engineering, that uses some of art’s syntax (in the case of visual design). It is different from engineering in the sense that engineering looks after the efficiency and robustness the product, and design looks at the interaction between the product and a human being.
Now, let’s get to the good stuff:
You are already a pretty good designer
If you have been programming for a number of years, you probably have very good design and architectural coding skills. These skills are connected to visual design at a high level of abstraction. The connections are so strong you can face off two masters of their own field and it will make sense to senior designers and programmers alike. In fact, I’m going to face Edsger Dijkstra against Charles Eames .
Design depends largely on constraints.
The ability of discerning high quality unavoidably implies the ability of identifying shortcomings.
Innovate as a last resort.
The competent programmer […] avoids clever tricks like the plague.
Who ever said that pleasure wasn’t functional?
There should be no such thing as boring mathematics.
Everything you already know about design and architecture in programming can be applied readily to visual design, with few exceptions. The problem is that your skill set is domain specific. You don’t have the bridge to apply what you know about software design into visual design.
You are already creative
Perhaps you have bought into the bullshit that creativity is a state of mind, an eureka moment that bursts into flash of brilliance to produce something that has never been done before.
I’d go as far as saying that the popular conception of creativity is actually harmful to good design, as it relies on established conventions in order to function. There is a time and moment to innovate, but it should never be done for innovation’s sake.
Creativity is being able to create things. Objects that can be shown, discussed and built upon. In this sense programmers are much more creative than many so called creative professionals out there.
Your systematic mind can be used to your own advantage
One of the most difficult concepts to teach young aspiring designers is the ability to think in systems. If I requested a button in 99designs (without more context), people would jump at the chance of creating shiny realistic buttons. You probably know what is wrong with this scenario: you can’t design a button without knowing how the rest of the design looks.
This is something that takes many years to mature in a designer, because the relationship between visual elements is not as obvious as it is in code. I’m not only talking about consistency, but the profound understanding that each element competes for attention, and that by making an unimportant element “shine” you are detracting from the rest of the elements.
You already have attention to detail
In a scale from 1 to 10, how sinful is choosing a poor name for a variable?
Now, in the same scale, what number would you chose for code where every variable had an awkward name?
This is attention to detail. Knowing that the details make the product itself. I’m constantly amazed by the discipline of some programmers, their code is carefully formatted, comments are succinct, and the structure is evident by just looking at it.
So, how do you get started learning design?
Design education is quite different from other disciplines. It needs to be so, because design is concerned as much with skill acquisition as it is with knowledge acquisition. It is project oriented, because that is how design is professionally articulated. Design is not subjective, as people often say, it’s meant to solve a problem, and the problem may have different solutions, some better than the others.
The actual structure of design education is centered around the design critique: the teacher explains some concepts, then asks his students to articulate something visual around those concepts adding some constraints, and then the final work is discussed as a group.
The actual critique mechanics are quite interesting. Every student lays their work on a large table, and the teacher will chose one, and ask other students what they think about it. At this point, authorship isn’t important. It’s likely the teacher and his peers don’t know who made it. The objective is not criticizing the student, it’s criticizing the piece of work. So a student volunteers an opinion, and the teacher validates it. After a small round of opinions, the teacher gives some insight and moves on to the next piece.
I’ve been thinking long and hard on how to replicate this experience online in a way that scales. I’ll extend it to other disciplines, but the initial course will be on design for programmers. If you are interested sign up to be notified when we launch, or just follow our Twitter. We will be writing more on this blog about the relationship between design and programming. Keep tuned.
