
Don’t design like a programmer - pankratiev
http://www.uxdesignedge.com/2010/03/dont-design-like-a-programmer/
======
kwis
"Error establishing a database connection"

Don't program like a designer?

~~~
StavrosK
I came here to say the exact same thing. Perhaps I should make less obvious
jokes.

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

~~~
d_r
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.

~~~
mahmud
That's very sensible actually, but how do you explain the free cost of
automatically generated CRUD and admin panels?

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

~~~
tomkarlo
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.

------
rohwer
This 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.

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

~~~
saraid216
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.

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

------
Ysx
Google cache:
[http://webcache.googleusercontent.com/search?q=cache:qmKT38N...](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/&cd=1&hl=en&ct=clnk&gl=uk&client=firefox-a&source=www.google.co.uk)

------
statictype
These design articles are interesting but I wish more would provide examples
of what you _should_ do instead of just what you shouldn't.

~~~
GregBuchholz
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...](http://www.codinghorror.com/blog/2006/11/this-is-what-happens-when-
you-let-developers-create-ui.html)

~~~
saraid216
Well, who's the user?

------
TorbjornLunde
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?

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

------
pspeter3
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

~~~
wladimir
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.

------
LarryA
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).

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

(And, no I didn't write that error message. :))

~~~
everettm
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.

------
elboru
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?

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

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

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

------
bjb39
Conversely, don't program like a designer: <http://i.imgur.com/zqJpM.png>

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

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

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

