
UI editing is a professional job - jgrahamc
http://blog.jgc.org/2010/06/ui-editing-is-professional-job.html
======
chime
My take on X is a professional job is this: it depends. If you have 20
developers in your team, one or two better be good at UX, one or two better be
good at low-level coding, one or two better be good at SEO and so on. If you
only have two developers, they better be good at the core product and be
mindful of everything else. The third developer is never going to be a tester,
QA, or UX if your first two developers can't keep up with the core.

In a large pharmaceutical company with 10,000 employees, you have people with
job titles like "Quality Assurance Lead II (Wound Management)". In a startup
with 3 people, people call themselves CEO, CTO, and CFO. As the startup grows,
it will need people. Eventually you'll hire a "QA Lead II" or "UI Editor (Web-
Apps Division)". The main question is who do you hire next? Do you need a
graphic designer more than a helpdesk person? Do you need a project manager
more than an AP assistant?

~~~
bluishgreen
What I took away from the post is this. There is a certain quality metric that
one needs to be aware of to do a good job at X. Programmers all do Sysadmin
work from time to time. And founders always double as Sysadmins. But just
because its not your primary role doesnt mean you can leave random ports open
and do a really bad sysadmin job.

The same is true of UX design. But the problem is while the distance from
programmer to sysadmin seems to be a short walk, the distance from programmer
to UI/UX from my experience is a long one.

Sure, we cannot/should not afford another guy with a title, but Graham is
pointing out a valid blindspot for all of us and it should be taken into
account when making decisions.

------
tomjen3
With one important caveat (which people never seem to post) this only applies
if you make software people use to do a few similar things.

Your development environments, your film editing software, your database
software, your programming languages, your unix shells, etc should under no
circumstances be intuitive, because that also means they can never be powerful
which is more important.

~~~
Qz
I call bullshit on the idea that intuitive software can't be powerful.

~~~
decode
You're right to some extent, but there is definitely a tension between the two
things. This is true with all tools. If a tool enables doing something very
complicated, it is almost always hard for beginners to use.

Think of musical instruments. A kazoo is beginner-friendly, but you can only
make fairly simple sounds with it. On the other hand, a piano keyboard is
barely usable at all to a beginner, but is incredibly powerful in the hands of
an expert.

~~~
Qz
You can do very complex things with a hammer, but learning how to use a hammer
is very simple. The key is that a hammer does exactly the same things as it
has always done, and the nails don't get fussy if your hammer doesn't have the
latest driver update.

~~~
decode
I'm not sure you can do very complex things with a hammer. You can really only
hit things and pry things. Those are very simple tasks.

Of course, combining those simple tasks in complex ways will give you complex
results. But then you've moved all of the complexity out of the tool and into
your head, and beginners cannot do these things.

To go back to my instrument analogy, you can play a 2-hour song with 10,000
notes on a kazoo. But, you're only playing one note at a time. On a piano, you
can play many notes at once, playing some simultaneously and others with
partial overlaps, changing the sustain and timbre of the notes as you go. The
kazoo, while it creates a song that is a complicated whole, does not perform
tasks as complicated as the piano. This is what I'm getting at with my
statement about software interfaces.

~~~
Qz
I don't want to get too off track on analogies, but on a piano you only play
one note at a time. A piano is just a set of kazoos that match octaves, set in
a row, and you press a key instead of blowing into the kazoo. But the
interface for the piano is dead simple -- every key can be pressed the same
way, and there's levers at the bottom which I never really understood :).

So yes, the complication of a piano comes from what you can do with the
multiple simple interfaces, not from the complexity of the interface -- see
where I'm going?

On a computer however, there's complexity in whatever the task is, and that's
inherent. You can't fight that. But you can fight the complexity in the
interface itself.

There's been plenty of articles on HN about interface inconsistencies. The
windows 'system tray' is particularly notorious, where basically every single
icon does entirely different things depending on whether you left click, right
click, middle click, double click, etc. Imagine a piano, where the notes hit
by the keys are in a random order on every piano. And it's not a windows only
problem -- interfaces are consistently inconsistent on every platform.

------
ojbyrne
There's a great cartoon in "Don't Make Me Think" that captures what is
essentially the committee approach to UI/UX. Its a great book, and basically
makes the same argument.

