

Why Johnny can’t build a decent user interface - cwan
http://jeffreyellis.org/blog/?p=8897

======
SoftwareMaven
I completely disagree with the assertion that interface design is an "inborn"
trait. Most people suck at it because they have not spent the time learning
how to design a good interface (the whole 10,000 hours thing), usually because
it isn't a priority or interest for them.

~~~
scott_s
I agree, but I have found that many people here hold the complimentary view:
that programming ability is an inborn trait.

~~~
Terretta
> _hold the view... that programming ability is an inborn trait_

I recently wrote someone a recommendation where I argued that programming
languages and patterns are readily teachable, but holding a complex model in
the mind and communicating it effectively to peers, laymen, or computers (the
computer is the ultimate simpleton) is less easily taught.

~~~
scott_s
I agree, but what you're saying is that teaching _teaching_ is hard. And I
think it is, for reasons I brought up here:
<http://news.ycombinator.com/item?id=2360570>

~~~
Terretta
Heh, I suppose I was being too polite. I'm not sure holding that mental model
in the head _can_ be taught. I think it's a key driver of excellence in
innovation and insight across a variety of industries, not just software
development, and whether nature or nurture, seems to be formed very early--
through avid reading or story telling, perhaps?

I agree with your linked comment about teaching. One university teacher told
me that to lead someone to your point of view, you must first put your arm
around them making you start the discussion from where you can see theirs.

------
tseabrooks
I think the original intention of "Why Johnny Can't ___" provide some items
the environment around him is doing wrong and some action items on what those
in a position the change the environment and action items for Johnny. This
article, OTOH, offers only criticisms of Johnny with no real action items for
how we (all of us are Johnny in something) can correct some of this abhorrent
behavior. I for one would like more advice from the designers (UI / UX)at HN
covering how I, as a low level software dev, can start improving my design
abilities. I don't want to replace a designer but I want to get better at
explaining my needs to a designer and maybe be able to help come up with the
look and feel of my 'vision'.

~~~
TheThinker
Sorry, I thought I did provide some advice, not just criticism - specifically
the last 6 paragraphs of my post.

~~~
jonmc12
I dunno.. your article only has 2 links - 1) 'Websites that suck', 2) your own
article about how 'incompetent individuals tend to overestimate their
abilities'.

The last 6 paragraphs are fairly obvious points where you do not go into
detail or give examples. How is the reader supposed to know what you mean in a
way that is useful? Some links to examples or how to implement would be useful
advice.

Also, I'm curious, why the snarkiness? Do you consider being critical of
others to be part of your online persona? Is it for entertainment value? Is it
an effort to improve something? I don't mean to pick on you - I'm actually
curious.

~~~
TheThinker
I was honestly not trying to be snarky. Can you point out where I was?
Seriously, I'm not trying to get defensive here - it would help me if you
could point it out.

~~~
jonmc12
Perhaps snarky was not the right word - the article contains little/no
sarcasm. I think myself and others are reacting to the general feeling of a
largely negative criticism without any focus on good design done by engineers
(or anyone).

Words like 'mad skillz' imply condescension towards some hypothetical group of
developers. Words like 'self-serving', 'lack of', 'incompetence', etc are just
negative - again targeting a straw-man group of developers.

Within your article there seems to be a paradigm of a) stuff that 'sucks', and
b) the 'right' way (your way).

So, it leaves me thinking that you are targeting a negative generalization
towards a group of developers. Effectively, you created an ad hominem argument
against a straw-man. This comes off as negative, but more so it tells me as a
reader that you spent energy evaluating the scenario from the standpoint of
'this is wrong', without fully understanding the point of view of your straw-
man or pointing to examples of good design.

Instead of conveying 'these guys over here suck, they should do it my way' you
could have conveyed 'these guys over here can suck, but when I have observed
them doing x, y, z they definitely suck less' - same message without the ad
hominem. Or, even better 'these guys over here are good at design vs average
engineers because they do x, y, z' - same message with an emphasis on positive
examples, not negative examples. That would convey that you have taken the
energy to evaluate both the negative and the positive about the straw-man
developer group you appear to be attacking.

As a general aside, I have been trying to understand why many smart / skilled
people bias towards viewing others in a negative light - ie, does it have a
benefit? I am generally interested to understand where this negatively comes
from when skilled people evaluate their peers.

~~~
TheThinker
Thanks for the feedback. Negative criticism, I was certainly engaging in. I'm
not sure that I'm attacking a "straw-man group of developers," though -- I
certainly never meant to convey, for example, that all developers are bad at
user interface design -- but I did say "most" so perhaps I was painting with
too broad a brush. And agreed that I could have provided concrete examples --
perhaps a future post.

------
dkarl
He forgot two reasons interfaces go wrong:

1\. Giving users what they ask for; and

2\. Designing to sell.

~~~
reneherse
Number two is an insight i hadn't considered, so thanks for sharing.

Isn't one of the things that generally makes Apple's products arguably great
is that the hardware is designed to be true to its purpose, and the marketing
campaign is an entirely separate and often equally brilliant thing, also true
to its purpose...

~~~
JoeAltmaier
Designing to sell - that reminds me of the last laptop I purchased. It had
every gizmo turned on, endless vendor crap installed, booted up like a dog and
ran worse.

There was definitely zero interest in making my experience a good one.
Somebody marketing committee had gotten ahold of the product and this was the
result.

1st thing I did: wipe it and reload the OS. With OS media I had to buy
separately.

------
spanktheuser
As a designer and sometime front-end developer, I find that writing code can
be at odds with taking a user-centric point of view. I've often been tempted
to re-use a view simply because I didn't want to maintain two different
versions that were almost the same... surely the user wouldn't notice a
difference. I also am less likely to start over when I have a better UI idea
if I've already committed the first approach to git.

~~~
sreitshamer
Programming isn't a code-production activity. It's a knowledge-acquisition
activity. It was worth writing that code to learn about the approach you were
thinking of. It's also worth throwing it out once you see that there's a
better UI idea.

------
nonrecursive
I also disagree with his “inherent ability” argument. I think that interface
design is a learnable skill and can be improved through practice. Which of us
is right? We’ll never know, as it’s not really a testable assertion.

In my opinion, that makes it a pretty weak argument that detracts from the
rest of his article. Besides that, it could have the effect of discouraging
people from trying, as they’ll just think “Oh well I can never do that because
I don’t have the genes, or whatever.”

My opinion is that programmers in particular have a hard time with design
because they’re not presented with a systematic way of thinking about it.
That’s what I’ve started to try to do with my site <http://www.visualmess.com>
. It tries to instill the “user-centric” mentality and provide a framework for
thinking about design based on the brain’s visual information processing
capabilities.

------
mechanical_fish
The central problem is lack of incentives, or misaligned incentives. It has
relatively little to do with the character of the developers. Developers are
generally not stupid. Many of them could learn to be better designers, and
they could certainly learn to _consult_ with better designers. But why should
they?

If software is sold based on a checklist of features then it is more important
to build ten ugly features than one beautiful one. If software is sold based
on beautiful demos then it pays to make the demo awesome but skimp on the
corner cases. If software is sold based on gorgeous screenshots and icons then
the median icon or screenshot will be gorgeous, even if the app itself is
missing or broken. (Even the broken iOS apps have beautiful, beautiful icons.)

If your company has so many layers of management that the feedback from end
users never makes it back to your desk, you'll generate designs that please
your management.

If you're at a bootstrapped startup, searching for product-market fit, it pays
to design incrementally. Even if incremental design is the wrong approach for
the problem, it still pays to design incrementally, because a better-designed
app with no market is a disaster. That means that there are many theoretically
possible designs that are difficult or impossible to achieve in practice.

The trick to improving the design of software is to figure out how to make it
pay. A major enemy is the rate at which the landscape changes. Computing still
changes so quickly that there's a premium on disposablility. The jury-rigged
contraption built of metaphorical duct tape may be barely usable, but it's
cheap and quick to build, and in a year nobody will care: They'll have traded
it in for the next model, or the platform will be obsolete and everyone will
have to move, or _you_ will switch jobs (perhaps by selling the product to
Cisco) and you won't care anymore.

------
mikhaill
This is a great post to get people thinking about the amount of time and
effort that's required to build a great user interface and work flow
scenarios.

It took me a long time to appreciate the difference a great interface makes
for an application. For me the problem comes from the original team that start
building out product. They are working on sweat equity, don't have a $1 to
spare and are rushing to market. If they don't have a designer among them, the
design and usability gets moved to 'When get some traction, we'll redo this'
and it never gets re-done and more items are piled on top of the quickly made
UI. By the time the product ships the UI is almost unusable.

------
teyc
Back in the days of text mode applications, we do not complain about user
interface design. Either it is seen as a lesser problem, or text mode itself
is better for presenting user interfaces.

I'd argue that the latter is true.

Firstly, in text mode, screen estate is limited. One has to be careful in what
one chooses to display on the main menus.

Secondly, we already program in text mode. Creating text mode menus poses less
cognitive dissonance for the programmer than dragging and dropping radio
buttons and menu bars.

The bad user interfaces that I've seen usually present all available options
within the main screen, and it ends up being a crapfest of controls with no
obvious guidance to the poor user as to what is a sensible next step.

Text menus also present a very structured way for users to explore a program.
If you made a mistake, you have a better chance of retracing your steps. In
contrast, WIMP systems may present multiple entry points for a single
functionality, with little information on how to undo one's changes. Toolbars
are the worst in this respect. The button that one clicks to "perform" the
action is not the same button one might use to "undo" the action.

------
prpon
How about iterating based on what the users are actually doing on the UI (or
website?). PG said in one of his articles _if you don't know how to design,
keep it really simple_. That's probably a starting point. As a developer
learning to design I find myself thinking in terms of data rather than user
experience.

------
Florin_Andrei
Well, if Johnny is very good at algorithms, then the stereotype says Johnny is
not very good at interacting with people and, in general, not good at figuring
out what's going on in other people's heads.

I might be biased, but I always held this as axiomatic truth.

------
hasenj
The link to the worse web sites includes:

> <http://art.yale.edu/>

Oh how very, very ironic.

The Yale school of Art.

Looks more like the toddlers school of scribbling.

------
rayboyd
I don't think some people are aware an entire discipline exists within
Software Engineering called HCI [1]. Is the distinction made between graphic
design and ui design? I'm not so sure. But this article stinks of ignorance as
to what UI design really is.

[1] <http://en.wikipedia.org/wiki/Human-computer_interaction>

~~~
TheThinker
Did my sentence "...and most software engineers don’t understand the value of
true human factors engineering — in particular the cognitive psychology and
human-computer interaction expertise that human factors engineers bring to
user interface design" not show that I am aware of HCI?

~~~
rayboyd
Most software engineers do not need a deep understanding of Human Factors as a
working tool, it is a broad term covering multiple disciplines and mediums -
particularly focused on physical forms. HCI is focused on computer
interaction; you are discussing user interface design.

