Don’t design like a programmer

"Error establishing a database connection"<p>Don't program like a designer?

I'm not quite <i>this</i> bad, but here's one of the things that happens to me:<p>Very early during the programming process, I'll create a debugging console -- an arbitrary, ugly GUI that lets me control the values in the data structure. For testing.<p>Weeks later, when I want to design an intuitive interface, that debugging console seems <i>very</i> intuitive to me. It's hard to ask, "Where would a user who wants to do X look?" since I've done it hundreds of times and <i>know</i> where to look.

One of my clients explained this phenomenon perfectly to me once, and it's an explanation that I've yet to see anywhere else.<p>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.<p>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.<p>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.

This programmer design fallacy got started by the Mormon church (not kidding): <a href="http://portal.acm.org/citation.cfm?id=169163" rel="nofollow">http://portal.acm.org/citation.cfm?id=169163</a><p>Gregg "Skip" Bailey, Manager of Human Factors, The Church of Jesus Christ of Latter-day Saints.<p>Iterative methodology and designer training in human-computer interface design, Proceedings CHI '93<p>This pseudo-scientific study pitted Skip and his team of highly trained designers versus old mainframe programmers (two of whom graduated college). They used an interface design tool--Skip and his design team had prior experience with it--to create interfaces for retired Mormon volunteers. The retirees made more errors with the programmer's interface and presto.. the myth of poor programmer designers is born with all the statistical significance generally found in CHI papers.

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.<p>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.<p>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.<p>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.<p>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.

Another good book to read along this vein is <i>The Design of Everyday Things</i> by Donald Norman. He talks a lot about designing things which <i>afford</i> being used correctly; that is, you can't help but use them the right way, just based on the way they work. His favorite anti-pattern is the "Push" door with a "Pull"-handle on it, or a "Pull" door with a "Push"-plate on it. The door, like the programmer's interface, exposes more options than are relevant to the actual use case.<p>This is actually a very empowering mindset: If you push a "Pull" door, or pull a "Push" door, <i>you</i> are not the moron! In fact, it is the person who put a "Pull"-handle on a "Push" door! This viewpoint turns PEBKAC on its head. If a user runs a script that he thinks will configure his bootloader, but instead it erases his filesystem, who is the moron? The user, or the process which produced a script that can be run in a way that will erase your filesystem?<p>The worst offenders I've ever seen in this vein are Atlassian. The admin interface to their products, particularly JIRA, is basically a glorified database query GUI; there is no indication how each of the parts fit together, and 9 out of every 10 possible configurations you can create are actually broken.<p>The problem is that you can't design a better interface without thinking about how other people will <i>actually</i> use your app, and that's extremely difficult. However, it's useful to look out for signs that you are Doing It Wrong. The "programmer's interface design" from the article is one of them. Another is the phrase "Well, at some point, somebody might want to..." If you hear this phrase repeated frequently during discussions about feature or interface design, panic! It means you don't know what your <i>use cases</i> actually are.<p>This is one of the ways I think Agile development can be extremely helpful, but no one seems to practice it in a way that leverages this type of benefit. Thinking about things in terms of user stories <i>forces you</i> to make these kinds of decisions, and you almost can't help but design the interface better.

Google cache: <a href="http://webcache.googleusercontent.com/search?q=cache:qmKT38NBp1kJ:www.uxdesignedge.com/2010/03/dont-design-like-a-programmer/+http://www.uxdesignedge.com/2010/03/dont-design-like-a-programmer/&#38;cd=1&#38;hl=en&#38;ct=clnk&#38;gl=uk&#38;client=firefox-a&#38;source=www.google.co.uk" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:qmKT38N...</a>

These design articles are interesting but I wish more would provide examples of what you <i>should</i> do instead of just what you shouldn't.

Good analysis, but…<p>I think the main problem is not that programmers are programmers… but that they are not <i>designers</i>. 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.<p>So basically: people who are not designers make mistakes when doing design. Who would have thought?

True enough. I don't struggle with that stuff though. You can be a programmer and still laser-focus on usability. What we can't do (those who don't possess both skills) is make things easily pretty. I tell my designer friends this: when you picture a person in your head, you see a lot more detail than I do. I see a circle, eyes, a mouth, a nose, and a hairline that stops somewhere on the forehead. You see exactly where that hairline stops. And how it falls down the side of the head. And where the shading on the cheeks go. And the ridges on the lips. I don't see those things. I like the imagination. It's why I can never be a designer; it's not in my DNA. It's why I favor extremely simplistic designs, easier to make look relatively attractive.

That was a really good article. I definitely find myself making some of those mistakes when I mock up forms for websites I'm developing

Code like a programmer, design like someone who will use it. The best approach is if you can get some test data, in order to directly experience using the system. If the user enters dates a lot, you better make the date entry method as painless as possible (no mouse popup on dates, maybe even allow for - or . as separators so operators can stay on the number pad, etc.).<p>Do they enter bulk records more than one-ofs then have it so they can bulk-enter a group of records, etc. If you were told to do the entry what would you want to make your life easier.<p>As a programmer we think of the computer and how it reacts when running our code, it also helps to think of the user and how they react when using the UI.<p>Of course I know a couple of the problems with this - frameworks and IDEs, some of which don't give the programmer easy access to custom interface elements (or by using such tools the programmer is never aware of other ways to implement a UI).

Thanks for linking to my article. Sorry about the "Error establishing a database connection," but there's been a lot of traffic today. Please try back later if you didn't get through.<p>(And, no I didn't write that error message. :))

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?

Many people have asked me to provide a good UI design for wGetGui. I've started this with a new post "Don’t design like a programmer, Part 2" (see <a href="http://bit.ly/lceiAx" rel="nofollow">http://bit.ly/lceiAx</a>).<p>Thing is, it would be a mistake to jump to a solution and the process behind the solution is ultimately more educational. So, I'm starting with the process and will apply the process to create a good design in Part 3.

Very good in general, but I think that requiring users to enter unnecessary personal information is much more the fault of marketing than the programmer.

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

Conversely, don't program like a designer: <a href="http://i.imgur.com/zqJpM.png" rel="nofollow">http://i.imgur.com/zqJpM.png</a>

Like most of us, he "suffers" from NADD (Nerd Attention Deficiency Disorder)

Unusually good article. Author knows what he's talking about.

404 error, guess it doesn't hurt to know how to program if you're making web sites. Otherwise nobody gets to see your designing abilities...