Kevin Cheng  

Kicking the Llama

October 10th, 2003 by Kevin Cheng :: see related comic

Joel Spolsky is a vocal software developer who writes regularly on his website regarding software development topics ranging from interface design to project management. Recently, he published a book that collects a number of articles he has written over the past few years. This book, entitled User Interface Design for Programmers, discusses how programmers need not fear the development of user interfaces (UI) and outlines some guidelines and rules to demystify UI design.

As a former software developer turned Human-Computer Interaction (HCI) consultant, and one who has worked for years in the software industry with a smorgasbord of programmer archetypes, I felt his book and more importantly, the excerpts which I read in this area were particularly relevant.

Joel begins by describing the concept of control and its importance on a user’s perceptions and ultimately, potential frustrations. In particular, he mentions the importance of matching the user model against the program model leading to his axiom:

> A user interface is well-designed when the program behaves exactly how the user thought it would.

While his comparison to his former job at a bakery is a little reaching in relevance, the example does illustrate the impact of control on a person’s emotional state. He further discusses giving users the feeling of control by designing to the user’s model. Defining the concept of “program model” and “user model” for his target audience of programmers is hopefully a step in creating better UIs; in the least, it will create more informed developers. My only complaint was that his definitions were too brief. As our comic illustrates today, user models are not the same for everyone, especially programmers.

I don’t expect his articles to create a sudden rash of programmer inspired UI. Joel�s topics often discuss developer processes, platform selection and other technical issues. As such, his readership is not only limited to the choir of programmers who already believe in good UI design. Thus, his book and articles may simply serve to inform the uninformed regarding UI design and help programmer interaction with HCI specialists.

The book may help programmers do their own UI when they have no access to HCI consultants but what of those that do? How does a book like this affect interactions between HCI and programmers, if at all? Let’s first look at programmers in general.

In my personal experience, there are four major classes of problematic programmers that I have worked with:
- __The Enthusiast__: those who will bend over backwards to meet HCI’s requirements. These developers relish in the challenge but will sometimes spend too much time perfecting inconsequential UI aspects.
- __The Guesser__: those who completely misunderstand but assume they have an understanding and develop entirely the wrong thing until it is too late to change.
- __The Nielsen__: those who constantly quote usability rules from Norman, Nielsen or even Joel Spolsky to debate UI decisions.
- __The Fearful__: those who spend more time debating how hard it would be to do than the time it would take to actually do it. Their first line of defense is to try to change the requirement to match their program model rather than take on the task as a challenge. You would almost think they were afraid of anything UI.

Of course, there are exceptions and variations to these blatant generalizations and there are hybrids. The Fearful Nielsen is particularly popular. By far the most common class I encounter is the Guesser. The least common is the Enthusiast.

The solution to each of these archetypes is communication. Enthusiasts spend extra time on UI aspects that are unimportant. If designers can communicate with Enthusiasts better, we can determine whether a trivial UI component is as trivial from a development perspective. For example, I may specify a table must highlight the current row selected as a part of my design. Although I feel it adds clear visual feedback, I may not be so inclined towards it if I knew that it took a week longer than simply marking the row with an icon.

Handling Guessers is a matter of communicating with them on a regular basis to ensure they understand the requirements properly. The onus is on both parties; programmers need to ask questions whenever there is any ambiguity and HCI needs to regularly perform what I call “UI Code Reads”. Just as programmers ensure validity in their architectural design through a code read, they can ensure correctness of UI implementation with HCI.

Assuming the programmers are logical beings (and that’s a big assumption), a good HCI person can justify their reasons for breaking the rules Nielsen advocates abide by and when necessary, explain why a rule is not applicable to the situation. I could go into how I would never see it fit to question the choice of algorithms the programmer makes but that’s for another time.

Finally, the Fearful are perhaps the most dangerous on a team. The problem with a Fearful is that their priority is on the program model. To use Joel’s terms, the program model takes precedence over all else. If you request a dropdown menu to be sorted in a particular fashion, a Fearful may explain that it simply can’t be done because of the way their database was constructed. Let’s forget for a moment that the database should be designed with the UI requirements in mind. After all, many projects are upgrades dealing with legacy artifacts. The solution is communication - of what? Here, the risk lies in an HCI specialist�s inability to debunk what the programmer claims. If I was non-technical, I have to take the Fearful’s word for it and thus, adjust my requirements instead of challenging the claims.

In fact, working with any of these programmers is difficult when you are not technical. A Guesser misinterprets requirements for the most part because the designer speaks a different language than the programmer. Enthusiasts have difficulty conveying which features are technically difficult while HCI often does a bad job of articulating what features are truly usability must-haves.

While an HCI consultant could facilitate such conversations more easily if they were technical, perhaps it is easier for developers to understand basic UI concepts than it would be for a designer to learn Big O-notation; which brings us back to Joel.

Communication barriers between HCI and programmers cause all sorts of results, depending on the kind of programmer you are working with. Lowering these barriers will facilitate clearer communication which will lead to fewer misunderstandings. The majority of the gaps we encounter will be solved if this could be accomplished.

Perhaps a better overall understanding by developers will aid in that communication.

I leave you with a parting thought about the Nielsen archetype. Joel’s target audience is fairly new to UI so his book is fairly introductory. There are few, if any, noteworthy “rules” that haven’t been touched upon before. However, by setting a collection of rules and axioms on programmers, he runs a very real risk. Programmers are inherently logic oriented. In particular, digital logic is the domain they work and think in. There are 1�s and there are 0�s and rarely anything in between. Thus, when a statement is presented as a rule, it may be interpreted too literally.

Having read Joel’s other articles, I recognize that he doesn�t intend for these to be hard and fast rules so much as a way to educate developers. His book can be thought of as a collection of guidelines for a frame of mind. The only benefit of having Nielsen programmers quoting rules is that it perhaps provides a sanity check for HCI. Designers are certainly not perfect and we rarely have a second HCI person to give us feedback. Left to our own devices, mistakes or inconsistencies are often made. I encourage developers to take the rules you read on Joel’s site, on Jakob’s site, on UIE or anywhere else, apply them as guidelines and provide a rational feedback mechanism for us.

23 Responses to “Kicking the Llama”
Mike wrote:

Hahah… Being an ex-dev myself, I can totally relate to this week’s strip. While wearing the hat of a software dev., we often get into the thinking of more feature shown is better and end up plastering UI with everything we can think of.

isomorphism wrote:

Ok? Cancel?

Userinterface design is a pretty hot topic, for at least many years now. What I didn’t know was that someone could actually make a comic out of this and make sensible comments about UI design!

Roland Tanglao's Weblog wrote:

4 types of problematic programmers for UI design

(SOURCE:”joel”)- Very true and very funny because I have worked with all four types.

Wayne wrote:

Nice article, thanks.

At the risk of being both negative and off topic, the site formatting you’ve chosen makes it difficult to read.

For those of us with high-resolution monitors, the text is very small. That’d be forgivable if we could increase the text size in our browsers, but it seems it’s fixed for your pages. I have good vision, so I’d hate to think what you are putting a person with a visual-impairment through.

The dark-grey text on light-grey background doesn’t help either.

Normally I wouldn’t bother mentioning this, but as you are HCI-dudes, I thought it useful.

thegoodtomchi wrote:

Thanks for the comments Wayne. We’ll look into editing our styles so that text resizing works. It will be another triumphant victory for user feedback!

Mal Ross wrote:

First time on the site and what a great article to start with. :)

One thing puzzles me, though - kicking the llama?

Eric wrote:

Wayne, I don’t know if you’re familiar with it, but Mozilla Firebird ( ) (and probably Mozilla proper) resize the text just fine (as well as being good browsers in their own right).

I’m not sure it’s true that programmers are inherently binary in their choices. Maybe a beginning programmer is, but any experienced software developer should be quite familiar with design tradeoffs; often one particular design pattern or algorithm can’t be identified as an unqualified best. I would think most reasonably intelligent people could see the analogy to HCI rules. On the other hand I may be giving people too much credit; I’ve seen fellow developers redesign a progress bar so that it merely increments itself every x seconds (and restarts from 0 when it hits 100%) instead of actually tracking progress because it “looked better”.

Still, I think getting more people aware of HCI and UI design is a Good Thing; the fewer QuickTimes and RealPlayers we have, the better.

Eric wrote:

Oh, and Mal, I think the title refers to Winamp, whose mascot is a llama and whose motto is “it really whips the llama’s ass”. I gather Kevin is not particularly fond of Winamp’s interface design.

mp wrote:

Another class of problematic programmers:

Those that can’t stand what they see
as stupidity. If you were to face
the facts, some HCI people are, let’s
say, less than perfect. Also they tend to
be very political creatures — if someone
in upper management likes a particular
feature even if no customer is going
to need it and it is going to be staring
all customers in the face 24x7 and
it takes up valuable screen real estate —
the HCI guy is going to put his
full weight behind it anyway.
Of course the HCI guy is going to
see the programmers who oppose
his politically expedient issues
as “problem” probrammers!

brethorsting wrote:

winamp skins for dummies

I just found a new comic strip through joelonsoftware. I’ve always absolutely, completely detested User Friendly. I have never found it to be funny or interesting in any sense. However, I think that OK/Cancel is actually really quite amusing, and…

aaron brethorst wrote:

you guys really should open comments and trackbacks on the comic strip itself. I notice that the number of comments/trackbacks for the first blog entry under a strip are significantly higher than they are for the second one. This suggests to me that most people are just plugging the first trackback URL they find, regardless of whether they’re attempting to do a trackback on a strip, or on an actual entry.
cheers :)

Developer wrote:

I’d like to take issue with the tone of this article, represented nicely by this quote:

“Programmers are inherently logic oriented. In particular, digital logic is the domain they work and think in. There are 1s and there are 0s and rarely anything in between.”

I think that’s a pretty narrow minded and dehumanizing generalization.

Many people react to disagreements by dismissing the concerns of others as mental defects of their “kind”. This problem is particularly endemic to the software world, where people identify so closely with their cliques.

I think that it’s really unfortunate when people think about and communicate with their coworkers in this way.

Tom Chi wrote:

Well we’re sorry if the tone of the article offended you. There is nothing wrong with being logical, in fact, it’s something that many people (both developer and non) pride themselves on. If it sounds like a mental defect, then that is not the intention, as both KC and I are reasonably logical people.

That said, what the article tries to do is intiate a dialogue between developers and HCI folks. In most organizations it is the HCI person who is dismissed as “their kind”, and rarely understood (if for nothing else than their small numbers compared to developers). That the article would put developers on the defensive is already surprising to me. KC is describing his own experience, and if you have other experiences which have helped you avoid these very common communication problems, then we’d definitely welcome them.

stanley chong wrote:

not that this has anything to do with your above article, but it’s really an eye strain to read your blog as there is little contrast between the font color and background color.

Ben Poole wrote:


mr. hu wrote:

I agree with the above poster. Programmers are not DSP chips. most of us rarely run into binary anything, and get nervous when talking about stuff in base 16.

Programming is every bit as creative as any other “creative” endeavor. we just don’t go to art school.

Kevin Cheng wrote:

I absolutely agree, programming is an incredibly creative endeavour. However, the machine you’re working on IS a set of chips and gates and a programmer’s problem solving skills involve creatively manipulating this logic. Their DOMAIN is logic and they’re GOOD AT IT.

I believe the quote “Developer” quoted above is a little out of context, too. I was referring to the risk of Nielsen type programmers who interpret and apply rules too literally. Not all programmers are this way and in fact, most aren’t but the kind of programmer I describe does exist and I’ve experienced several even in smaller firms.

Vernell wrote:

Just out of curiosity, does anyone know of any major or minor software products that are great examples of HCI design done right?

Jamie Fristrom wrote:

I consider myself a “fearful” and I wear the name as a badge of pride. Fearfuls are simply more likely to ship on time. We may be confused with “lazies”, which is annoying.
Here’s how to deal with us:
* Ask us what it would take to get the feature done. Time / personnel / etc. Remind us that with computers, nothing’s impossible. Ask for best-case and worst-case estimates.
* Is there enough slack in the schedule to accomodate it? If not, decide what features to cut to accomodate it. Or admit that, yes, this feature is not in fact worth it.

Kevin Cheng wrote:

I will happily admit that certain features are not worth the time it takes to implement them.

I don’t believe anyone that says, “that’s going to take too long to do in the current architecture” is automatically a Fearful. Rather, those that do so as the FIRST RESORT rather than the last are what I would call Fearful. Rather than taking it as another requirement which needs to be implemented, some programmers almost instinctively resist when another 15 minutes of thought might actually find a reasonable approach. Having a technical background myself, I’ve sometimes found that I had to personally walk them through their reasoning and find that alternate path myself. Something HCIers should not be expected to be have to do nor be able to do it.

Having said all that, I’m simply clarifying my definition, what you said in terms of process I completely agree with. It’s a question of the attitude more than the actions that make someone a Fearful.

oa wrote:

came here to read the Joel book review, then complain about the font size (Mozilla resizes it fine, but why would a HCI site use a non-readable font by default?), but actually I have to comment on the “programmer kind” thing, no matter how off-topic.

mr. hu: I firmly believe that to be a good programmer, you need to understand the platform. To understand the platform, you have to understand how computers work in general, and that DOES mean you need to be able to work with binary. So, if you’re nervous about it, I think you need to train more.

Besides, DSP chips these days use floating point and are better at “fuzzy logic” than most programmers.

Fred Swartz wrote:

Your basic points are good, but the characterization of programmers is surprisingly off the mark for programmers I know. You might recognize the offensive characterization when it’s flipped around:

Graphic designers are inherently illogical. In particular, they think and work in an analog domain where things are rarely 1 or 0. Thus, when a statement is presented as a rule, they may not be able to understand and follow it.

fbr.soup wrote:


Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?