Don’t design like a programmer(uxdesignedge.com) |
Don’t design like a programmer(uxdesignedge.com) |
Don't program like a designer?
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.
(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.
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 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.
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.
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.
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.
[1] http://www.codinghorror.com/blog/2006/11/this-is-what-happen...
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?
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.
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).
(And, no I didn't write that error message. :))
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!!
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.
