There is really no mystery about UI. Yes, it requires skill and a deep knowledge of how humans process information, and even a touch of design genius.
But the real problem is that most shops can't measure usability in a fine-grained way. And yet everyone does have some idea that it's really important. Consequently they are bamboozled by anyone who purports to have such expertise.
For the most part, so-called usability experts are really just graphic design snobs. They have a certain aesthetic they like, which is arguably "cleaner" and has more white space. So the page might be better organized but that's nowhere near what true usability is.
Real usability work is about trying to understand how the user is thinking. What their mental model is. What their goals are. In what context they are trying to achieve a task. Not just how their eye is scanning for information.
Anyway my point is, when it comes to real usability work, programmers are just as (un)qualified as graphic designers, marketers, or any other kind of "product" person. Arguably the designer is supposed to have a larger toolbox when it comes to possible graphic treatments, but the programmer also has a toolbox of quantitative methods, experimentation, and a deep understanding of how the system could work.
You know, I thought I had UI design mostly figured out, using a few simple rules:
* Minimise the total number of clicks needed to access the sum of the program's functionality.
* Make frequently-used functionality easier to reach than rarely-used functionality.
* Don't have more elements in the UI than is easy to parse quickly.
* No surprises.
However, after reading this article, I get the feeling that it's a more arcane art, which not many people know. What are some simple rules about good UI design, in your opinion?
You are exactly right. Making usability and user design into a science is difficult because we'd be trying to model the human mind, which is, well, pretty much impossible.
For example, in the information retrieval community, companies like Google continue to employ a lot of people to mark search results as relevant or not. Even with all this data, it's still hard for us to quantify what is "relevant" to a user. Likewise, it is hard for us to quantify what is "usable."
But even though the programmer may own this toolbox of quantitative methods and whatnot, most of them do not use it when it comes to usability. Why? Because the toolbox is quite empty. The advantage that these "snobby" designers (just like how programmers are "snobby" about their choice of programming languages and tools) have over programmers is that designers have more empathy towards the everyday man. So there is some emotion involved. Sure, there might be a science behind all of this, but since no one figured it out yet, we'll have to go use our intuition of what a good design is.
Fortunately I think this is changing: tools are coming out that make running quantitative UX studies easier. Services like Optimizely, GazeHawk (disclaimer: that was a shameless plug for my company), UserTesting.com, etc are becoming more commonplace, bringing the barrier to entry for a UX consultant who is actually useful down.
In the future I imagine there being plenty of UX consultants who, rather than having a strong education in the psychology of websites, instead is experienced with the tools necessary to evaluate a design and make recommendations. Then there will be graphic designers, marketers, etc who are actually qualified to work with usability.
I hear a lot of "programmers don't do good Ui" as well as "marketers dictate bad UI" in my travels. I used to try to work out some sort of theory about which statement is true, and why. But then I experienced a revelation, Sturgeon's Revelation:
90% of everything is crap.
Therefore, if handed ten UIs designed by programmers, nine will be crap. If handed ten UIs designed by marketers, nine will be crap. Perhaps there is a characteristic way in which the nine programmer crap UIs are crap, but the observation that most programmer UIs are crap is not insightful and doesn't magically justify the idea of turning UI design over to product management.
That's a really good point - but I think a really big issue is that a lot of programmers (and I don't know why) seem to think that a good User Interface (API, Visual, Docs, etc) is just not needed.
That; and the attitudes range from "who cares" to downright hostile "if you can't understand it, you're stupid". I say this as a programmer (who spends a lot of time on the "user" facing components), not as a business person.
That attitude has to change - I don't care that the business people think hackers are Eloi fit for the slaughter while they are the Morlocks - the intelligent ones. Good business people don't have that attitude, good business and product people do care about scalability, supportability and quality. Those that don't will fail.
On the other hand, the constant refrain I hear from people in my own community and profession about making something usable and intuitive just makes me upset. I can't change the broken business people - I can try to make my corner of the world better.
You know Zed - this was a really good read. There's not much I can personally disagree with here, especially your final point (which I won't give away so people will read it).
Very well written; and some great advice. I much prefer this to ranty-zed :)
The Long Beards, (Latin Langobardi, later "Lombards") were a tribe of Germanic "barbarians" who settled in Northern Italy in the late 500s AD. They were primarily responsible for thwarting the Byzantine Emperor Justinian's campaign to reconquer Italy and re-establish the Western Empire.
Another word for programmers who "make products for people who make products" are systems programmers.
I'm sure Apple values systems programmers. And Google. And Oracle (at least they certainly should). Microsoft could not possibly build their products without systems programmers. Amazon could not have created its cloud products without systems programmers.
In Apple's case, their products would be impossible without the capabilities that the systems people build. Without an operating system that they could strip down and fit on a phone, while keeping much of its core functionality, no iPhone. Likewise if they didn't have the technology underlying Safari under their control.
Much of the eye candy that wowed people in Mac OS X came as a thin layer on top of the technology built by systems programmers. Like the graphics APIs underlying Expose. And the fast, system wide indexing behind Spotlight.
So, if you want to be appreciated as someone who "makes products for people who make products," work for a software company that makes products requiring innovation in systems software.
I agree with many of the things said in the article.
I'm so annoyed with people who make open source projects that don't comply to the principles that Zed listed. (Clear code, documentation, easy to get started, reasonable defaults, support, etc.) It happens so often that I interact with such OSS projects and it's so hard to work with them.
I feel bad for all the honest effort that these people put into the core parts of their OSS projects, without realizing that if they concentrated a bit more on the things that Zed mentioned, their project would become so much easier and fun to work with, and they'd have a bigger healthier community around it.
<Sociopathic rant> Sometimes when I see one of these projects, (let's call it, as an example, project FooBar and say that it converts between image formats,) I fantasize about forking the project, fixing up all the documentation to be good, make a good UI, give installers, make a nice logo, etc. Then rename it, sell it as a commercial project and become a millionaire, without crediting the authors of FooBar. Then I will drive in my fancy car to visit the core developers, and I will show them a wad of $100 notes and tell them: "You see this? This could have been yours. This could have been yours if only you documented your freaking code. You worked so hard on this code, and if you would have only taken care of the things around it, like documentation and binaries and design and UX, you could have made a lot of money. But you didn't. You suck." Then maybe for their next project they'll write freaking documetation. </Sociopathic rant>
Except the implicit intellectual theft. What you are describing is pretty close to the music industry's original purpose - bridging the gap between creators and buyers - and see how often that gets criticised (perhaps rightfully now) as vampiric.
"let's say you can pull this off and you have permission to really make the UI sexy. Alright, where's your designer? In every mega-corp and government agency I've worked for there has never been a staff designer of any kind."
Amen to that. I'm working on a project to boost a new product line for my megacorp that competes against the established leader. So I asked to really boost the UI. And it was approved, provided of course, I made it myself :( . All my pleas for a designer were unheard or shrugged off.
With some help from the Internet, I've come up with a design that doesn't suck, but it's still a far cry from what a designer would have done in a tenth of the time (in effect, they hired me as a crappy designer and spent far too much of my time aka their money, but they don't see it that way)
Excellent read. I found myself relating this to the division between hacker types and the MBA types. I think the comparison is close as sometimes the product people are the MBA people.
As a hacker, I enjoy having large blocks of time to create what I think is good and not coding some autocratic vision of a product. As I've grown older though, I have come to appreciate and value the interaction between MBA types and myself. In one particular project an MBA type brought me valuable information about what we were doing well, how we compared against competitors, and what he thought our customers wanted. He then told me to run with it and stepped out of the way. I thought that was pretty neat.
Another thought - A quote from the article:
"A sudden rise in Long Beards simply copying Product People Products but doing it cheaper using their cost reducing backend skills."
reminded of the Paul Graham essay "Copy What You Like"
I end up with things like "arrive at site", "create objectX", "view & edit objectY" as the next level nodes and keep going down levels from there. Since a mind map is a tree structure, it really helps to visually map out decisions a user will make. Following a branch is the user making a decision of what to spend their limited attention on. If you are improperly the distributing number of decisions a user must juggle at a particular node or repeating a lot of functionality in different areas, you will instantly visually see it.
Then when you start translating to code, if it's M-V-C architecture like most webapps, the first order nodes are the names of your controller functions.
Just one point on Cooper and the Inmates book... it was written 11 years ago. Cooper being a vaguely smart guy has learned stuff since then and has quite a different view on the way development and ux folk fit together now.
There's a large chunk of the UX community that's moving away from the developers-as-enemy attitude. And vice versa for the developer community I hope :-)
In my opinion usability requires a lot of grunt work. You have to craft error messages for any and all user input. You have to degrade gracefully if the user's interface (no JS, IE6, small screen on a phone, etc) doesn't meet the ideals for which you've designed the interface. Usable is much more work than functional.
Most programmers are aware of that, and are willing to put the time and effort in to making what's required. But often the product people, besides deciding what things should look like overall, are also in control of the budget and schedule, and they expect all those kinds of things to just magically appear.
Couldn't agree more about how a poorly designed backend can increase costs, however pretty and well-designed the frontend is.
We have a situation at work just like this: the inherited backend code is dreadful, full of WTFs due to poor implementation, lack of knowledge and lack of planning and design. It's eating away our profit margins. New features and customization take far longer than they should, and time estimates are impossible. Bugs, from simple UI stuff to server issues, are numerous and end up adding to customer support costs, not to mention reputation.
Do the management understand this ? Nope, they just consider these costs to be the normal cost of doing business in this sector. We have pleaded time and again to rewrite and refactor the code, but never given the time or leeway because the sales team want the latest shiny feature to sell to the client.
The irony is that we have a healthy and growing user base and top-rank clients. An outside competitor (of which the developers are aware, but about which the management are oblivious) are about to eat our lunch because they can simply execute better and faster.
I don't know - they probably do, god knows it allows me to make something that doesn't look like a series of cat turds, but formulaic designs don't last long term. You need something which really differentiates you from the pack.
It's very refreshing to see someone write about their ideas and at the same time, demonstrate them with a real product. It's more than most people do when they proclaim things like what he has in his essay. Zed is someone worth listening to.
Steve Jobs on design: "It's not just what it looks like and feels like. Design is how it works"
This applies just as much to infrastructure as it does to anything customer-facing. To a non-programmer, for example, sendmail, nginx, and mongrel2 may all look like user-hostile crap. To a developer or administrator, it's easier to discern the differences in the design of this part, which is itself a major part of the usability of a webserver.
I have been a "product person" for 15 years and I believe that product people like Michael describes are bad product people. A good product manager knows the UI and the guts behind it. I am not an engineer by training but I wouldn't be a good product manager in this field if I didn't know how to build a web server either.
For the "Jeep Cherokee made from iron ore": I give up. ;-)
I'm almost certain when he says he can "make a web server", he means that he can sit down with a text editor, a compiler, and a standard C library, and produce a program that will serve HTTP requests. There's some gray area beyond this, but he definitely does not mean that he can download, configure, and run a premade piece of software.
Is this what you mean too? Is there really a population of self-described "product people" who have this knowledge? Or did you interpret his statement differently? I certainly agree that such people exist, but I would be surprised that their luxurious gray beards don't blow their cover. Which is to say, do they really work as product managers?
Agreed. The best product people are those who can understand the back end--even if they couldn't code it themselves, they have a respect and basic understanding for what's going on.
The comments here are very UI-centric, but what I found interesting was first the reminder to invest in fad-resistant skills (and don't forget, he drew a distinction between UI and hardcore design skills!).
And second the stuff about parsers in the section about making usable infrastructure software. Every time I peek at the mongrel2 source, there's one or two more Ragel files in there, some of them generating token streams to be consumed by a Lemon parser. I figured there was a good reason for that (although I shot a quizzical glance at the one that just parses "--a --b b" CLI args into key/value pairs). What I didn't realize was how much that's an integral tenet of his software design philosophy.
You know there are entire disciplines dedicated to the study of usability and user experience. Zed seems shocked that someone would claim that programmers (who generally have no training or interest usability) aren't good at making usable products. It's about as controversial as saying that construction workers don't make good architects.
English is written for people and not machines. Code needs to be written for both. It's too bad that coders often forget that someone is going to need to be able to read it later.
[+] [-] neilk|15 years ago|reply
But the real problem is that most shops can't measure usability in a fine-grained way. And yet everyone does have some idea that it's really important. Consequently they are bamboozled by anyone who purports to have such expertise.
For the most part, so-called usability experts are really just graphic design snobs. They have a certain aesthetic they like, which is arguably "cleaner" and has more white space. So the page might be better organized but that's nowhere near what true usability is.
Real usability work is about trying to understand how the user is thinking. What their mental model is. What their goals are. In what context they are trying to achieve a task. Not just how their eye is scanning for information.
Anyway my point is, when it comes to real usability work, programmers are just as (un)qualified as graphic designers, marketers, or any other kind of "product" person. Arguably the designer is supposed to have a larger toolbox when it comes to possible graphic treatments, but the programmer also has a toolbox of quantitative methods, experimentation, and a deep understanding of how the system could work.
[+] [-] StavrosK|15 years ago|reply
* Minimise the total number of clicks needed to access the sum of the program's functionality.
* Make frequently-used functionality easier to reach than rarely-used functionality.
* Don't have more elements in the UI than is easy to parse quickly.
* No surprises.
However, after reading this article, I get the feeling that it's a more arcane art, which not many people know. What are some simple rules about good UI design, in your opinion?
[+] [-] elbenshira|15 years ago|reply
For example, in the information retrieval community, companies like Google continue to employ a lot of people to mark search results as relevant or not. Even with all this data, it's still hard for us to quantify what is "relevant" to a user. Likewise, it is hard for us to quantify what is "usable."
But even though the programmer may own this toolbox of quantitative methods and whatnot, most of them do not use it when it comes to usability. Why? Because the toolbox is quite empty. The advantage that these "snobby" designers (just like how programmers are "snobby" about their choice of programming languages and tools) have over programmers is that designers have more empathy towards the everyday man. So there is some emotion involved. Sure, there might be a science behind all of this, but since no one figured it out yet, we'll have to go use our intuition of what a good design is.
[+] [-] bkrausz|15 years ago|reply
In the future I imagine there being plenty of UX consultants who, rather than having a strong education in the psychology of websites, instead is experienced with the tools necessary to evaluate a design and make recommendations. Then there will be graphic designers, marketers, etc who are actually qualified to work with usability.
[+] [-] jeffclark|15 years ago|reply
UX designer = "mental space"
[+] [-] raganwald|15 years ago|reply
90% of everything is crap.
Therefore, if handed ten UIs designed by programmers, nine will be crap. If handed ten UIs designed by marketers, nine will be crap. Perhaps there is a characteristic way in which the nine programmer crap UIs are crap, but the observation that most programmer UIs are crap is not insightful and doesn't magically justify the idea of turning UI design over to product management.
[+] [-] jnoller|15 years ago|reply
That; and the attitudes range from "who cares" to downright hostile "if you can't understand it, you're stupid". I say this as a programmer (who spends a lot of time on the "user" facing components), not as a business person.
That attitude has to change - I don't care that the business people think hackers are Eloi fit for the slaughter while they are the Morlocks - the intelligent ones. Good business people don't have that attitude, good business and product people do care about scalability, supportability and quality. Those that don't will fail.
On the other hand, the constant refrain I hear from people in my own community and profession about making something usable and intuitive just makes me upset. I can't change the broken business people - I can try to make my corner of the world better.
[+] [-] jnoller|15 years ago|reply
Very well written; and some great advice. I much prefer this to ranty-zed :)
[+] [-] gte910h|15 years ago|reply
[+] [-] mnemonicsloth|15 years ago|reply
The Long Beards, (Latin Langobardi, later "Lombards") were a tribe of Germanic "barbarians" who settled in Northern Italy in the late 500s AD. They were primarily responsible for thwarting the Byzantine Emperor Justinian's campaign to reconquer Italy and re-establish the Western Empire.
http://historyofscience.com/G2I/timeline/images/alboin.jpg
Today Lombardy is the most populous of Italy's 20 regions and Milan, the capital, is Italy's leading financial center.
[+] [-] zeemonkee|15 years ago|reply
[+] [-] jimbokun|15 years ago|reply
I'm sure Apple values systems programmers. And Google. And Oracle (at least they certainly should). Microsoft could not possibly build their products without systems programmers. Amazon could not have created its cloud products without systems programmers.
In Apple's case, their products would be impossible without the capabilities that the systems people build. Without an operating system that they could strip down and fit on a phone, while keeping much of its core functionality, no iPhone. Likewise if they didn't have the technology underlying Safari under their control.
Much of the eye candy that wowed people in Mac OS X came as a thin layer on top of the technology built by systems programmers. Like the graphics APIs underlying Expose. And the fast, system wide indexing behind Spotlight.
So, if you want to be appreciated as someone who "makes products for people who make products," work for a software company that makes products requiring innovation in systems software.
[+] [-] cool-RR|15 years ago|reply
I'm so annoyed with people who make open source projects that don't comply to the principles that Zed listed. (Clear code, documentation, easy to get started, reasonable defaults, support, etc.) It happens so often that I interact with such OSS projects and it's so hard to work with them.
I feel bad for all the honest effort that these people put into the core parts of their OSS projects, without realizing that if they concentrated a bit more on the things that Zed mentioned, their project would become so much easier and fun to work with, and they'd have a bigger healthier community around it.
<Sociopathic rant> Sometimes when I see one of these projects, (let's call it, as an example, project FooBar and say that it converts between image formats,) I fantasize about forking the project, fixing up all the documentation to be good, make a good UI, give installers, make a nice logo, etc. Then rename it, sell it as a commercial project and become a millionaire, without crediting the authors of FooBar. Then I will drive in my fancy car to visit the core developers, and I will show them a wad of $100 notes and tell them: "You see this? This could have been yours. This could have been yours if only you documented your freaking code. You worked so hard on this code, and if you would have only taken care of the things around it, like documentation and binaries and design and UX, you could have made a lot of money. But you didn't. You suck." Then maybe for their next project they'll write freaking documetation. </Sociopathic rant>
[+] [-] forensic|15 years ago|reply
[+] [-] nopassrecover|15 years ago|reply
[+] [-] GFischer|15 years ago|reply
Amen to that. I'm working on a project to boost a new product line for my megacorp that competes against the established leader. So I asked to really boost the UI. And it was approved, provided of course, I made it myself :( . All my pleas for a designer were unheard or shrugged off.
With some help from the Internet, I've come up with a design that doesn't suck, but it's still a far cry from what a designer would have done in a tenth of the time (in effect, they hired me as a crappy designer and spent far too much of my time aka their money, but they don't see it that way)
[+] [-] andjones|15 years ago|reply
As a hacker, I enjoy having large blocks of time to create what I think is good and not coding some autocratic vision of a product. As I've grown older though, I have come to appreciate and value the interaction between MBA types and myself. In one particular project an MBA type brought me valuable information about what we were doing well, how we compared against competitors, and what he thought our customers wanted. He then told me to run with it and stepped out of the way. I thought that was pretty neat.
Another thought - A quote from the article:
"A sudden rise in Long Beards simply copying Product People Products but doing it cheaper using their cost reducing backend skills."
reminded of the Paul Graham essay "Copy What You Like"
http://paulgraham.com/copy.html
... and copying something you like is probably a good way to bridge the gap between back end "long beard" and product designer.
[+] [-] jimbokun|15 years ago|reply
One of the founding principles of Y Combinator is to make the Hackers the product people.
[+] [-] metamemetics|15 years ago|reply
I end up with things like "arrive at site", "create objectX", "view & edit objectY" as the next level nodes and keep going down levels from there. Since a mind map is a tree structure, it really helps to visually map out decisions a user will make. Following a branch is the user making a decision of what to spend their limited attention on. If you are improperly the distributing number of decisions a user must juggle at a particular node or repeating a lot of functionality in different areas, you will instantly visually see it.
Then when you start translating to code, if it's M-V-C architecture like most webapps, the first order nodes are the names of your controller functions.
What methodologies do other people use?
[+] [-] adrianhoward|15 years ago|reply
Folks interested in a look into his more current thinking might want to take a look at his keynote for Agile 2008 http://www.cooper.com/journal/2008/08/alans_keynote_at_agile..., and his keynote at Interaction 08 http://interaction08.ixda.org/Alan_Cooper.php.
And from his involvement in things like the http://www.andersramsay.com/2010/02/04/notes-from-the-agile-... things are moving on from there too.
There's a large chunk of the UX community that's moving away from the developers-as-enemy attitude. And vice versa for the developer community I hope :-)
[+] [-] ojbyrne|15 years ago|reply
Most programmers are aware of that, and are willing to put the time and effort in to making what's required. But often the product people, besides deciding what things should look like overall, are also in control of the budget and schedule, and they expect all those kinds of things to just magically appear.
[+] [-] zeemonkee|15 years ago|reply
We have a situation at work just like this: the inherited backend code is dreadful, full of WTFs due to poor implementation, lack of knowledge and lack of planning and design. It's eating away our profit margins. New features and customization take far longer than they should, and time estimates are impossible. Bugs, from simple UI stuff to server issues, are numerous and end up adding to customer support costs, not to mention reputation.
Do the management understand this ? Nope, they just consider these costs to be the normal cost of doing business in this sector. We have pleaded time and again to rewrite and refactor the code, but never given the time or leeway because the sales team want the latest shiny feature to sell to the client.
The irony is that we have a healthy and growing user base and top-rank clients. An outside competitor (of which the developers are aware, but about which the management are oblivious) are about to eat our lunch because they can simply execute better and faster.
[+] [-] gte910h|15 years ago|reply
[+] [-] jnoller|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] ryan-allen|15 years ago|reply
[+] [-] Poiesis|15 years ago|reply
This applies just as much to infrastructure as it does to anything customer-facing. To a non-programmer, for example, sendmail, nginx, and mongrel2 may all look like user-hostile crap. To a developer or administrator, it's easier to discern the differences in the design of this part, which is itself a major part of the usability of a webserver.
[+] [-] danielnicollet|15 years ago|reply
[+] [-] nkurz|15 years ago|reply
I'm almost certain when he says he can "make a web server", he means that he can sit down with a text editor, a compiler, and a standard C library, and produce a program that will serve HTTP requests. There's some gray area beyond this, but he definitely does not mean that he can download, configure, and run a premade piece of software.
Is this what you mean too? Is there really a population of self-described "product people" who have this knowledge? Or did you interpret his statement differently? I certainly agree that such people exist, but I would be surprised that their luxurious gray beards don't blow their cover. Which is to say, do they really work as product managers?
[+] [-] TWAndrews|15 years ago|reply
[+] [-] shoover|15 years ago|reply
And second the stuff about parsers in the section about making usable infrastructure software. Every time I peek at the mongrel2 source, there's one or two more Ragel files in there, some of them generating token streams to be consumed by a Lemon parser. I figured there was a good reason for that (although I shot a quizzical glance at the one that just parses "--a --b b" CLI args into key/value pairs). What I didn't realize was how much that's an integral tenet of his software design philosophy.
[+] [-] Bdennyw|15 years ago|reply
[+] [-] greenlblue|15 years ago|reply
[+] [-] billswift|15 years ago|reply