Don’t design like a programmer

One of my clients explained this phenomenon perfectly to me once, and it's an explanation that I've yet to see anywhere else.

Programmers are accustomed to thinking in abstracts: data structures, pointers, memory addressing, program logic, pipes, files, and so on are all abstract concepts. Although you can describe them using strained metaphors for the real world, they don't really represent real-world things.

But most people don't think that way; they think in terms of the tangible. That's part of why the concept of the computer "desktop" is so confusing for novice users, or why the idea of layering in a user interface is nearly not navigable for new users.

It had never occurred to me that other people didn't think in abstracts. I grew up programming; I learned my first programming language while I was also learning my first human language.

I guess bad design is an habit that we programmers carry from school. I don't know what about American education, but in my college proffesors use to ask for functionality not for good designed interfaces, and that habit is difficult to quit, users don't know anything about design either, so you show your final product, it works, the system does what it should, and they are happy they won't tell you, hey! this form has too many textboxes, or hey! why are you designing like a programmer?

Seems like a better way to put it is: Design first, then develop. Which, in my experience, is a good idea whether you are responsible for the design or not.

If you have no data structures or other programming limitations to work with, you can focus on perfecting the interface and then worry about making it happen. If you already have the program written, it is natural to want to take the easy way out and just slap up a form that matches the code.

An aside, being someone who enjoys playing both roles, I find the design phase goes a long way to improving the structure of my application because I have time to get a better understanding of the requirements, program flow, etc. Every element I draw automatically turns into code in my head, thinking about how it is going to be implemented as best as possible. The program is already written long before I ever touch a text editor.

Furthermore, programming is design. A programmer's job is to write code that is not only functional, but code that is visually appealing. Visual appeal is the factor that makes code maintainable or not. It is basic human nature to want to work on pretty code and reject ugly code. As such, it is wrong to say programmers do not have artistic talent. They exercise it each and every day. The only thing many programmers lack is practise in designing visual interfaces.

Given all of that, I find it very unfortunate that we try to separate the design and development jobs. I understand the business appeal of trying to do the job twice as quickly with two people, but from a fundamental point of view, the separation only goes to hinder the quality of our software, in my opinion.

Why the absence of pictures? I'd expect a more, ahem, user-friendly approach than walls of text from a UX blog. A picture is worth 1,000 words.

Good analysis, but…

I think the main problem is not that programmers are programmers… but that they are not designers. I think anyone who is not a designer can make similar mistakes. Ask someone (who is not a programmer and not a designer) to design a interface and you could probably find many of the same problems.

So basically: people who are not designers make mistakes when doing design. Who would have thought?