Joel's Iceberg Secret -- 90% of the work is in the backend

Joel Spolsky's Iceberg Secret says that designing the UI is only the tip of the iceberg.

    Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want. It's just never going to happen. Get over it.


    I promised to tell you a secret about translating between the language of the customers (or nontechnical managers) of your software and the language of programmers.

    You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we're talking less than 1%.

    That's not the secret. The secret is that People Who Aren't Programmers Do Not Understand This.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I don't get it. Why the need to diminish the importance of UI?

I know he is talking about desktop applications and the like, and that the non-technical people he refers to are not the UI designers, but the customers or higher-up executives and middle managers. But does anyone believe this applies to web work where information architecture is probably more like 50% of the work. Analogize this to the architect and contractor who are involved in the building of the house. At least half of the work should surely be spent on clarifying the design before breaking ground to put up the building. This discussion seems like an extension of the Extreme Programming versus Interaction Design debate.

Some of his corallaries (which appear at the bottom of the essay) ring pretty true. But, I don't understand his attempt to undermine the importance of the UI in order to make his argument. It seems in some places, that he talks about UI design as nothing more than decoration. It's just ashame that his agenda wants to separate the technology from the user experience.

I didn't see it that way

I'm not sure if I really see it that way. It doesn't seem like he's really diminishing the importance of UI. I'm reading this and seeing two major points

1) The idea that you can build a succesful product, web or software, by sitting a client (I'd extend this to any potential customer) in a room and ask them what they want is fundamentally wrong. This is something I really agree with. Its difficult for customers to explain what they want in a way that translates into new features or updates to current features. That is really where having a smart information architect pays off. You need to be able to understand the way a user will relate to the problem at hand and be able to translate that understanding into a UI. His analogy is not the architect-contractor relationship but the architect-customer relationship. There's a big difference there. In the architect-contractor relationship the two parties have similar domain knowledge. That knowledge is centered around what to do to solve the construction problem at hand. In the architect-customer relationship the architect translates the customers abstract wants and tangible needs (I want a modern building that can accomodate 5,000 people) into something workable.

2) Non-technical managers or clients equate the interface of a product with the product itself. This is where I think the iceberg analogy comes into play. His point is not that the UI is only 10% of the WORTH but 10% of the WORK. In software development this is often the case (as an information architect now working in software design I can vouch for that). The programming involved in making the UI look and act as specified is trivial compared to the programming involved in getting the backend to work. If he was talking about the thought and care that should be put into the backend vs. the UI I'd completely disagree. The interface for a piece of software should get at least as much thought put into it as goes into the code. This is where the translation of your knowledge of the problem at hand into features and interface gets put into play. If the application doesn't solve the users problem in a clear and easy to use way it won't sell.

This is the extension I think this article misses. Its not just the managers and clients who equate the quality of the UI to the quality of the product. Your customers think that way too.

Yes, I agree with your points

Yes, I agree with your points. I did not suggest the architect/contractor analogy to describe the customer/consultant relationship. I was describing the specifications requirements writer/programmer relationship.

I don't disagree with most of what Joel says. In fact, I find that most of what he writes rings true in that essay. I was just picking apart a piece of it that seemed contrary to what I've experienced working on both sides of the development of web sites (specifications requirements/site development). I understand that what he is describing as that 10% of work is contrary to what a client perceives. In his description, clients focus on window dressing rather than functionality. No doubt we have all experienced that. But, in my estimation, 10% is just not all that accurate to describe the amount of effort in doing IA/Interaction Design. Perhaps I'm just nitpicking. (Surprise, surprise)