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.
Don’t design like a programmer
21–30 of 34 posts
Re: Don’t design like a programmer
#22This programmer design fallacy got started by the Mormon church (not kidding): http://portal.acm.org/citation.cfm?id=169163
Gregg "Skip" Bailey, Manager of Human Factors, The Church of Jesus Christ of Latter-day Saints.
Iterative methodology and designer training in human-computer interface design, Proceedings CHI '93
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.
Re: Don’t design like a programmer
#23These design articles are interesting but I wish more would provide examples of what you should do instead of just what you shouldn't.
Exactly. I've seen the GUI wget example held up as a bad example [1] before, but I've never seen anyone try to produce a "good" wget interface.
[1] http://www.codinghorror.com/blog/2006/11/this-is-what-happen...
Re: Don’t design like a programmer
#24These design articles are interesting but I wish more would provide examples of what you should do instead of just what you shouldn't.
Exactly. I've seen the GUI wget example held up as a bad example [1] before, but I've never seen anyone try to produce a "good" wget interface. [1] http://www.codinghorror.com/blog/2006/11/this-is-what-happen...
Well, who's the user?
Re: Don’t design like a programmer
#25I'm not quite this bad, but here's one of the things that happens to me: 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. Weeks later, when I want to design an intuitive interface, that debugging console seems very intuitive to me. It's hard to ask, "Where would a user who wants to do X look?" since…
I've been there but found that having a debugging console (or generally, using any UI over and over to repro some steps while you're developing) ends up being a huge time sink. It's often much more sensible to invest time into building a unit test to guide your development instead. As a result, now I don't create much debugging UI but try to unit test, which gives me more time/inspiration to build actual UI. (Borrowi…
That's very sensible actually, but how do you explain the free cost of automatically generated CRUD and admin panels?
Re: Don’t design like a programmer
#26Seems 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…
Not sure I agree with the sequencing. The basic message is that designing your presentation with the expected viewer in mind is really important. For code, it's designing it such that another programmer can grok it easily. For an interface, it's an end user.
To that end, I think it's a good thing that we recognize these are different roles. The fact that each role has a different set of audiences means they can specialize in catering to those audiences, which improves effectiveness. The issue is when we DON'T recognize the difference and try to lump them together.
Re: Don’t design like a programmer
#27Unusually good article. Author knows what he's talking about.
Re: Don’t design like a programmer
#28One 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 mo…
To put it another way: being a good software developer requires the ability to internalize and traverse complex mental models entirely within your head, then convert them into a set of models and rules that implement that mental model for others to use. So as a group, developers are self-selecting for being very tolerant of a relatively complex UX relative to the median user.
I suspect you could find this in other fields - for example, I'd be that a commercial airlines pilot is pretty good at maintaining a complex mental model of his aircraft's systems in his head. But very few of those fields are asked to create products / experience for a set of users that does not have that same capacity to deal with abstract mental models.
Making that worse is the fact that at least in most physical systems, there are constraints on complexity and process, or established social scripts for a process. (E.g. most of us "know" how a restaurant works, and we all definitely know how the ordering process works.) Software doesn't have those constraints so you can get into trouble fast.
Re: Don’t design like a programmer
#29These design articles are interesting but I wish more would provide examples of what you should do instead of just what you shouldn't.
Exactly. I've seen the GUI wget example held up as a bad example [1] before, but I've never seen anyone try to produce a "good" wget interface. [1] http://www.codinghorror.com/blog/2006/11/this-is-what-happen...
ffmpeg is far more complex than wget, and has some seriously intimidating output for "--help", but it does the sensible thing of guessing intention from file extensions/suffixes. `ffmpeg foo.bar foo.quux` will just convert your file, silently.
Re: Don’t design like a programmer
#30Like most of us, he "suffers" from NADD (Nerd Attention Deficiency Disorder)