
Products For People Who Make Products For People - michaelfairley
http://sheddingbikes.com/posts/1285436217.html
======
neilk
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.

~~~
StavrosK
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?

~~~
neilk
In my opinion it isn't arcane, at least, no more arcane than other "soft"
design fields. But the simple rules are complicated to follow.

Your first three principles are about efficiency. That's a big part of
usability. When you reduce clutter, you make it easier to use by clarifying
the next action the user should take.

But "No surprises" is rather complex. It means that you not only have to
explain what you are doing, but also work with the user's mental model, which
might be totally wrong.

Here's an example from my current project. We are designing a web form to
upload images and video to Wikipedia. In 2010, the users' model of media
uploads comes from Facebook, ImageBucket, and maybe Flickr. Even after you
make them click on a box that says they give up their own rights before
proceeding, they don't understand what they did. Apparently people's mental
model just continues on blithely until it smacks against a major
contradiction.

So we've tried various metaphors. "License your work" was replaced by "Release
rights", and the next iteration is going to be " _Donate_ your work". That
wording was the suggestion of a usability testing and analysis firm we hired,
by the way. So it does take a certain amount of inspiration to come up with
alternatives, but recognizing where the problem areas are is just a matter of
measurement.

Inspiration is aided by just having a bigger bag of tricks, too -- knowing
common problems and solutions. For instance, if there is so much to do on one
page that users are finding it overwhelming, it is helpful to break it into
multiple steps (a "wizard"). That's another approach we have taken.

Anyway, I'm not sure if my expertise with usability is so deep that I could
pronounce just a few principles. Maybe "reduce cognitive load to the minimum"
is one, which has been more memorably distilled by Steve Krug as "Don't Make
Me Think". Since we want to avoid onerous information transfer and cognition,
there are some models of communication that might be helpful here; a classic
text on human communication is The Responsive Chord, by Tony Schwartz. He
argued that most communication is about activating stuff you already know (at
the right moment), which you can see at play in the example I gave.

But ultimately it's about motivating human behavior, so it's only about as
complex as the human heart. ;)

~~~
StavrosK
Thank you, that's very interesting. You can't get everything right the first
time, but yes, it doesn't seem to be something magical that you don't have any
control over (other than praying to some UX god), either.

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

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

~~~
raganwald
Interesting that you compare "a lot of programmers" to "good business people."
It is no surprise that the programmers fare poorly in comparison. What do you
have to say about Good Programmers? Or A Lot of Business People?

May I attempt to find common ground between our points of view by suggesting
that 90% of programmers have this attitude? And that by the same token, 90% of
business people are busy demanding flash web site intros and banners that
SCREAM without doing the A/B testing or other quantified analysis to know
whether they are generating higher conversions?

But your last statement is absolutely spot on: making what we do better is
what matters most. Upmod gladly given.

~~~
jnoller
Well, the larger HN community seemed to not take kindly to my comment, which
seems odd in and of itself.

Regardless, I concur with you - I can't speak to business people directly as
it's not my particular domain, but yes - I've seen the same behavior that you
have.

------
jnoller
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 :)

~~~
gte910h
I was thinking the same thing, "Well reasoned with 75% less hyperbolic rant".
Good stuff Zed, keep it up.

------
mnemonicsloth
Colophon:

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
That's interesting; I didn't know the origin of "Lombard". Justinian's attempt
to conquer Italy was one of the bloodiest periods of European history.

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

------
cool-RR
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>

~~~
forensic
Sounds like an xkcd comic involving the guy with the hat.

------
GFischer
"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)

------
andjones
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"

<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
"I think the comparison is close as sometimes the product people are the MBA
people."

One of the founding principles of Y Combinator is to make the Hackers the
product people.

------
metamemetics
Here's what I do to plan my code based on user experience. I use Free Mind
<http://freemind.sourceforge.net/wiki/index.php/Main_Page> and write in the
middle of the home node "Things A User Can Do"

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

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...](http://www.cooper.com/journal/2008/08/alans_keynote_at_agile_2008.html),
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-...](http://www.andersramsay.com/2010/02/04/notes-from-the-agile-ux-
retreat-at-cooper) 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
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.

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

------
gte910h
I think his "longbeards" actually do quite well on iOS where it says "Do X
just SO" and you get a pretty decent design if you just follow the 1-2-3s

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

~~~
count
I think it could be argued that formulaic design/experience HELPS long term,
if you have some functionality that the user needs. If your app
looks/acts/feels like the rest of the OS or environment, the user will (in
theory) learn it faster and use it more fluently.

A 'revolutionary' design may be awesome, and may increase the productivity or
ease of use of your specific application, while causing some serious friction
between your app and it's environment in the users mind.

------
ryan-allen
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.

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

------
danielnicollet
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. ;-)

~~~
nkurz
I want to believe, but I'm dubious.

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?

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

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

------
greenlblue
Good to be reminded once in a while that code is written for people and not
machines.

~~~
billswift
_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.

------
krakensden
On a side note, Heroku's web site is really, really pretty.

~~~
steveklabnik
Check out their documentation for the new Addon program:
<http://addons.heroku.com/provider/>

Click some of the links at the bottom. It's so gorgeous.

------
fun2have
Well Copper designed the first prototype of Visual Basic. I think that
explains lots. When you combine Zed's argument that "Nope, because the tools
they've given you are again controlled by some corporation with a certain
design ideal. If it's Microsoft then the things you have to work with are
Microsoft looking and feeling. "

How many unusable software products came about because of Visual Basic? I can
rant and rant about Copper.

------
cparedes
I would kill for nicely designed API's for the things I work with.

Then maybe I can stop writing stupid shell script wrappers.

------
jpwagner
Frontend - Backend = Profit

Awesome

------
jpr
Great stuff. I think I'm developing a severe case of nerd crush on Zed.

The part about linguistic experience was especially good. I have thought for
some time now that all configuration files, command-line options etc. should
have simple and clearly defined syntax. Some already do. My dislike of weird,
inconsistent and complex syntax (and semantics) is so severe that I've semi-
intentionally not learnt shell-scripting, Perl or Ruby.

Sadly, there are very few systems that I feel I get a good linguistic
experience(TM)(R) out of. I have come to think that GUIs as we know them are
based on fundamentally flawed ideas - pointing and grunting - instead of using
a language, the feature that separates humans from other animals.

I really wish good textual UIs (there aren't many that I know, but I'm using
one for writing this comment: GNU/Emacs) became the norm, instead of the
randomness of the contemporary GUIs or the bass-arckwardness of shell-like
languages. I think UIs should aim to become Turing-complete, completely self-
documenting and reflective. The distinction between a function, a program and
an user interface is in my opinion mostly arbitrary and harmful, creating an
unnecessary wall of misunderstandings between the author of a program and its
users.

~~~
jimbokun
"I have come to think that GUIs as we know them are based on fundamentally
flawed ideas - pointing and grunting - instead of using a language, the
feature that separates humans from other animals."

The dilemma is that human language is staggeringly ambiguous. This works
because human beings have an extremely sophisticated model of other human
beings in their head and a really good pattern matching facility, which makes
us really good at selecting the intended interpretation without even noticing
the ambiguities. Presented with the languages we use to instruct computers,
designed to be perfectly unambiguous, normal humans quickly get upset that the
computer doesn't understand them if they veer the slightest bit from the
tightrope of a language they're given to use.

In other words, if you have a computer that faithfully and consistently passes
the Turing Test, you may have something. Otherwise, pointing and grunting
might be less frustrating for normal people.

Another aside: pointing or at least gesturing is much better than even the
perfect language interface for editing a photo or playing a video game. So it
depends on the application.

~~~
Qz
One of the issues is that current UIs for computers have very little context
information about whats on screen, which would make language based interaction
much more convenient.

Also, editing a photo is a perfect example of where language interface _would_
be useful: instead of hunting through Photoshop's millions of menus for the
graphic effect you want, you could just say/type things like:

    
    
      Scale to 200%
      Increase contrast 10%
      Resize to 400 by 600
    

I'm pretty sure that language based interaction for photo-editing would
increase productivity by huge amounts.

The other thing is that we've somehow locked onto the idea that the computer
should be able to understand everything immediately or else it's not even
worth it. But in the real world human's constantly miscommunicate, and we
solve that problem very simply: ask more questions. So if the user says
something like:

    
    
      Adjust contrast by 10%
    

The computer could respond:

    
    
      Do you want to increase by 10% or decrease by 10%?

~~~
whatusername
But then you need to know the magic words (scale as opposed to "make bigger"
or "zoom" or some other combination). Point and click context menus try to fix
this -- "oh, it's 'scale'"

~~~
Qz
Or you could just allow all of them. If they serve different functions in
different situations, the program can just ask which function the user meant.
The point is that rather than view the program as a slave that is expected to
follow orders unflinchingly, the program can be viewed as something to be
conversed with, and capable of asking questions of the user.

------
c00p3r
Yet another blog post for the sake of a blog post.

Every educated software engineer know, that by respecting and following a
fundamental programming methodologies, such as data-abstraction, modularity,
encapsulation of details, and other basic techniques for managing the
complexity of large systems, you will get maintainability and programmer-
friendliness for free.

The problem is - most of in-house back-end developers and their public
teachers doesn't have a even a basic engineering education.

People who have managed to understand the ideas on which the SICP book is
based upon, let alone MIT graduates, never write such long but empty posts.

------
yycom
It's one thing for a random comment, but to see it on an actual, real live
blog post by the likes of Zed is irritating.

"couldn't care less", please. How can you be hackers if you can't get some
basic logic right?

------
jarin
If there were Zed Shaw fanboys I would be one.

------
rimantas
Looks like Zed got some different Cooper's book than I did. Or misread it
completely. "Inmates are running the asylum“ was one of the most useful books
I ever read, it completely changed my attitude. It's not "don't let
programmers to do interfaces", it is "build interfaces for intended users and
intended usage". If Zed thinks that Cooper's book is idiotic then he is just
unable to get what it's all about (like many other nerds — and that explains
why open-source is good for servers and sucks in UI department). I hope he
sticks to building awesome web servers nobody needs.

~~~
zedshaw
I don't know what book _you_ read but the title alone, "The Inmates Are
Running The Asylum" is offensive since it implies _I'm_ the inmate. But take
this quote just from the product description at Amazon:

"The Inmates are Running the Asylum argues that, despite appearances, business
executives are simply not the ones in control of the high-tech industry. They
have inadvertently put programmers and engineers in charge, leading to
products and processes that waste money, squander customer loyalty, and erode
competitive advantage. Business executives have let the inmates run the
asylum!"

Don't get much clearer than that, but let's talk about the damage the book
caused. For a book that purports to try to improve things for humans it sure
caused a ton of damage to humans. It was lacking in almost any real substance
and was effectively a thinly disguised rant about coders. It was used to fire
programmers, boost fake ass business guys, and created the plague of crappily
implemented products that may look slick, but fail in horrible ways.

In my own personal experience with the book I have had _numerous_ executives
and biz people toss it on my desk and say they read it and they agree. I've
had friends fired or demoted because of this book. It also spawned whole
generations of "UX consultants" who fleeced people using the phrasing and
words in the book. I personally had to deal with consultant after consultant
who would come in, looked at the best we could do, and then insult us. And any
time a programmer tried to show who was really in charge and to blame, out
came this damn book to prove us wrong.

I could go on, but no matter what little snippets of text you remember, the
impact of the book the way _I_ remember it is one of negativity toward a group
of people who were not to blame: programmers.

~~~
jaimzob
Then it sounds like you've known some asshole executives and consultants that
have completely misread this book.

Cooper's point was that, sans any other guidance, programmers naturally tend
to create interfaces that reflect the structure of the code (since that is
what they are immersed in) rather than the structure of their user's goals.
And the reason they don't have any other guidance is that people running
technology companies didn't have _any_ kind of design phase other than sending
salesmen out to get pointless checklists of features.

If anything, the book is a criticism of the way tech companies are (or at
least used to be) run rather than a criticism of diligent programmers doing
their best with incomplete information. In fact Cooper says this several times
during the book. Unfortunately, it seems easier for a lot of business guys to
use the book to transfer blame to programmers rather than implement what it
actually says.

Really bad Amazon summary too.

