I'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 done it hundreds of times and know where to look.
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.
(Borrowing words from the article) Warning sign: During the development, dozens of times, I have to go through step 1 in my UI, select a person, go to step 2, enter an address, select a state, go to step 3, and so on.
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.
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.
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.
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.
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.
Another good book to read along this vein is The Design of Everyday Things by Donald Norman. He talks a lot about designing things which afford 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.
This is actually a very empowering mindset: If you push a "Pull" door, or pull a "Push" door, you 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?
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.
The problem is that you can't design a better interface without thinking about how other people will actually 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 use cases actually are.
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 forces you to make these kinds of decisions, and you almost can't help but design the interface better.
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?
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.
I agree. The article is actually pretty good and provides useful tips. Even as a programmer I've many times been annoyed by these kinds of UI laziness, usually in "enterprise software".
It's not only programmers that make these kinds of mistakes, though. Also designers that come from a "forms on paper" background, or simply don't know enough of HTML/JS to make friendlier forms. So they simply make an unending list of text fields...
My most common annoyance with forms on the web is asking things that you A) don't need to know or B) already know.
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.).
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.
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.
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.
I received some feedback that my article was disrespectful to programmers. That wasn’t my intention—rather my goal was to explain why these are such easy traps to fall into if you are thinking about the code instead of your users.
I’m a developer myself and I want to help other developers raise their UX game—in fact, I’ve built my business on training interaction design to non-designers.
If you are a developer who wants to improve your UX design skills, please check out the rest of my site.
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 http://bit.ly/lceiAx).
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.
[+] [-] kwis|15 years ago|reply
Don't program like a designer?
[+] [-] StavrosK|15 years ago|reply
[+] [-] roc|15 years ago|reply
[+] [-] Dove|15 years ago|reply
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 done it hundreds of times and know where to look.
[+] [-] d_r|15 years ago|reply
(Borrowing words from the article) Warning sign: During the development, dozens of times, I have to go through step 1 in my UI, select a person, go to step 2, enter an address, select a state, go to step 3, and so on.
[+] [-] thaumaturgy|15 years ago|reply
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.
[+] [-] tomkarlo|15 years ago|reply
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.
[+] [-] rohwer|15 years ago|reply
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.
[+] [-] skidooer|15 years ago|reply
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.
[+] [-] saraid216|15 years ago|reply
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.
[+] [-] mcantor|15 years ago|reply
This is actually a very empowering mindset: If you push a "Pull" door, or pull a "Push" door, you 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?
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.
The problem is that you can't design a better interface without thinking about how other people will actually 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 use cases actually are.
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 forces you to make these kinds of decisions, and you almost can't help but design the interface better.
[+] [-] Ysx|15 years ago|reply
[+] [-] statictype|15 years ago|reply
[+] [-] GregBuchholz|15 years ago|reply
[1] http://www.codinghorror.com/blog/2006/11/this-is-what-happen...
[+] [-] TorbjornLunde|15 years ago|reply
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?
[+] [-] MatthewPhillips|15 years ago|reply
[+] [-] pspeter3|15 years ago|reply
[+] [-] wladimir|15 years ago|reply
It's not only programmers that make these kinds of mistakes, though. Also designers that come from a "forms on paper" background, or simply don't know enough of HTML/JS to make friendlier forms. So they simply make an unending list of text fields...
My most common annoyance with forms on the web is asking things that you A) don't need to know or B) already know.
[+] [-] LarryA|15 years ago|reply
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.
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.
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).
[+] [-] everettm|15 years ago|reply
(And, no I didn't write that error message. :))
[+] [-] everettm|15 years ago|reply
[+] [-] j79|15 years ago|reply
Great article, btw! Enjoyed the read. I do agree with others- A few pictures to go along with your examples would have been really helpful!!
[+] [-] elboru|15 years ago|reply
[+] [-] everettm|15 years ago|reply
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.
[+] [-] Symmetry|15 years ago|reply
[+] [-] beaumartinez|15 years ago|reply
[+] [-] bjb39|15 years ago|reply
[+] [-] aserra69|15 years ago|reply
[+] [-] mahmud|15 years ago|reply