Fog Creek Software
Discussion Board




The Iceberg Secret, Revealed

Discuss "The Iceberg Secret, Revealed."

http://www.joelonsoftware.com/articles/fog0000000356.html

Joel Spolsky
Thursday, February 14, 2002

Too true.

I worked with someone who excpected the output of external software developers to match that of external graphic designers who produced page mockups in PhotoShop.

Surely there is a bigger issue here though - do we just accept "they don't understand" or is there a way to ensure people in these roles do understand?

Walter Rumsby
Thursday, February 14, 2002

Again Joel another very on target article.  It comes down really to managing the expectations of your ultimate end user whether its a CEO or three junior accounts payable people.  This train of thought goes even past your prototype, but also your emails (as you pointed out), presentations, day-to-day conversations with the stakeholders. 

A consultant I worked with taught me this...When speaking to clients and stating times always take the longest time and make it first for example instead of saying 4-6 weeks, say 6-4 weeks.  Say those to yourself a couple of times, you always remember the first number don't you.  Just another way of managing expectations, which is just underpromising and overdelivering.

I fully agree with the perception that users have no idea what they want (generally).  They have a concept of what they would like the application to do, but cannot articulate that vision in technical terms.  Doesn't mean you won't come across a savvy user every once and awhile.  This has happened to me on a couple of occasions and is a welcome change when it does.  However, for the most part your going to have manage the expectations of the end user and use the tools Joel provides in this piece.

One final tool I would like to pass along.  My former director used to tell this to uppity end-users who were clamoring for an application.

"Software development is like building a house.  You can build a house in a few days...if your only going to live there for say 48 hours you would say sure go ahead and build it as fast as you can.  On the otherhand if you want to live in that house for 20 years, you probably want the contracter to take a little more time, wouldn't you?  The point is we can build an application in a few days or we can build an application in a few months, which would you prefer?

Grant Case
Thursday, February 14, 2002

I am a developer of software for the hospitality industry and the situation is [sort of] the reverse. Our clients seem to know what they want, however they don't know how they want what they want to actually work. If that makes sense?

Our initial PC product was butt ugly, absolutely butt ugly, but it had a really good featureset, and thats what seemed to sell it for us when you have a restauranter knowing that he wants this product to print out on the printers this way, in this color, with this functionality. If we can do it, then they don't seem to care that the program doesn't look so crash hot.

Saying that though, we have been slowly making our software look better over the last year, and it now looks quite pretty. Also outr wireless handheld software has generally looked pretty good all the time.

Mark Allanson
Thursday, February 14, 2002

There is no way to ensure that a nontech understands anything, short of making him a tech, which would likely be more time consuming than adapting your project to make the visual interface reflect the state of the code.  Maybe impossible. 

I am working on a project right now that has this problem.  We gave the client a 100 page book explaining in detail every process in the application, with navigation charts(it is web based), and 1 page summaries for each section so they would only have to read a page or two to get the gist of the program.  We built the program to spec, and now they want something completely different.  And they are angry with us that the project they paid 60000 for is not what they wanted.... turns out they never read a single page of the design document.  We had meetings showing the interface, and all they did was ask how far it was along, and make a comment or two.  It turns out that all of their input was about things that they didn't really care about.... And now that it looks done they expect it to be finished and work how they want - and they don't understand how changing the way client roles work could take 2 weeks to complete.  Now our design team is demoralized, we are stuck working for no pay on a project that was due months ago, and our client hates us.

This article is straight to the point, and has provided me with helpful advice to deal with clients like this in the future.  I wish I was able to read this article a year ago, it would have saved us an immense amount of trouble.

D. B.
Thursday, February 14, 2002

It is funny, but perhaps the best kept secret in the IT industry is that the customer does not know what they want.

Perhaps more specific is that they don’t know the how, and the whys of information design. They think they do...but they don’t. They have a vague idea. This is also why so many projects get trouble when they consist simply of a specifications list.

We can make a specification that we need information about how much product we sold last month. Both the accounting department and the sales department will agree on this need. However, what really matters is the task at hand. In other words, good software is task orientated. Thus the task of the accounting department taking inventory is totally different then what the sales department does. The only difference between the two departments is a task. They both need the SAME information. Thus our specification for sales data is NOT good enough.

A good software designer will create an imaginary user and start solving tasks for that user. Since designing software is task oriented, then you must get the customer to focus on tasks.

However, the focus must be ON THE TASK and NOT the software design. Customers cannot design the software!

Just today I had a customer request that a check box be placed on a form when a booking to a event occurs. That way they can produce a printout to show that the customer is booked to an event. I did not tell them that this was a dumb idea.

What they really need is a printout that shows their booking status. If they are booked to an event, then we already know this. In addition, if you have to check a box then the operator might forget to do this (or when un-booking from an event). You see what Joel means by “the customer only sees the interface”. In other words...they simply think...and see and want a cute little check box. What happens behind the scenes is unknown to them.

I will probably make a report that displays the check box but the users will NEVER have to set, or change the check box. In fact, I probbably will not even display a check box...but simply place a status field into the report.If the user has an active booking we know this already. Now, it sounds really dumb that the customer is asking for this feature. This is exactly Joel’s point about the customer does not know how to do this stuff. My customer *does* need the printout with the status but not a check box.

My post is already too long...but the comments on "pretty UI" must be taken with a grain of salt. Clean, and nice is always preferred to real Jazz. CityDesk is *very* clean, and look good. But it is not snazzy. Nor is yahoo's home page. (which is the #1 home page in the work environment).

Both CityDesk and Yahoo prove that clean and nice is better than too much snazzy. I suppose as we march more towards the mass market then *perhaps* snazzy is the way to go.

A few screen shots of one of my applications can be found at:

http://www.attcanada.net/~kallal.msn/Rides/Rides.html

I use NO color in any of the screens..and only the front splash screen has a picture.

Albert D. Kallal
Thursday, February 14, 2002

Another thing I learned early on is that the numbers in a demo screen must be reasonable and must add up correctly.  If you mock up a simple graph with a little tab data to go with it, the whole thing must reflect a reasonable sample of domain knowledge.  If it's wrong, the customer will not be able to get past thinking about the peculiar domain situation, and the discussion will be a complete waste of time for all concerned. 

The programmer says "it's just a bunch of sample numbers, ignore the values" and the customer says "you're an idiot and  this program is totally hosed - the RJPC factor is never over 3.5 when the ikea is low in the first quarter."  The programmer shrugs and says "whatever" and everybody stomps out of the room ...

Better is for the programmer/designer to try to figure out what a "good" situation would be and try to illustrate that in the examples.  If you hit it, great, if not, you've found a discontinuity early in the game and can learn from it inexpensively.

Doug Johnson
Thursday, February 14, 2002

I learned this lesson a couple of years back.  Still stings.

I can only add that short release cycles have proven helpful.  Prototype only what can be produced in a short period of time; no more than three months.  Hit your first release.  Then prototype and hit the next.

After two or three releases, there will be a general understanding about what can be accomplished in a fixed period of time.  Moreover, as the project evolves, the client begins to distinguish between real and imagined needs.  Customers, believe it or not, actually begins to understand what they want.  (I think the XP folks call this "steering".)

Of course, its not always easy to get going in this manner.  Negotiating that first release can be .. something of a challenge.

Evan Owens
Thursday, February 14, 2002

Customers apparently know what they don't want.

I think software development would be easier if the customer was simply removed. From the developer's point of view, this could be achieved via some kind of human partition that can translate between customerese and programmerese.

These people would require software development knowledge. The fact that few such people exist, preferring to throw themselves into project death marches, attests to the ultimate satisfication in programming itself (or, alternatively, to the collective stupidity of programmers).

Dominic Cooney
Thursday, February 14, 2002

Your article is so true.  I have recently experienced this very phenomenon and it's made me decide to change the focus of a project which I am part of at the moment.  The excellent work which we have done so far all falls in the category of the 90% of the iceberg that's underwater.  We need to now make the 10% that people see accurately reflect all the hard work which is embodied by our code.  It'll be interesting to see what comes out of this change of direction.

Claire Henning
Thursday, February 14, 2002

Totally agree with everything Joel says, and with many of the comments above, especially the one about avoiding using obviously "dummy" data in prototypes or mockups. People just _sieze_ on that stuff in meetings. Why? Because that data might be what they're experts in, and it hurts them to see it wrong.

One small point: Joel writes "The secret is that People Who Aren't Programmers Do Not Understand [that the visual stuff takes maybe 5% of the work]." Now, I'm not a programmer, but an interaction designer, and I really really do understand this. I've made sure that I understand enough about servlets, or database indexing, or whatever, to really talk to the developers I work with. Now, it might be a bad idea to ask me to start writing classes and designing the databases... but I certainly know when changing one line in my spec document means a day or a minute of a developer's time. 

Many other good UI designers, _do_  indeed understand The Secret. Clients maybe never will, but there's no excuse for anyone on the development team not to have a reaonsable understanding of _any_ aspect of design and production that can impact the schedule or product.

Andrew H Otwell
Thursday, February 14, 2002

I love your writing style Joel!

Keep up the great work!

anon
Thursday, February 14, 2002

Our non-techy 'project manager' was bowled over by the fact that our windows app had a 'fantastic blue gradient bar' at the top and spent half of a recent meeting letting everyone know how important he thought this was ... !

Steve Brett
Thursday, February 14, 2002

> A few screen shots of one of my applications can be found at:
>
> http://www.attcanada.net/~kallal.msn/Rides/Rides.html
>
>I use NO color in any of the screens..and only the front splash screen has a picture.

Albert, looking at your screenshots, it looks like you've ignored windows colors and hard coded "GRAY" into a bunch of your screens.

Check out: http://www.iarchitect.com/color.htm

Also, wouldn't your "Move it!" button be better served with 3-pushbuttons instead of a pushbutton and 3 radios. (I mean - there are 3 distinct actions - why click twice for any of them?)

--

On Mark's comment about hospitality industry appz. Any kind of POS-style application is usually REALLY UGLY! Not because of bad design, but because of interaction rules with the user. Lots of the applications are designed for touchscreen use, and the BIG UGLY BUTTONS actually help the application. Developers often have a harder time accepting that becase we are having a difficult time getting over "layout shock."

--

Ok, mandatory kudos to Joel for voicing what developers have always felt! :-) Perhaps everyone should sign their messages with an OBJKU (Obligatory Joel Kiss Up :-P)

James Wann
Thursday, February 14, 2002

A considerable part of the last ten years has occupied me in specific client products.  Other than when what was wanted was a modification to how their existing accounting system worked I have never shown any client a prototype.

Prototypes kill. 

Apart from my consultancy delivering specific requirements I've also given consultancy on how to manage development and pull round a project to get a product out of the door. 
There was one client that was working on a major generational change to their core product, a complete replacement.  They worked ceaselessly on the requirements doc, they generated prototype VB forms for virtually every single dialogue and form.  They debated and argued every single point.

And when they came to develop it drove itself into the ground.  They had debugged a prototype and forgotten that the map is not the territory.  They had conned themselves that they'd actually done some work.

Prototypes of forms are almost entirely useless.  Prototypes of code aren't, exploring methods to handle this or that situation are fine, but they aren't for users to make decisions on.  That's programmers and designers playing and its important to do it.

The way I solve, or mitigate, the problem of User/Developers not understanding each other is to forget about software entirely when talking to the user.  I enter their workplace I watch, listen, take no notes, I talk with the people doing the actual job more than the management.  I talk only in terms that they use.  I admit to them that I'm stupid that I don't understand what they do, I let them teach me.

Then I go away and write a short specification for them in english that hopefully they'll read and ask questions on.  But I don't expect that they will.  If they ask to see mockups and prototypes then I give them a rate at which that can be done and tell them it will extend delivery time.  They rarely if ever come back wanting prototypes, if they do then I expect that project will go pear shaped at the end.

As soon as there is something ready to test, I deliver it to them ands encourage them to test it, not approve it (though that's implicit), but test it.  Often they won't or their work doesn't allow them to test it but if they do it improves the process no end. 

There's also no hard and fast rule that applies, different management, different users require different handling.  This is a people skill.

Simon Lucy
Thursday, February 14, 2002

Pragmatic answer, and obviously written by a programmer!

The answer is surely to make sure we understand what the client wants. If I want a Ferrari, I want a flash car that looks as if it goes fast. Even going fast is secondary, because most people will never drive it at 150mph. Ferrari engineers get excited by carbon fibre and V12 engines, but buyers actually want to impress the neighbours.

So I find the first step is to understand what the client really wants. For the clearer headed this may be some business objective - sell more widgets, make Joe in accounts redundant to save money (or stop him taking my job!) Very few people know they want an Sql powered networked content management system.  For others it may be because the boss told them to do something, and they know new software is the answer to all their troubles.

Once you understand the real need, particularly if the client doesn't see it himself (or herself) you are onto a good thing. They will be pleasantly suprised because you have made their life better or made them look good (their real objective) and they will pay double bonus and pay on time .......oops lost the plot a little there.

Satisfy their real needs, give them somthing to play with that gives them ownership (I like the GUI idea) but don't let them anywhere near the techie stuff, thats our domain. And always tell them it will take take twice as long as it really will so they are impressed by early shipping.

Keep up the good work Joel

Peter

Peter Lovatt
Thursday, February 14, 2002

I like the idea of having the state of the UI reflect the state of the application and infrastructure.  This insight is analogous to the WSIWYG principle, OO UIs, etc.  Users shouldn't have to keep a mental model of the state of the software (who cares); it should be obvious from what they are most interested in (usually the UI).

I've also made the mistake of creating a proof-of-concept prototype that was taken for production code.  In this case the UI was not what the user was interested in.  Nevertheless, result = death march.  Never again!

David Hawley
Thursday, February 14, 2002

Larry Constantine's perspective on user interfaces I think is a useful one: As far as the user is concerned, the UI _is_ the system. No matter how hard they try to resist that view, and no matter how hard scuba-diving programmers try to point out the deeper underwater nature of the iceberg, they will inevitably assess what they cannot see by what they can.

Kevlin Henney
Thursday, February 14, 2002

Having worked as a software developer for a while now, I've found that there is no substitute for becoming a domain expert.

How can you write software if you don't understand what it is supposed to be doing?

Eric Ulevik
Thursday, February 14, 2002

I have experienced the iceberg effect, as probably most of us have, and I think the idea of having the GUI reflect the reality underneath is an interesting one. I haven't tried it, but I'll keep it in mind.

There is a more basic issue, which is that the customer needs to know what is really going on: the growing GUI is just one way of doing that. There are other suggestions already in this discussion and they are mostly good.

Joel's original, which is to "spam" the stakeholders with the real status, is probably the best. We should know our status and we should report it.

As for the on-site customer, while it may be difficult to get a qualified responsible customer on the team, I'm here to report than when you do it is very powerful. The thing is, the most important things happen. The customer sees what you are doing and therefore sees that you are working hard on his stuff. He sees what you do and therefore learns more rapidly about what he really wants.

Maybe it's hard to get and keep one. I've worked with lots of teams who made the effort, and they are all very glad that they did.

Ron Jeffries
Thursday, February 14, 2002

If anybody has read Pratchett, I think this is definately Headology were talking about.

In addition, I have found that business users are most impressed if the email contains the following:

A graph - made in Excel, but it has to be real good.  These people can graph in their sleep and will leap mercilessly on anything below par.

A formula.  The forumula can just describe the graph, or be lifted from a text book, but nobody ever argues with anything that looks mathematical.

Ged Byrne
Thursday, February 14, 2002

I don't see how this "spamming the people the other end" works in the situation of "salesman agreed price on vague spec".

Personally, I'd like to see some sort of negative accountability fed through to sales - as it is, the saleman who sells the most stuff is the winner. It doesn't seem to ever be accounted for that he's selling things for less than they cost to make. That's engineering's "fault" for not being able to make arbitrary projects arbitrarily cheap.

At the point I usually get a hand in projects, the "spec" has been "agreed" and there's no option for talking about things. ["spec" means "a weird mish-mash of requirements, user-stories, detailed designs of the easy bits of the structures, vague hints about where "magical" things are required and odd absolutely non-negotiable mandatory counter-intuitive UI sketches put together by people who will never use thesoftware. "agreed" means that it represents the minimum delivery and maximum price. "magical things" means the points where they stop saying things "the customer number will be checked for validity by check that it is a valid customer number" and start saying things like "this will compute the correct tax allowances for all employees"]

Far too often this is the result of long, tiring meetings between our sales people and people from their company who are sufficiently far from doing any actual work to have approval authority to buy the thing. Hence the reason you get specs which say things like "CUSTOMER_TRACK_ID - this field holds the customer track id".

{As a footnote Windows does much the same thing with files it doesn't understand; "install.pl      1K      PL file"
in the hope that repeating the thing requiring definition is defining it.}

I got one the other day - a discussion document about a possible design. 6 pages long, page 1 started saying things like "We'll keep the following data: customer identifiers as a 4 digit number..." which personally I thought was rather forward for non-technical people to be handing to technical people. Especially the fact they got that involved in the design and haven't even decided if we're bidding for the thing yet or not. Quite apart from these not being the cobol days and we don't specify fields by the number of decimal digits anymore.. you want 10,000 possible customer records, ask for minimum 10,000 possible customers...

Mostly the problem is that the technical people are the /LAST/ people that ever get involved in projects, because they're very, very busy finishing off the last late, overbudget project...

Katie Lucas
Thursday, February 14, 2002

Corollary to the "build your UI to match your existing feature set" rule:

Whenever possible, GET YOUR CUSTOMERS USING YOUR SOFTWARE WHEN THE FEATURE SET IS SMALL.

Put them into your software when it's 30% done, and you'll set their expectations at that point.  Make them wait until it's 100% done, and they'll be annoyed by the wait, and then take for granted everything you've done.

But put them live when you're at 30%, and every step of the way to 100% will seem miraculous. 

Caveat: obviously, there are some systems where this doesn't apply; don't try to sell a broker a system that lets you buy but not sell.  More applicable to a system where buy and sell is complete, and then you add *graph*.

Jeff Porten
Thursday, February 14, 2002

Regarding Cusomer in your team. You alwayd do have a Customer - at least as a role. This is basically a part of what Program Managers at MS did.

In my project though I would be more than happy to have a Customer in a tean, it is not possible, so here I am - playing a Customer role.

The problem is that I'm not a good Customer - sometimes I don't have an answer - I have to get it from somewhere, sometimes I have a wrong answer or priorities. So I'm sure it would be much better for everyone to have a customer in a team.

Roman Eremin
Thursday, February 14, 2002

I mostly agree with this article. But, Joel I think you're too dismissive of the customer role. You say, "Assume that your customers don't know what they want. Design it yourself, based on your understanding of the domain. If you need to spend some time learning about the domain or if you need a domain expert to help you, that's fine, but the design of the software is your job. If you do your domain homework and create a good UI, the customer will be pleased."

So ... ditch the customer, but find a domain expert or be the domain expert yourself? There's got to be a balance, simply because the customer is the one who has the need, initiated the project and will be (at least partly) the judge of success. If the customer is an idiot, then it's simply going to be a difficult project, domain expert or not.

Chris Morris
Thursday, February 14, 2002

So the USGA banned the Callaway.  Big deal.  These are the same people who tell you you can't wear metal spikes anymore.  The USGA is a waste.  Use the Callaway anyway.  Have fun, its a game.

Pat
Thursday, February 14, 2002

Now there is an interesting additional extra corrallary to this.  I have experienced this distaster.  Do not get infected with the tendancy to run two tracks of development - an "enron" track or demo track where one has a mockup that simulates the product for the board meetings, and another more solid tested version that lags behind the demo that is considered to be the real thing.

The demo of course always wins, becomes the shipped product and lasts far longer than anyone coceives of.

peterk

Peter Kennard
Thursday, February 14, 2002

I've been fortunate to work with reasonable clients on occasion. In those situations, I've found that an accurate visual prototype works pretty well.

Letting the graphic designers draw a pretty picture and show it to the client is a recipe for failure. Working with the graphic designers to come up with a pretty picture that we could actually implement is much better. You can show the picture to the client, say "this is a picture", and walk through what buttons the user would press to accomplish a task. After the client approves the picture, you can say "okay, now I'll start writing the code."

This only works if the client can comprehend the difference between the picture and the program, and if the client is basically honest about what they've agreed to. I usually send a follow-up email saying something like "we agreed that the screen would do x, y and z." It'll probably get changed in the future, but at least the development team will get paid to change it.

With a client who can't tell the difference between a demo and a program, break out the magic markers. When you sketch a prototype on the board, it's very hard for a client to conclude that the program's already been written.

Beth Linker
Thursday, February 14, 2002

Great comment about XP and the onsite customer. The "context" of the onsite customer is usually not discussed. Eliciting requirments can take place in many ways. Face to face "discussion" of the requirments can be very useful in many instances, but the requirment to have a "customer" in your face at all times, needs to be placed in context.

Glen B. Alleman
Thursday, February 14, 2002

I have done RAD programming for 15 years.  I spend about 1 hr to get the initial specs and then return in the next 2 weeks with a initial prototype.  We discuss the prototype for about an hr and a week later repeat the process.  This has worked for me and the clients.  We both get educated by each other.

My biggest complaint over the years has been the programmer who doesn't understand the business.  By not understanding the work flows they can't buld the system flexible enough to handle any upgrades.  If they knew the business they would have programmed the system to handle the users requests.

Every programmer should learn about accounting and cost  accounting, and sales these topics will be used in most of their projects.

Great website !
Bill Benko

Bill Benko
Thursday, February 14, 2002

I've found that as a developer, part of my job has been to educate my users so that they can develop the communication skills to understand what it is that they want. 

Two years ago we began the task of replacing an old VAX mainframe with a SQL Server back end/VB front end system.  The first objective was to replace the functionality of the old system, and the longer-term objective was to begin to add new functions that the old system did not handle.

As a newcomer, I was not used to the old system, and therefore could think of tasks in terms of outcomes instead of HOW the task was already being done.  When users would ask for something like a printed report to send to the Distance Learning Department, I would say to them, "Forget about what you think needs to be done programmatically.  I'll worry about that.  What is your ultimate goal?"  They would begin to realize that what they really needed was just a way for Distance Learning to be able to access the same data, so instead of passing a piece of paper down the hall, the Distance Learning people could pull up the data themselves.

Slowly they began to think in terms of tasks instead of implementation, leaving that up to me.  For my part, I would follow them around and ask a million questions, like, "Where does that piece of paper go after you're done with it?  Why does this flag get set at this particular time?  What do these codes mean?" so I could speak their language and they felt comfortable that I understood their needs.

At first they were convinced that the new system would never successfully replace the old system.  During the testing phase we had to reassure them time and time again that new systems had bugs, that the bugs would get fixed, and if they found a bug, that was a good thing, because then we could fix them; that their JOB was to help us find the bugs.

I admit that I am fortunate in working for a small place (~40 reasonably intelligent people) with minimal politics and managers who are only one level above the people who actually do the work.  Therefore the managers themselves are reasonably familiar with the processes, so they're not in fantasy land when it comes to understanding the workings of their own departments.  We're also only one site and not developing software that has to be shipped or sold; I admit that this makes the job a whole lot easier.

Anyway, nearly two years later, everyone is glad that we replaced the old system.  The new system is running smoothly and only an occasional non-lethal bug pops up once in a while.  The users are comfortable with asking for what they want, and they trust me if I tell them that, no, we don't need a check box on that screen.  We've found that common ground where the users' needs are me in a technically sensible way.  I guess I'm lucky.

Dana Hoffman
Thursday, February 14, 2002

We are all customers of something. How often do
you know what you want? How often are you
unhappy when you get it? Talk to a landscaper
sometimes about their customers :-)

todd
Thursday, February 14, 2002

Albert,

Use GIFs for your screenshots, that's what the foramt was desgined for - graphix.  JPEG is for pictures.  Try it and you'll see the difference.

Tekumse
Thursday, February 14, 2002

Great article, reminds me of a saying that I live by, "Give them what they want, not what they ask for."

Bob K
Thursday, February 14, 2002

Having the UI match the state of the actual codebase is an excellent idea.  I don't think it works because the customer is an idiot who doesn't know what he wants, though.  Rather, the UI is how users communicate with programs.  They're not techies, but they do have an intuitive understanding of how programs work, and it's based on what the UI communicates to them.  A UI that doesn't match the underlying existing program isn't just misleading, it's a visual lie.  You can tell people "This is a lie, but tell me what you'd want to change if it were true," and some will get it, but visual communication works on such a visceral level, they're more likely to believe the picture than what you tell them.

Why not just tell the truth visually in the first place?  Spend the time to translate the reality of the program to the pixels on the screen.  Make the made-up numbers bright red so when the customer tells you they're wrong, say, "Exactly; when we get the right numbers, they'll be black."  Make the buttons that don't work yet look broken on the screen.  Grey out the areas of the interface that relate to unfinished areas of the program.

It's all about communication.  It's not that customers don't understand the 90/10 rule.  It's that they expect the 10% they see to iconify the 90% underneath so they can understand it.

Lucian Smith
Thursday, February 14, 2002

But the worst is the CEO who *used to be* a programmer.
They have same problem understanding the iceberg (that
comes with the CEO title, no matter what), but they also
usually come with the memory that "when they were a
programmer" they could code that piece in a few hours.

Art Mellor
Thursday, February 14, 2002

We solve the "too extreme" problem of having the customer in the room by hiring people who are sharp enough to do the hard work that you mention - develop the principles, concepts, and UI that the customer will want. We call these folks customers, because we want the developers geared toward satisfying them.

They are technically savvy - they do understand the Iceberg effect. I don't know how you could develop software without a few of these key visionaries on board.

Mark Lemmons
Thursday, February 14, 2002

After getting burned as a developer on software projects where all I got were vague "requirements" for features, I decided to take on the onerous task of bcoming the person who understands how to translate between mangers and programmers.

To the development team, I play the role of "customer".  I describe what is required in excruciating amount of detail, which I gather by going to the users and aking them lots and lots of questions about what they are trying to  accomplish (Tasks, not features!), WHY they are trying to solve a problem, and the steps they think are most important to them.

Some of the things I've learned:

- Establishing trust with the development team and the actual business client is the most important thing.  Both sides need to feel that their needs are understood. 

- One should be able to explain things to each person at the appropriate level.  If the customer wants to know why it's important that the application be multi-threaded, then find a simple diagram and explain it.  Spend an equal amount of time on the technical details and the business benefits of doing it this way.  Make sure your diagram LOOKS GOOD.  It should be as nice as the Info Graphics on USA Today.    Expect that the marketing person in charge of the project will take that diagram and use it to explain to THEIR bosses why a multi-threaded application is needed.

- Figure out the key features and capabilities of the system, and produce them first.  If your system is going to require a LOT of data to run properly, it's in your best interest to make sure that users are able to enter and retrieve the data as early as possible.  Otherwise you may find that they had very different expectations of what they were getting.  If they start to deal w/ the /very/ early tools and interfaces, they will be a lot more sympathetic to the amount of time it takes to do things, and will be MUCH happier when you roll out each new widget.  Everyone will be more focused on the functionality, rather than the interface.

- It's in the best interests of the development team to avoid fingerpointing at all costs.  Once things start to go downhill on a project, it's always the development team that gets burned.  It's the developers' fault if the user didn't understand what they wanted.  This is because the criteria by which developers and marketing folks are measured for success are very different.  A marketing manager is sucessful even if the project turned out to be vaporware.  Not so with the development team.

Thanks again Joel for a very thought-provoking article.

Anca Mosoiu
Thursday, February 14, 2002

Well speaking as one of those dreaded CEOs who "use to be a programmer", I can say a couple things on that particular subject:

1. Yes, I do sometimes make the mistake of saying something like "Hey, I could have done that in two days!"  Its a mistake.  It also happens to be true.  But I always say things like, "Geez, I could never have done that as fast as you did."  Much less of a mistake. :)

2. Everyone in my company gets involved in technology.  They don't all have to be programmers, but they all know what software is, how it is built, how long it takes, what the icberg looks like (to use that example).

Human nature cannot be overcome with item #2, but it helps a lot.  There are lots of argumetns over what "we really want" but seldom over the value of time spent doing code behind the pretty pixels.

David Whatley
Thursday, February 14, 2002

I can’t agree more with Joel's idea about understanding the customer's domain.

I have worked with some programmers who care more about tinkering with new languages or creating the “best” abstract model but their eye's glaze over when you start talking about the customer's domain. Their code notoriously misses the mark for what the customer needs and ultimately cause some late nights of bug fixing.

A project’s success is directly proportional to how well the programmers understand the customer’s problem.

B. Reynolds
Thursday, February 14, 2002

If being a domain expert made for better software, I would spend much less time cussing at the software development tools I use.

While I have my own share of customer horror stories, I have come to realize that, for the most part, customers are good-hearted people.  We (software types) must share the responsiblitiy for miscommunicated requirements, desires, expectations, known bugs, schedule slips, etc.

Michael Gauland
Thursday, February 14, 2002

In "About Face: The Essentials of User Interface Design
", Alan Cooper goes as far to to suggest that UI prototypes use scanned handdrawings of text and images. If the client sees "real" GUI, they will assume that the product is almost complete and they will not want to make any suggestions for changes. If the client sees a messy handdrawing UI, they will (as Joel describes) think the software is still malleable.

Banana Fred
Thursday, February 14, 2002

I must say I’m surprised that someone as familiar with usability and its impact on UI design would take such a dismissive and contemptuous tone towards involving “customers”—i.e., the people you’re hoping will ultimately pay for this wonder app—in the design process. Certainly, you need to make everyone aware of the detailed behind-the-scenes work going on and its progress, but that’s because everyone has the correct priorities, not because your customers are clueless.

I would argue that customers DO know what they want: a usable, intuitive interface that does everything they need with a minimum of fuss. What bothers programmers is that the customers don’t know or care what’s involved in getting to that point. And yes, a well-designed UI can give the impression that the code is “almost ready”—but the solution is to explain the discrepancy, not hide the good UI designs from them.

If there’s one point that needs to be hammered into the skulls of developers, it’s this one: Customers don’t care about the hidden part of the iceberg—and there’s no reason they should.

That’s a tough realization for programmers who are always kvetching about how customers keep focusing on the interface and screen design—in your words, “We couldn’t get them to think about the actual functionality.” Well, duh; why should they? That’s YOUR job, not theirs. As far as customers are concerned, the interface and its design ARE the application. Period. Nothing else matters to them, and no amount of effort or complaining on your part will make them care about the features you’ve poured months of blood and sweat into.

And you know as well as I do that there’s a lot more to UI design than just “prettying up the pixels.” That remark bothered me, as did your implicit suggestion that customers should be kept out of the loop on design reviews. What makes you think the design is something you can fix up in a day (less than 1% of the work)?

Proper attention to design review and user/customer testing should make it clear that many interface problems go way beyond fonts and colors. Fixing these issues can involve substantial redesigns on every screen, or even rethinking the entire sequence of presentation from the ground up. It’s easy to develop and deliver “according to spec,” but a laundry list of features is NOT—repeat, NOT—the same as a well-designed application that will satisfy your customers. Still think you can “pretty up” the interface design with a day’s work at most? And do you still want to pretend that anyone will buy your brilliantly coded product if it’s presented with an awkward, hard-to-use design they hate?

I can’t tell you the number of times I’ve dealt with frustrated coders who complain “I delivered every single feature the customer wanted, and they still hated it. Obviously, customers don’t know what they want.” There is ignorance at work, all right, but it’s the programmer’s, not the customer’s. Delivering functional code that performs all the required functions is only PART of the developer’s job; turning that code into an interface that appeals and works well with the customer’s expectations and skills is the rest of it.

And despite your claims that this is “non-crucial, lipstick on the chicken stuff,” the fact is that coming up with a good, intuitive, USABLE interface design involves a lot more work and effort than just tossing some pretty pixels on the screen. If your customers discover they’ve hired “developers, not painters,” they might decide to take their business elsewhere—perhaps to someone who understands the central importance of the UI.

Here’s a rule for developers who truly want to understand how to deal with their customers and actually satisfy them (i.e., make money): The interface IS the application. No amount of complaining will change your customers’ minds about that, so you’d better get used to it and give UI design—yes, even the “pretty pixels” you sneer at, even in the earliest prototyping stages—the attention it deserves.

Brian Curtis
Thursday, February 14, 2002

accurate parallel with interior design there. i did home renos for a decade. the job was 90% psychology; learning how to read each client, learning just how much to involve them in and no more, learning what to surprise them with to make the job special for them.

one more thing: a home reno is always a traumatic invasion for the client. you're an invader in their life, no matter how invited. you have to learn to make a daily "visible difference" so they know where you are. when the electrician is wiring, do something the client can understand no matter how trivial, like getting tinted primer on half the walls. keeps the client calm. they need to be able to glance and see change.

owen
Thursday, February 14, 2002

It was agonizing.  I was the director of programming for a small start-up company and we had developed a Web-based application that was fairly easy to put together, but terrific in its appeal.  We put our customers through demos and they would start screaming (literally -- you had to be there) about how great this stuff was (no, I won't tell you because I hope to try this again).

I went to our Vice President and said "Okay, our betas are great.  People love what we're doing.  We've given demos in Oregon, Alaska and California and people are drooling over it.  We need to hire a graphic designer to make this professional."

He wouldn't, we didn't, and the virtually guaranteed VC money disappeared in a puff of smoke and the company died.  Oh, there were other problems, but we had a wonderful product, no competition and customers begging for the chance to use it outside of a demo.  It *should* have succeeded, but it was butt-ugly.  There's no other way to put it.  I was embarrassed to show my friends any of what I was working on because it was so ugly.  Our Web site was so ridiculously amateurish that no one would have even remotely considered giving us a penny.  I'm glad Joel finally put a name to this mess.

Curtis "Ovid" Poe
Thursday, February 14, 2002

Another one bang on, Joel.  Totally agree about the extreme comment as well.  I do dig XP and was an early adopter, but only certain parts of it.

I've never provided mockups using actual computer screen shots for the very reason of one thing: font.  I can't stand spending 2 hours during a meeting discussing what the best font is.

Hand drawings are the way to go.  And never really thought about it, but you are right about the fact that this prevents people from thinking the project is completed as well.

Gary Baanstra
Thursday, February 14, 2002

Actually our kitchen designer did discuss dishwasher placement with us, although only to ask which side of the sink it should go on.

Andrew Simmons
Thursday, February 14, 2002

There are kernels of truth in here, but pardon if I step on my soapbox for a minute. A representative paragraph from the first half of the article (which is probably not where he makes his main point, but which promotes some ideas I’d like to put to rest):

Assume that your customers don't know what they want. Design it yourself, based on your understanding of the domain. If you need to spend some time learning about the domain or if you need a domain expert to help you, that's fine, but the design of the software is your job. If you do your domain homework and create a good UI, the customer will be pleased.

The kernel of truth is that customers don’t know exactly what they want and that they are not software designers. You should not take what they say about technology and design at face value. Absolutely. But on another level customers know EXACTLY what they want. They want their work to get accomplished and they know their work far better than you or I. It would be a fatal mistake to assume that you have little to learn from customers just because you can’t trust what they say about design & technology. Watching them work and asking them about their WORK (not the technology) should be an important part of our design process—even if we think we understand the domain.

Ted Boren
Thursday, February 14, 2002

A related lesson, learned from several client meetings:
I didn't use "Lorem Ipsum" latin filler text in mockups or prototypes shown to customers until a few meetings went like this:

Me: So, here's what the proposed home page will look like, and you just simply click on the discussion ar...

Client: What's that paragraph say about healthcare funding getting slashed?

Me: What? Oh, that. I just copy and pasted the first story on Yahoo News' medical news page, I thought it'd fit as filler text since this was a medical site. Now about the functionality of the featur...

Client: Well, can we change that? I mean, I don't want to look at bad news when visitors see the site.

Me: I just put that in for this photoshop mockup, it won't ever be seen by anyone. Now about the new proposed sub-sectio...

Client: Ok, but if you could change all the mockups, that'd be great, I don't want to show these around the office with that bad news on there.

I've used Lorem Ipsum as filler text from then on.

Matthew Haughey
Thursday, February 14, 2002

What customers want is tricky on two fronts, and I think it's too glib to say, "become an expert in the domain".  Lots of big software projects are intended to serve more than one audience, and it's almost impossible to become expert enough in all the relevant domains.

I used to work in libraries, and one of the interesting things that happened there was the appearance of graphical clients.  The graphical clients were wonderful to use in some ways.  They presented lots of information on the screen -- far more than what you'd get on an old green-screen terminal.  And they looked great.  Very nice for showing to library patrons.  (Oops.  We call them "customers" now.  Sigh.)

Anyway, one problem with these systems was that they were clearly the result of lots of consultation, usability studies, and (most importantly) expert librarians working inside the development houses.  Because nobody thought about what it would really cost to put down 200 Windows machines (as a replacement for 200 dumb terminals, which are about $10 a pop these days), the library vendors were suddenly faced with great resistance to their products.  The conflicting demands -- a pretty, easy-to-use interface and easy maintenance -- got overlooked, because nobody asked.  Every library type I ever talked to about the question was looking for some kludgey way around the demise of dumb terminals -- Citrix, annual PC leases, whatever.  But it was obvious that nobody had ever asked the customers what they might want.

It seems, then, that you need to be careful which expertise you have.  Joel's remarks about "hallway usability testing" are the right ones here, of course; you just need to make sure you pick the right hallway.

Acowymous Nonerd
Thursday, February 14, 2002

What if, even though interface design makes up only 10% of the hours in a project, the program actually *is* 90% worse if the user interface is bad? Should the amount of time spent on different areas of a project have anything to do with its actual importance in the final project?

Good design can determine whether a totally functional program *gets used* by its users. You can have the coolest, most innovative, interesting program out there, but if you don't give necessary thought to the placement of the tools, design of the representative icons, consistency of the overall interface, people will not use your program.

My conclusion is not so different than yours: that it is extremely important to design a good user interface. The difference lies in the typical programmer's reaction to design. You appear to be saying (and I have heard repeatedly from programmers) that design simply adds a pretty face to the actual important part of the project and must be accepted, begrudgingly, as necessary to get the dimwitted clients to be happy with their end product.

Remove the clients from the equation in your theory and design becomes completely irrelevant and unnecessary. I think this is actually what happens often in the Open Source movement. Quite often, user interface isn't thought about, layout of the program features is haphazard, and the program is not nearly as usable as a closed source (Microsoft/Adobe/etc.) program it may be surpassing in features.

Until programmers learn to value design, designers have to count on those dimwitted clients to support their time spent making the functionality of a project usable.

Dave Rutledge
Thursday, February 14, 2002

We are still in a period when IT and the Web are often seen by clients as being magic wands in business. Connecting a software project to clear client objectives with explicit metrics for success is very important. If you can't do this, maybe the project shouldn't go ahead. If you can you have an objective basis for evaluating solutions.

Clients _can_ learn about software programming and about UI design. But we need to manage their expectations about what we are presenting them. We should certainly be presenting UI design solutions in a variety of forms – including pencil sketches, interaction maps, wireframes, rough interactive mockups, treatments for design elements, and so on – but we need to make clear what we were are presenting, why we are presenting it in that form, and what we want them to react to.

The shock treatment for clients who are stuck on a design idea or solution you don't think will work is to usability test it. Clients, even more than designers, are often dumb-founded when they see their product in use by intended users in a real context.

I agree with (most of) the contributions from Albert D. Kallal, Beth Linker, Evan Owens, Peter Lovatt, Bill Benko, Anca Mosoiu, B. Reynolds, Banana Fred, Brian Curtis and Ted Boren.

Nico Macdonald
Thursday, February 14, 2002

Well, I think Joel has some good points regarding how to show project progress.  On some other issues I do not agree.

Here are some of my points of disagrements.

1. Customers DO KNOW WHAT THEY WANT.  They want a solution to their problem. They might not know HOW to arrive at a solution, so they hire You to provide a solution.  This brings me to point #2.

2. You do not do not have to assume you need to build anything because the solution MIGHT NOT INVOLVE SOFTWARE!!!  Maybe it does, maybe it does not... You as a consultant should be able to point this out to the customer (and you should be compensated for pointing this out). If you then determine that the solution does involve software you can then "figure out a design that solves the problem that the customer has in a pleasing way."

3. The only one with domain knowledge might be the customer.  So you will have to work with the customer anyway, to gather requirements and to better understand his problem.

Paul B.
Thursday, February 14, 2002

Okay, I found a few people mention the REAL problem here: It's your cohorts who will sink you.  As one person mentioned:

<blockquote>
It doesn't seem to ever be accounted for that he's selling things for less than they cost to make. That's engineering's "fault" for not being able to make arbitrary projects arbitrarily cheap.
</blockquote>

I would complain that they were "selling dimes for nickels".  We techs would have to spend lots of overtime at NO EXTRA PAY to get done what had not been properly discovered.

Of course the customer doesn't know EXACTLY what they want. This requires the "discovery" phase.  But as I mention above, your cohorts will have no clue about this and they'll mistake pizza over lunch with the client as having determine the requirements and they'll pass you the napkin and give you the deadline. Seriously.  Time and time again I've seen people mistake their limitations for someone else's domain. "Gee ... if we can't think of it, it must be for the tech people".

Don't blame the customer. Go through your discovery. Think. Brainstorm, model. Create a model, as architects are known to do.  EXPECT lots of changes during this period. 

The problem is not the customer. The problem is with people who try to sell a town-house at a trailer-home price. The problem is with people who think a napkin with scribbles is all the documentation the "tech" people need. The problem is with people who should not be invovled in software development as they have no clue.

Peter J. Schoenster
Thursday, February 14, 2002

It's sad to think we're all aspiring hairdressers. By the way, where is that can of mousse, Derek?

Nick Bauman
Thursday, February 14, 2002

I agree, Peter.  Of course developers need to explore what is needed with the customer so that both parties get a clearer picture. 

With regard to the UI, this is where techniques such as Larry Constantine's Usage-Centered Design (essential use cases and abstract prototyping in particular) are useful.  In my opinion, showing a pretty prototype without doing any modelling first is short-sighted and is likely to lead to focusing on the appearance of the UI rather than what the customer needs the software to do for them.  Using abstract prototypes avoids the misconception that there can't be much more effort in getting the system to work.

Keith Pitty
Thursday, February 14, 2002

I ran into this exact problem on two projects back-to-back before coming to a solution. In the third project we mocked up the program in pencil drawings only. They were latter scanned in and stored as part of the design documents.

In all those design reviews no one ever asked about fonts, colors, button sizes, etc. Since we were working with pencil drawings it was 'obvious' to all the marketing folks that those things were still malleable and instead they focused on the 'flow' of the program.

We were also very careful in the phasing of the development. While doing the up front design work with the pencil and paper design with the marketing people the software engineers were working on a the guts of the program in command-line driven form. No GUI. Only after the UI design settled down and the core was starting to gel did we (intentionally slowly) start to put a GUI on the program.

Joe Gregorio
Thursday, February 14, 2002

Hey!! I have a Callaway driver and it's perfectly legal (and I hit it a mile!!) :)

Everything is so true... I once made two mistakes: not having a perfect design before starting development, partly because the customer didn't exactly (at all) know what he wanted... A month and a half project took about 13 months...

And similarly, that same customer when he saw a nice UI thought that it was almost finished, while I really had about 20% complete...

Well, with each project you get to learn something always!!

Keep up the good work!

  -- LuisR

Luis Alonso Ramos
Thursday, February 14, 2002

Pat,

The banning steel spikes are the golf course owners.  This is because they damage the greens, the fairways, macadam, bridges and carts.   

the PGA has no opinion on this. 

BTW...have you seen the pics of golfers in the early part of the century...  1" spikes!!!    they look like tree climbers...

Greg Davis
Friday, February 15, 2002

Life is not so simple.

Some customers know precisely, exactly what they want.
Most dont give a F*** about the 90% of the iceberg, but
if your 90% compromises the 10% then you'll get to know all about it.

Your ability to know who is who is all that matters.

Tony
Friday, February 15, 2002

Thank you for another set of insights into the hard facts of a SW developer's life.

One should not be surprised though with the behaviour of the non-tech customer.

Marshall McLuhan ("the medium is the message") and Alan Kay ("the user interface is the program") certainly wouldn't.

Keep up the good work, Joel

Rui Costa
Friday, February 15, 2002

Danger of prototyping. I have been in situations where the customers expect you to convert a VB/Powerbuilder prototype into a web based (html) product and have the same response time and the cool widgets that a heavy client can provide. In one case, the customer had an existing thick client application which they wanted to 'webify' and expected every little cool feature available on the client with the same response times and usability.

R. Sriram
Friday, February 15, 2002

I agree totally about the necessity for designers and programmers to be in the domain. If they are not it  inevitably leads to the customer providing a long list of changes that should have been features from the outset. In my experience the more people involved the higher the chance that the software will suffer in this way.

A Fernandez
Friday, February 15, 2002

One more minor thought: not all domain experts are created equal. If the project doesn't have strong buy-in from management in the domain, you may get Joe, who's a heck of a nice guy, but who was only hired six months ago and doesn't know how things work yet. "We can spare Joe," goes the thinking. Unfortunately Joe's answers tend to be "Hm, I guess it should work this way." You can end up with a false sense of security based on expertise that isn't.

But in the best of projects, I think having a domain expert beats trying to become an expert yourself. You need to know enough about widgets to get the widget production process steps in the right order on your process control interface. But you need someone else who *really* knows about widgets to tell you all the things that can go wrong with the process that you need to account for. If you spend the time to develop that level of expertise, you'll never get any software written.

Mike Gunderloy
Friday, February 15, 2002

Curse the Delta Inflight magazine! Curse them!

Steven Garrity
Friday, February 15, 2002

It seems to me that a few people on this thread are Taking the article out of context.  They think they are arguing with Joel when they are agreeing with everything Joel has said about a 'Usable' interface in his book.

http://www.joelonsoftware.com/navLinks/fog0000000247.html

The article is specifically talking about a 'Pretty' interface.

Now a pretty interface and a useable interface don't always conincide.

Take for example data input.  If a data input clerk is going to input several hundred tickets a day, then they may be better served by a purely text based interface, which can be operated from just the keyboard.  If a field has 5 or 7 options, then the clerk memorises 5 or seven single letter codes, no problem.

Now a lot of these mainframe input pages have been given a web frount end.  The Browser is much less responsive than the old text screen.  Instead of a single letter code to remember there is  a drop down with the options, and 2 of them begin with the same letter.

The interface is much preetier, but for the clerk who has a quote to meet, it is much less usable.

Ged Byrne
Friday, February 15, 2002

This reminds me of a story I heard once that shows that these sorts of issues, and solutions, have been around a *long* time.

Apparently there was a painter during the Renaissance who did a lot of portrait for the nobility.  He'd do a beautiful painting and they'd always find something wrong with it.  So he'd have to do it over. Of course, being nobility, they didn't have to pay for doing it over.  They'd tell him he was luck to keep his head - at least we don't have to worry about *that* so much today.

Then he got smart.  He'd put a big ugly hair on their arm.  They'd of course spot it right away, he'd fix and, then they'd be happy.

In my group we call this the 'hairy arm' and it works to great effect.  If you know the customer is looking for something to make themselves look important (and they always are) given them something obvious and simple.  They get a chance to show off how smart they are and you get them out of the way quickly.

Tom Haviland
Friday, February 15, 2002

Right on target. An analogy for those who speak more then one (human) language:

- A person who masters a foreign language but has a stron aaksent is perceived as non-fluent.

- A person who has a perfect pronunciation but has only a limited vocabulary is perceived as being much further along in learning the language.

Peter Thoeny
Friday, February 15, 2002

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

* * *

Perhaps this is the reason why a project that's "95% done" ends up taking another six months (or longer) to finish...

You want to know the real secret? You want something that you can actually leverage into a successful project, instead of something that allows you to rationalize your failures?

TRUST. You're almost guaranteed failure without it, and success with it. Build it. Earn it. Work your ass off for it. Everything else falls by the wayside if you have earned your customer's trust.

Robert K. Brown
Saturday, February 16, 2002

Customers.......makes you want to go the speculative route. But after the  "webs_highest_and_best_use_is_a_retail_channel.com" meltdown, more talented people are chasing "secure" jobs with companies that already have Customers.

The best opportuinites are in building what people need, not what they want. In other words...people don't know what they need. They only know that what they have is not what they want.

To the extent that communication is the problem,  the MBA cirriculum a very easy to learn ( despite what the b-schools and their alumni whould have us all believe ). The concepts are  easy and the math is simple. LEARN IT.

To the extent that "the UI is the application". It is. That's most people's reality. When in Rome....

Thanks Joel

Dan Sickles
Sunday, February 17, 2002

Best article I ever read on the subject!!!
Keep up the great work

Alessandro Federici
Monday, February 18, 2002

Joel, I think you practice too closely the 80/20 rule of usability when analyzing complex problems like the developer-customer relationship.  You try and and blanket the %20 of difficult problems with an %80 solution analysis.  This is only a B- solution. 

In the case of the customer relationship, I do not interpret XP as stating that one "gets customer in the room and involve them in the design process every the way." 

To give substance to your kitchen analogy, I am currently hiring someone to redo my kitchen, because my current kitchen sucks.  Of course I don't want my developer to present every design decision to me piecemeal.  I want them to distill the important decisions and interact with me to deliver me what I want.

For the kitchen analogy, I would expect them to read up on what is a "WorkTriangle" and let me decide what I want my "WorkTriangle to be.  See: http://www.budgetkitchencabinets.com/worktriangle.shtml

If they screw up and don't deliver me what I need for my specific usability needs, then I will hate them.  If I make a bad decision on a crucial usability need, then I will probably ignore it or even have them fix it at extra cost to myself.

XP holds that the developer interacts with the customer on crucial design decisions that the developer cannot know, not that the developer asks the customer to design everything.

Tim Burns
Monday, February 18, 2002

I agree completely with you that customers don't know what they want but I would like to be a little more precise.

Software is built to solve problems, to fulfill needs.  Customers know some of the needs they want to fulfill but they may not know all of them. 

When customers talk about their needs, I listen to them but I also keep in mind that there may be other needs that they are not conscious of that I need to find out. 

When customers talk to me about software solutions they envision, I don't listen to what they are saying, I ask them questions to find the underlying need they are trying to solve with their proposed solution.

So as consultant, we have to listen to what they say but differentiate if what they are saying is information about a need or information about a solution.  They rarely can help us with solutions because they don't have the expertise in that.  They have an expertise in their domain.

This makes me think of my grandmother.  She would be hurting somewhere and she would go see the doctor and she would tell the doctor that she had some kind of illness she heard about on TV.  The doctor would make her feel that he was listening to her when he would be really making his own mind about her condition.  He would really listen to her though when she would tell him where she hurt but not about when she was talking about diagnostics.

Pierre Roberge
User Experience consultant

Pierre Roberge
Monday, February 18, 2002

Joel,

Thank you so much.  I thought my former non-tech boss was an idiot.  He wanted us to add the ability to save the work done in a multi-paged web form so the user could return at their leisure.  I kid you not, he said, and I quote "It isn't that hard, you only add a button to each page."  I still can't figure out why that company went under :-/

Stephen

Stephen
Monday, February 18, 2002

Oh dear Gods...

I work in a webdesign company, doing simple little database driven sites - most clients have been fine, most jobs have been fine, but one particular client...
$#&@(*#&@!!!

First off,
they were completely Secret Squirrel about it, and wouldn't tell us what they wanted, until we signed a confidentiality agreement saying we wouldn't 'steal' their idea etc.
Trust me, there was nothing novel at all.

Second,
they were *still* 'Secret Squirrel' about it, only said what they wanted in dribs and drabs. And what they *originally* wanted was pretty simple.

Except they continually changed their mind.
The more they learnt, the more they changed their mind.

For example, even on simple, html, text pages, they submitted at least *5* lots of text changes to each page (rephrasing things etc). I don't mean 5 changes to each page, I mean they revised the page. Then revised it again. Then again, then again, then again.

Once they did learn a bit more, they asked that we do things in a really shoddy way.
Eg, their users *think* they are getting a unique password - but they're not.
They all get the same email, with the same username, and password.
Also, it was a website and they initially didn't want to pay for *any* design).

It took months, for something that in functionality (if I was to do it *right* - eg unique passwords!!!) should have only taken weeks...
And basically, I feel ashamed of it. Embarrassed that I did such a cruddy job.
AND I tense up whenever I hear the clients name - although whenever a client sounds like they might be a bit difficult, we refer to it as a <the client's name> job.

So, argh!
I'm hoping this is an extreme example...
And point being, some clients are not worth it.
And point two, just say No!
Be assertive, nail them down on what they want, and tell them once signed off, that they only get a certain amount of changes, and sign THEM off, and tell them if they don't like how you do it, go with someone else.
You'll sleep better.
Really you will.

Grail
Tuesday, February 19, 2002

I think the statement "Customers don't know what they want" is dangerous and leads to a lot of bad attitudes among programmers. On this board, I already see the meaning being misinterpreted to say "Customers don't know how to program so I'll just tell them what they want."

In reality, customers have a pretty good idea what they want. That's why they came up with the cash. They don't know whether Widget A should go here or there, and they don't know which algorithm is the best choice for your sort routine. What they DO know is that they have a need that can be met by your services. ALWAYS be afraid if the customer starts by showing you the user interface they came up with and says "You can take it from here". Now you're looking at their idea and making tons of assumptions about what they are really trying to do.

The customer is simply limited by their experience and their (assumedly) limited knowledge in your domain. I always find it best to talk strictly in terms of the customer's domain. What are the problems with the current process? What can you not do now that would be valuable to you? What is keeping you from focusing on higher level problems?

Keeping the customer thinking about these issues will lead you to the REAL requirements. If you can do that, and you have a really good UI designer on your team, you shouldn't ever need to prototype (except to show progress) or get bogged down in "I prefer teal over powder blue buttons" crap.

Jason Wood
Wednesday, February 20, 2002

What I hate about this scenario is that it leads me to be
a two faced bugger. Just yesterday when discussing a ui
design where I had 2 versions in the presence of only a
technical cohort I said "What am I an interior designer?
I don't give a crap." Requisite Yuck Yuck Yuck.........
Of course once the rest of the interested and decidedly
non-technical types arrived the decision took on the
tone of nuclear physics. I feel soiled!

hockeypuck
Thursday, February 21, 2002

Chock full of good recommendations, as usual, but you have a couple of pitfalls in here.  Once a long time ago, I worked on a rather technical program that involved a lot of UNIX system programming and a GUI to control it.  Realizing the system programming was the interesting part and the GUI would be dull, I got the cool system programming part done first.  Totally, completely done.  The product was usable and shippable from the command line, and the GUI was only going to drive the command line and perhaps edit the configuration file.

So far, so good.  All we have to do is implement a rather simple GUI in a few months and we look like heros.  We were commanded from above to use the Galaxy cross platform GUI toolkit, because the company was making a big investment in Galaxy.  OK, we drag out the Galaxy doco and install tapes, crank up a couple of their simple examples, and start hacking.  The requirements list, still on a whiteboard, immediately starts growing. 

"This dialog is too big."

"We need tabs like Word has."

"It needs to be more colorful."

Never mind that this is an idle terminal monitor, not a word processor, and that most of the customers were using monochrome X terminals.  Yup, VP driven design at it's very worst.  So what do you do?

As many engineers would, I completely lost respect for Mr. VP Bozo, tried to work his mostly but not entirely idiotic requests into a workable design the users would still be able to use, and eventually got fired for not working 24x7 on his pet project.  It turned out fine, I landed a better job THE NEXT DAY, but it taught me the first rule of being a software engineer:

1.  Pathological development organizations happen.  Some remain pathological for decades, others start out great and decline over time.  Don't support them.  If you can't change them, leave them as soon as you can.

Getting fired is not the ideal way to deny your services to a pathological development group; I heartily recommend finding a better job first.  When you leave, remember the advice my father gave me:  "The best revenge is to just live better."  Don't gloat and don't pout, just move on and be happy.

The "change it if you can" part?  The way to do that is to become the guy in charge.  The job I moved on to had the title "Manager of Research and Development", and I made it a pretty good place to work for about 9 months.  Then the owner returned and turned the R&D department back into his "code typing" pool, I quite, and the poor 28 year old kid who was stupid enough to push me out and step into my place had a heart attack the next year.

The moral of this story is I'm still living better, and I don't really care if they are or not; they're no longer my concern.

Wes Peters
Monday, February 25, 2002

I despise the theory of customers as automatic idiots. The theory of programmers who are as powerful as real domain experts is simple programmer hubris. A programmer might specialize in a domain or more, but unless one really is expert, don't pretend.

Don't expect customers to be skilled in information development or systems thinking. These are developer skills (and not super powers) which aid in defining a project's scope and content. 

Interestingly, Extreme Programming addresses all of Joel's criticisms. E.g., when the customer representative is a dummy, XP predicts you will get bad results (Extreme Programming Explained even cites some scenarios).  XP suggests walking away from pointless situations. When programmers are inexperienced, XP predicts difficulty, etc. When a user makes a technical decision, XP suggests an informed, grounded, risk-assessed approach. Should the need arise, the customer decision may be overidden by actual requirement.

This is pretty basic and obvious, and has little to do with the value of XP. The value of XP has to do with ditching irrelevant concerns and focusing on the expected result, via discernable methods. XP suggests various approaches to define and measure important metrics which provide actually useful feedback for project management. For example, getting anything done is measured by completion of user stories.

Joel, I think this column is way off. Your criticisms of XP are unfounded. As for the iceberg theory, I hope you were being sarcastic.

John Owen
Wednesday, February 27, 2002

Joel is right on the money. I call it the "jazz factor". This is where the software doesn't provide much but it looks great. That's what hooks those bastards everytime, wether it's a demo of a prototype or the real thing.

I have been programming for 15 years and have seen it happen on almost every project with many different companies in varying degrees, but nonetheless, it is prevalent.

The trick is to know how to use this to your advantage.

Paul Speranza
Monday, March 04, 2002

The Pain....

I recently spent 6-8 months re-engineering/re-designing a
business graphing package (Which was a complete mess
implementation wise and display wise)

During the unit test phase I made a GRAVE mistake...
I demo'd the product !!!
(I was asked last minute by the big cheese! to do so) so customers, fellow developers everybody was there!

Keep in mind

-ALL existing functionality had been re-implemented
The UI compeletely re-done with input from the customers.
management, marketing and every other SOB with an opinion!

At first they gasped at how beautiful it looked - very complimentary and very impressed... I was in heaven
baby - I HAD EM GOIN!!!!!!

THEN...about an hour into the demo
somebody noticed a text label displaying in the wrong
Font!
This graph label was too small compared to other labels on the screen - during the next 2 hours all of a sudden everyone and his brother was crying about these labels (we are talking text on the axis of the graphs about 5-6  to be exact!)
2 months after that demo - all people whined about were the F$^%$^ Fonts...

NEVER mind the product "worked",
NEVER mind it was a zillion times improvement over the previous release -
NEVER mind it was even ON SCHEDULE

Fonts on text labels.....
I guess bigger men have fallen for less!

Lesson: 1

You can have a  MATURE Software development process -
You can have excellent graphical designers,
Excellent this and excellent that...
Mature developers, Design reviews,
marketing analysis etc...
BLAH BLAH BLAH

BUT... Whatever you do....Get a psychologist or a good
salesman in the room with you when you demo your product = MANAGE product perception when people start to whine ....Nip it in the Bud FAST

When we left the demo room...we LOST the perception game!

Honest to god - the text labels were the LAST thing on earth  I would have thought people would whine about
(I personally was worried about performance re-sizing the graphs etc...) NOPE they never mentioned it


People..."Customers" NOT CODE, not technical brilliance, NOT fancy software....people = master how to keep them happy - What the software does/ how it does - doesnt matter!!!

Perception 101 - I'm sorry I took compiler class and missed this one!!!

Keep up the good work JOEL!!!!

Cfont run, cFont whine, cfont go to unemployment line!
Friday, March 08, 2002

I found this article to be fairly accurate re what clients want but I have to grizzle about Joel's Important Corollary Four (obviously written by a software designer)...It makes me cringe to think that he recommends 'several different graphic design versions' for the client to choose from..even worse..muck around with.

Just as the software designers become fed up with clients not knowing what they want so do GD's. It's our (graphic designers') job to determine what the clients visual/communication problem is and solve it for them. That's not to say that we shouldn't go away and construct as many versions as we feel appropriate until we've found 'the one'. The issue with giving the client extra options is that they invariably will try to pull out the 'mexican tiles' from one design and stick them with the 'Norwegian wood block' from another design..if you're lucky it might work but most often it doesn't. The client ends up with a bodgey job (because they don't know any better) and the designer ends up with a job they'd rather forget about than be proud of.

Perhaps design is only the top 10% - 5% - 1% of the iceberg...but even in this article it stresses how the importance and value of design (in the client/customer minds) stretches way beyond this amount. Isn't it worth it then to get it right and have it constructed by design professionals — not clients who play with designs because it has more novelty than getting on with their own job?

Just as there's a difference between software designers and cousin Jeff building a webpage - there's a difference between 'decorators' and 'designers'.

Joel...would you build four different versions of a product and then let the client loose to copy and paste code as they please?

Audra Willcocks
Tuesday, June 11, 2002

"Expect that the marketing person in charge of the project will take that diagram and use it to explain to THEIR bosses why a multi-threaded application is needed."

For some perverse reason, older people who did not grow up with PCs in their homes and on their desktops as part of the furniture, no more mysterious than telephones and electric lights, feel that they need to worry about the details of implementation. This reflex must be opposed. What doctor explains to the patient how the prescribed antibiotic actually works? This is not their domain to manage, with the possible exception of hiring someone from outside to develop an application which will be maintained internally. And even then, the worker bees should be involved at that level.

Discussion should primarily be limited to business results. To abuse the iceberg analogy: "We need a large hunk of ice, floating in this water. It should be able to last n months before completely melting. And, if a giant, unsinkable ship hits it, the iceberg should win". I am not about to explain the quantum mechanics of heat, temperature, and state change to them. If that's what they expect, they are talking to someone they apparently do not trust enough, because they feel like they have to second guess that someone.

Subject Matter Experts (SMEs) are out there. If necessary, they can be hired on to the project. It is certainly possible for we who are technical to intimately understand and even achieve certification in the business that we support. Tragically, that happens only slightly more often than conversation with technically informed business folk. Both should be sought out, and encouraged.

Greg Stigers
Friday, August 23, 2002

The one problem stated over an over here, is getting the user to commit to a design early in the development process.  The best way I have found to do this is to MAKE them.

I do this buy requiring written signoff of design documents.  All the way through the development lifecycle.  This is especially important if you are working on a fixed budget contract.  Make the user signs on that initial Project Plan document.  Make them signoff on each form design before you start development.  Make them signoff that you delivered everything in the design doc once the form is finished.

Customers do not take design documents serious.  But they do take their signature seriously.  I have never had a customer signoff on any design document without understanding exactly what they were agreeing to.  Once you have the signature, the customer can’t claim that they did not get what they wanted.

Do this and you will have no problems when it comes to the final system signoff.  Just make sure you have the right person doing the signing.

This process has two purposes.  The first is to cover you r butt.  But the second is the most important.  It forces the user to take the design phase seriously and to put forth the necessary effort early in the project development lifecycle.

John Olson - Project Leader - Madison, WI
Thursday, October 03, 2002

This article raises some good points about UI, but misses some important ones too.

Of course a product UI should look good. Would you buy a new car with a crummy, peeling paint job and cracks all over the dashboard?  How about a tangerine interior with a lime green exterior?  Let's face it, software is FINALLY becoming a mature product category.  Raw functionality and power are no longer the only thing that users lust after. Aesthetics are just another design factor that needs to be factored into customer purchasing criteria.

And I think it's also pretty clear that when doing the dog & pony show, you're in a sales situation. Common sense dictates that this is an area where you want to put your best foot forward as a company or development group.

But there is MUCH more to UI than just pretty pixels.

UI architecture concerns itself not only with with how on-screen information looks (this is usually the last thing to be considered anyway), but also how this information can best be structured to fit into or streamline existing workflow, address cognitive limitations and abilities, and to empower users to work more efficiently and effectively.

In trying to address these issues, UI Architecture answers many of the following questions:  What are the objects that users will see on screen? What are their properties? How are they created? What are their relationships to other objects in the system? How do users build a conceptual model of a complex information space? What are the focal points of interaction for a product?  Etc...

The thing is that if you mess up the important issues in the UI, you end up with problems like:

1. High error rates on key product tasks
2. Lengthy training times to learn the product
3. Higher numbers of support calls
4. More difficult sales cycles (because convoluted object models and flows make for confusing sales demos).
5. Difficulty of installation, maintenance, administration, etc...

I agree with Joel that having users involved with every detail is overkill. It's better to start your project with a thorough analysis of users and usage contexts so you have a good idea of how, where, and by whom your product will be used. Once you've got some design concepts together, you should build prototypes and put these in front of potential users to validate the organization and structure, functional behavior, and task flows. This can be repeated at key points in the development cycle--and should even be done using alpha and beta code bases to flush out remaining issues.

Personally, I've always liked the metaphor of UI as a cake. If the icing looks great, but the bread tastes like shit, people may give it a try, but no one is going to want to eat it.  Conversely, you could make a great tasting batter, but if you decorate the cake to look like vomit and dirt (sorry for the grotesque analogy), some brave soles may try it, but most will be scared off.  A great bread and beautiful decoration support one another to provide a satifying, multi-sensorial user experience.

The same should be true of software, where the UI, and the engine support people in their tasks simply and efficiently.

liam friedland
Sunday, December 08, 2002

The problem, I believe, is not what the secret of the iceberg is – but of how you let your programming team realize the importance of this secret and its corollaries. As a “non-technical” manager who sincerely appreciates what the technical team does – it has been an uphill task asking the team to give me a good-looking product which I can use to tackle the customers and the senior management team.

I couldn’t agree more on the need for a common language between the programmer and the MBA.

Thank you very much for the interesting and informative articles.

Atul Sabnis
Tuesday, April 15, 2003

http://guir.berkeley.edu/projects/denim/

might be a useful way to address the prototype-quality-match issue; it lets you do "scribbled" prototypes of structured web sites fairly easily.  I'd also seen the effect in SketchUp:

http://www.sketchup.com/

which is a rapid-prototyping 3d cad system, very easy to "sketch" in 3d - but the key thing is that there's a "roughing" mode that turns the crisp straight lines into more pencil-like strokes, and adds overshoot and such to make the 3d look more hand drawn - they claim that people are more willing to treat a "fuzzy" 3d sketch as malleable, which is a related concept (from "real" architecture vs. software architecture.)

Mark Eichin
Friday, May 16, 2003

everyone is searching for a treasure.

joel says that he knows a secret

what will the secret be?

his secret is this: no one knows where the treasure is

lurmit
Tuesday, May 20, 2003


I sooo want to work for Joel.

Sigh
Friday, May 23, 2003

---
Mostly the problem is that the technical people are the /LAST/ people that ever get involved in projects, because they're very, very busy finishing off the last late, overbudget project...
---

In our particular case, it's the 'our company can do yada yada yada' chest pounding routine. Of course, I or anybody else responsible for implementation is never around.

Cheers,
BDKR

BDKR
Friday, May 23, 2003

Good article as usual.

One thing I have learnt; If you are doing a graphic design for something like a website in Photoshop/Fireworks then be careful with the font/text areas.

When a client sees a lovingly kerned, antialised and DTP quality text area in Photoshop they expect it too look like that on the end-website in IE, Mozilla, whatever and across all platforms. It is very hard at that point to explain to them that "That was Photoshop, this is the web, it just can't do that."

So stick to web fonts, stick to web font sizes, switch off antialiasing and stick to letter and line spacing that can be matched on the web.

Paul Watson
Saturday, May 24, 2003

Joel:  your article kicked a33.  It's about time someone wrote it. 

A Few  things though (not criticisms)....

1)  Many IT bosses think the same way b/c they think like someone that looks at the product but doesn't use it.  Unless a techinical person uses the stuff, they are likely to be caught up on the GUI.
2) You can't get away with a Lame UI.  Period.  Like it or not, the most killer app in the world won't sell crap if it's command line.  See Linux ---- Or even better Unix.  Although I'm a C# and Pocket PC developer, my first love is Berkley Unix.  And it sucks that MS had to be the ones that let me write stuff people as valuable (even though a LOT/MOST of really important stuff has a lame UI b/c 3:33t K0drs can work from a command line).

3)  This is the part that hurts... But no matter how kill3r your app is, it only matters if people use it.  And if people use it, if they like it.  Killer Apps, by default, mean the USERS-NOT THE DEVELOPERS, dig the app.  However, they have this neat thing the marketing clowns always forget about----USERS LOVE THEM B/C THEY LOOK COOL, ARE EASY TO USE, AND THEY WORK!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

So the simple solution is to have Castro Style Executions of Marketing people and IT Managers, and let the Customers and the Programmers determine/build what a killer app really is.

William Ryan
Monday, June 02, 2003

Loved the article.

Customers may not know what they want but they sure as hell know what they don't want.  Chances are that it is what they just took delivery of.

We use your "lipstick on chicken" approach for design, but also give the customer wire frames to describe positioning and functionality.  This shifts the emphasis back in the functionality side of the court.

Personnaly I have found that face to face meetings with customers keep up the rapport and let you do the self promotion thing.  It also gives you feed back on how the customer perceives the project to be going.  This is an early warning system.

If I was presenting to a CEO then yes I would show him the pretty pictures.  The last one would be of a big iceberg with the top 10% labelled "what you have just seen" and 90% labelled "to do".

Dave Poole
Wednesday, June 04, 2003

Some people referred to "[User] Tasks".  Years ago, these would have been called "Business Processes".

"Users know what they want to do - not how they want to do it" -- That was once "Business Requirements".

"Translation between customerese and programmerese" -- Once there were "Systems Analysts" who talked to (more importantaly listened to) customers and then wrote things down that developers could understand.  Some peoples postings indicate they are doing this.

It seems to me we are rediscovering (or need to rediscover) many old principles.  They tend to be cloaked in new terminology that make them needlessly obscure.

OK, the technology changes, we know that.  But before the technology, you have two people trying to COMMUNICATE from vastly different perspectives -- that has not changed since Babbage tried to explain how cool his Difference Engine was.

I think "Systems Analysts" got a bad name when they had a whole waterfall phase to themselves and probably didnt understand the target technology.  Often they took a long time to come up with descriptions that didnt really satisfy either customers or developers.  So the industry got rid of them.  For a while it seemed we were all "developers", then "programmers".  Now we have Interaction Designers and "User Experience Consultant" (thats getting a bit rich) - sounds to me like these are doing the same thing that the GOOD Analysts (admittedly a minority) used to do.

If you take the attitude that your customer is a moron, you wont communicate(2-way) well.  Your best chance of communicating between your vasly different perspectives, is to respect your customer's perspective and knowledge, and ask that they respect yours.

All right they can sometimes be distracted by computings equivalent of shiny beads, and I thought the ideas on limiting those distractions or even using it to aid communication, were very good.  But dont go too far - "Design it yourself, based on your understanding of the domain" sounds like a bus driver who likes driving but hates passengers.  If you want to develop systems for yourself, fine, do it at home, but our customers are paying* us to develop systems for them.    (*or we want customers to buy the product)

Clay G.
Thursday, June 05, 2003

Absolutely fascinating,

I have been reading up on this website, for about 14 hours, I am a user dissatisfied with what I get, and want to 'build' for myself, I have learnt so much about the background for coding and so many pitfalls have been exposed so far, I am a far wiser person, and realise sadly, that I am one of those users who knows the 10% 'above water' A month ago I realised it will take me a year to get to grips with the programming and stopped rushing into building and more on understanding the basic structures of different applications, I mean I got to the point of not thinking of the UI but to the actual 'real stuff'

To be honest, I really can't wait to get stuck in to the other 90% I have limited 'basic' (and I mean basic, the last time I studied programming was twenty years ago at school) knowledge but think I will need so much more and can think of five different languages I need to learn so far!

I don't see much code around Joels site, but the WISDOM is immense,

Thank you all

Shauny

Shaun Crowther
Sunday, August 10, 2003

Joel -

Your characterization of XP is a little off.  XP says that if the customer is doing technical stuff, or the programmer is doing customer stuff, you'll probably end up with bad results.

So write down some user stories, iterate, show them concrete working functionality, revise, keep communicating.  It doesn't mean you ask the customer what O/R mapper to use, for example - any set of practices that advocated that would be useless, and fortunately XP doesn't.

I'd recommend starting with "XP Installed" by Ron Jeffries to anyone wanting to learn about XP.  Quick read, flows well, and contains a lot of wisdom even for people who decide XP's not for them.

Steve Conover
Tuesday, October 07, 2003

*  Recent Topics

*  Fog Creek Home