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?
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.
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.
Your point is quite valid; I've seen people do magic with video editing software and CAD packages that I'm sure wouldn't be possible with a more fisher-price interface. But basic actions should be intuitive for someone who is familiar with computers. Higher end video manipulation products are the worst offenders I've seen, with custom GUI toolkits and weird idioms. No native GUI widget like menus or toolbars in sight; it turns basic functionality like opening a file, or closing the program, into an exercise in frustration. Even vim and emacs have happy GUI wrappers these days that make those operations accessible.
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.
I don't think your analogy holds. In fact, the piano has an incredibly intuitive interface. Push buttons farther to the right, and they get higher in pitch. Push buttons farther to the left, and they get lower in pitch. I would argue that the playing of music itself is unintuitive, which is why a beginner would not know what to do with a piano.
I do agree that making the ui for complex tools easy to use is very difficult, but I wouldn't label complexity and ease of use a trade off. There are an infinite number of ways to display a user interface, and I believe there's always a way to make something easier to use.
I prefer not to use the word "intuitive" exactly because it has no definition and leads to such miscommunications. You're saying the layout of a piano keyboard is arranged by a system that is easy for beginners to understand. I'm saying it's not easy for beginners to use. These are two very different things and the piano is an interesting example of how one does not necessarily imply the other.
"the playing of music itself is unintuitive"
Most of the children I have met are able to use their voices and percussive instruments to play music. I don't think producing some form of live music is inherently difficult.
If one looks at the interfaces that really are intuitive, one often finds that the bandwidth -- amount of data presented to the user -- is limited. Creating contexts that are limited to a particular specific task is very powerful and helps avoid confusion.
If a task is complex, it takes a good amount of insight to be able to divide it into such specific contexts without unduly getting in the way of the user.
I think the issue is that bandwidth of data presented to the user at a single time is limited in intuitive interfaces, but if you organize the interface (or allow it to self-organize) properly, you can present high bandwidth data over time in chunks of low bandwidth intuitive interfaces.
Real life, despite being mind-numbingly complex in its entirety, can be easily interacted with because we break it down into a number of simple intuitive interfaces and then switch in and out of which interfaces we're focusing on very rapidly. If we can emulate the same thing with software, then learning to use computers will be no harder to do than learning to use anything else in life.
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.
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.
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.
How so? What are you learning how to do with the hammer? Pry up nails? Hammer nails?
What thickness of nail should you use to go through a given board? How should the way you hold the nail differ depending on size of nail, size of board, working area?
A hammer is not at all simple; it takes just as long to get the hang of than your average desktop app, if not longer.
I don't think your analogy holds. In fact, the piano has an incredibly intuitive interface. Push buttons farther to the right, and they get higher in pitch. Push buttons farther to the left, and they get lower in pitch. I would argue that the playing of music itself is unintuitive, which is why a beginner would not know what to do with a piano.
I do agree that making the ui for complex tools easy to use is very difficult, but I wouldn't label complexity and ease of use a trade off. There are an infinite number of ways to display a user interface, and I believe there's always a way to make something easier to use.
Okay, I challenge you to find me one that has both.
The only exception I can think of right now (3D Studio Max) essentially has too different modes: a normal mode where you have to use your mouse to select everything (which takes a really, really long time) and an expert mode without any buttons at all (which is by no means intuitive).
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.
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?