Fog Creek Software
Discussion Board

Another reason UIs go wrong

A lot of user interface design discussions focus on designing it right in the first place. f course sometimes you may not understand the user's mental model, or put an option in a stupid place, or put a stupid option

But in my experience an almost unavoidable problem with UI design - is you rarely design the app "right" in the first place.  When you first design your app, the UI and wording etc may not always be 100% clear to average user, but it usually is logical

However, when you release version 2, 3, 4, etc. you start to realize some users want a new feature to do X, and some users want functions Y and Z to be linked together etc. All stuff you didn't envisage originally. 

Sticking with the example of two options Y and Z becoming somehow linked, perhaps sometimes.  You could put the option into
(1) into Y's dialog, (people looking in Z won't find it, people who only use Y will not understand this new option)
or (2) into Z's dialog, (people looking in Y won't find it)
or (3) into Y and Z (some people will wonder if they are the same option or ?)
or (4) create a new dialog (in which case for people using the new function they need to use Y and Z and new function - 3 steps - easy to get lost)
or (5) combine/rework Y, Z and new function into some mega dialog (some people will find this plethora of options confusing)
or ...etc....

And as your app grows, it becomes harder to use and navigate.  Basically three problems, none of which have a perfect solution, I think:
- Apps get more complex => more features = more confusing
- Navigation around the app (finding the options) is almost bound to become more confusing as you add more options
- The original "model" you presented to the user may no longer be a perfect fit to your app. You could throw away your model with each new release, but this in itself is problematic as (a) users have to relearn the app every new version, (b) lots of work for you, (c) for those users not using the new feature - or even those using only some - a correct model may be too complex.  As a complex underlying app will usually reflect into a complex UI/model even if the user only uses a small part of the underlying app's functions.

S. Tanna
Tuesday, May 27, 2003

So you're saying iit's hard to write software "correctly" on the first try? Stop the presses!

Tuesday, May 27, 2003

Yes but - I am adding that what makes many UIs so complicated is not a flaw in the initial design, but the growth of new features

I see lots of articles that address the issue of getting the UI right initially - but I don't see problems in the initial design being the biggest reason for flawed UIs - so the articles aren't addressing the main problem as I see it.

Nobody (well okay some do) mucks up the UI knowingly first time round. But most apps which have been around for a while end up having a less than perfect UI, because of trying to shoehorn new features in when they don't quite fit the average user's mental model.

S. Tanna
Tuesday, May 27, 2003

If continual addition of new features is common on your projects, keep the Rev 1 UI loose so it can accomodate change with minimal pain. Make the UI good enough for the task but don't shoot for the Alan Cooper award on the first pass. As the feature set settles down by Rev 2 or 3, you can then either optimize or re-think the whole UI.

Mark Newman
Tuesday, May 27, 2003

That sounds like the feature-itis that hit Mozilla. Everyone wanted new features, they got dumped into the app and the Preferences dialog, and now it's such a mess that they're abandoning it for Firebird.

I'm sure you've seen mpt's "When good interfaces go crufty" -- it has to be one of the most-linked articles ever -- but in case you haven't:$374

Nate Silva
Tuesday, May 27, 2003

Can you give us exact details of what you mean. For example well-known programs tnat started out fine and then got messed up with later releases.

Until you do that I would be inclined to disagree.

Stephen Jones
Tuesday, May 27, 2003

----"Everyone wanted new features, they got dumped into the app and the Preferences dialog, and now it's such a mess that they're abandoning it for Firebird."----

I find the Preferences dialog a mess in Netscape 7.0 They really should have given it a menu to itself between view and edit. But the change would have been trivial. Where you place something on a menu bar (or whether you decide on some other form of access) is incredibly easy to implement for Windows apps, and so I presume shouldn't be too difficult for Mozilla. The problem is in making the right decision.

Stephen Jones
Tuesday, May 27, 2003

Dear Nate,
                  I've just read the first three parts of the article you mentioned. I think the guy is wrong on every one of them. Too late to go into details, but if you want I'm quite prepared to discuss it article by article.

Stephen Jones
Tuesday, May 27, 2003

The one where I disagree with almost everything in original post.

First, I disagree with the notion that "improving UI design after adding features" is not addressed in literature. That is the essence of usability testing: you built something, you do usability studies where you observe how people use the program/web site, you watch what is hard for them and based on that you redesign your app. Usability testing is rather old and covered in books, web-sites ( and research papers.

I also disagree with the notion that "apps get worse in time". From where I stand the apps that I care about (Word, Excell, file managers, Photoshop and the like) get better for two reasons:
- an average quality of UI improves because we improve things all the time. We went from command line to GUI, over time we added new useful gadgets like toolbars, comboboxes etc. We went from SDI to MDI and back to SDI. We add new tricks like tabs. One example of such progress is Visual Studio.NET which is much better than VS 6.
- software isn't design the way you describe. Next version of Word isn't built by adding some features and then panicking at the end when you see that there was no coherent design. For commercial software there are people responsible for re-designing the app and making sure that design is coherent. But I'll be curious to hear about counter-examples i.e. apps that were worse in version+1.

I also disagree that this is the main problem. I agree with Alan Cooper that designing the thing correctly in the first place is better than fixing observable mistakes (which is not to say that it's a replacement for it). There's plenty of argument to backup that in Cooper's book "About Face" if you're inclined to dig into the subject more.

Krzysztof Kowalczyk
Tuesday, May 27, 2003

I'm not sure what the experience of others is. To me I rarely try to make a conscience judgement about the UI of an application, I just try to use it, and I've found over the years that whereas once I would try for hours, now I'll only try for minutes before consigning an application I can't work instantly to my forgettary. Option overload is fine with me as long as the option I want is in there and I don't have to read the manual to find it.

Tuesday, May 27, 2003

I also disagree with the "When interfaces go crufty" article.  I posted a response to Slashdot when they linked to it: .

Tuesday, May 27, 2003

Count me in as another "cruft" detractor.  It seems that the Internet has allowed pretty much anyone to get up on a soapbox and spew forth without much thought.  I can't believe anyone takes that article seriously. 

Tuesday, May 27, 2003

I am also dealing with this exact same problem!

There is are a number of things that can be done to improve the UI, but as you mention you risk changing things around for existing users.

I do believe that some “re-factoring” of the UI is a ok thing.

For example, as a project progress, often the developers begin to realize that certain tasks should be grouped together. Of course, the problem (as you mention) is that your existing users often get trampled on when you re-arrange things. However, if the UI change is for the better, then I say go for it, as those long time users should not be up-set IF THE change makes a lot of sense.

The key here is MAKES sense! The other question here is how much of a change are we talking about? For sure, it frustrates users to no end to now have to “hunt” for a menu item that has been used for a year WITHOUT ONE SECOND of thought. Moving things around can really anger your users.

Of course, you already have those users!, and are not likely to loose them! Thus, I am actually saying you might have to anger them a bit, as it is new users that are MORE important!

For example, in my tour software my existing users expect to be able to add a new corporate group by selecting a groups button, and then selecting “add new corporate group button”.

However, it became apparent that products like Excel, Word etc all have a File->new option. So, I actually now added a File->new-->Corporate group option to my applications. However, I did leave intact the old method. Existing users will NEVER USE file->new to add a new corporate group, they simply will not. However, NEW users WILL in fact use the software the other way around (ie: they will simply go file->new because that is the way all software they now use works!)

I was lucky, since I have both a main form with some buttons on it, and also have a standard menu bar.

No doubt, when  you have just a few options, it is no big deal. However, as the app grows, then moving things around can be quite flustering for your users, since now they have to “think” to use something that required no though previously.

Also, there was comments made here about usability testing. Man, just look at horrible the new word merge features are in word after 97. In word 97, when you bring up a document in mail merge mode, you get a real nice big square button on the menu bar. This servers several purpose:

1) the user can instantly see that we are in mail merge mode, and not regular mode.

2) It is a large text button, and thus the user can again easily guess and see what the button will do.

3) about 99% of the time, users are going to have to insert SEVERAL merge fields. For example Select Firstname, then insert a space, then insert last name, then hit enter for a new line. Then add the address field. In word 97, this is a really nice process.

In word 2000 and beyond it is absolute night mare, since after you select a field, you are STILL in the field selection box. No one, but no one selects more then ONE field at a time, yet clearly the new UI makes this bad assumption. (after you select one field, the field dialog should close so you can continue working in your document).

If you take a look at the following screen shots as to how my mail merge code works, you will see that in word 97, users CAN IN GENERAL use my word merge code with NO TRAINING.

With word 2000 and beyond, it is really rotten, as now users don’t get a nice “insert merge” field text box, but have to hunt from some small little graphic button.

(you can download a working sample of the above, complete with sample data ready to go if you want).

So, for sure MS has made a complete mess of this word merge option. It worked perfect before. It worked the way I would have designed it myself. Now, some how usability testing came along and destroyed this. Why?

So, I can think of many examples where the next version of the product really does mess things up.

So, yes, I think changing and re-organizing the UI menus for the better is a good thing…as long as it is a step forward. That new word merge really was messed up. I don’t mind the change…but it was also big step backwards, and that I do mind.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Tuesday, May 27, 2003

Well I disagree with much (pretty much all) of the individual observations and examples in the crufty article, but that doesn't mean I don't think the phenomenon occurs.

When I made the post, I was thinking generally of line of business and vertical market apps.  If you have never seen a dialog in one of these type of apps where it has some button which is obviously a late addition, you need to look at a few more :-) I'd rather not give the specific examples  I had in mind, but this would be a reasonable *fictional* example the sort of typical sequence why this stuff evolves:
(skip this bit if you want to see similar (worse?) in a commercial app)

1. There is say some form where the user enters data into a database, let's say create a new purchase order.  Simple: fill out fields, hit OK or Cancel.  Version 1.
2. In some usage case, it turns out that some high % users, print out a particular report 80% of the time after filling out this dialog.  So now you end up with OK, Cancel, OK + Print Report
3. Version 2: For most people an improvement...  or only marginally worse (one unused option). However some new users, discover the Print Report option in this data entry form without discovering (or forget) you can do it somewhere else in the app without adding new purchase order. These new users, therefore learn to add a dummy record, print the report, and then delete the dummy.  While you could argue this is user's fault, the underlying root is the app has more complex navigation.  Anyway version 2 is livable.
4. In the purchase order form, you select the supplier of whatever you're supplying. In most cases you pick from a presetup list of suppliers. However in some cases, it might help if you could add a new supplier right in the form. Version 3 now has New Supplier button added
5. It's already looking untidy. Repeat for a few more iterations and you end up with a mess

If you do not think this type of thing occurs in shrinkwrap apps. Tell me why, (I'll pick Word 97 as example as I have it on this particular machine, but you can find similar stuff in other MS and non-MS apps).  Try doing this,  it's a lot simpler (trivially easy) to see on screen than explain:-

1. If I do Page Setup. Among the options I get Paper Size, Orientation and Paper Source.

2. If I do Print then Properties, I also get Paper Size and Orientation.  I do NOT seem to get Paper Source which is an odd ommission considering this seems to be a options largely relating to the printer's configuration such as toner, DPI etc.

3. If I do Print then Options, I get a whole bunch of options relating to what I want the app to print (like whether to expand various codes and stuff).  Plus I get the Paper source which logically should rather be in #2 (and this would be a lot more consistent too).

4. If I do Print then I get a Copies option.  Then do Properties: I get another Copies option (duplication)

5. If I do Print, the dialog has OK and Cancel. Do Properties and change something, when I return to Print dialog the Cancel changes to a Close button.  Same thing if I do Options on the Print dialog. 

Ah you say, this is because when you changed something in the sub-dialog and OKed it, you can't then Cancel in the main dialog.... Except
(a) it ain't like that.  Trying comparing Options in Save.  The Cancel there doesn't change to Close.  In other words, Word 97 is not even self-consistent between Print/Save in this idea.
(b) For Print:
- if you change Copies in the Properties in sub-dialog to 2.  Then OK that, you also see 2 Copies in the main Print dialog and Cancel button change to Close. Now pick Close. Then do Print again. Copies turns back to 1.  So in this case Close meant Cancel. 
- However if you try doing something like changing Print Resolution in Properties sub-dialog. Now OK that. In main Print dialog Cancel button changes to Close. Click Close. Then do Print again.  When you come back the resolution change sticks around.  So in this case Close meant Close not Cancel (i.e. Apply the changes but do nothing else)
- So Word is not even self-consistent within the print dialog

7. If I do Options on the menu, I get a dialog with 10 tabs that take ages to display, do not hour glass properly, move around in a confusing manner - and include a tab which duplicates #3

Is the above not an example of inconsistency, duplication, and confusion that evolved to a worse state over time? (cf: previous Word versions)?

If it happens in Word 97, with supposedly lots of resources and usability testing, why you would not expect similar types of faults in less resourced shrinkwrap apps?

I don't think the fact Word 97 is old is a get out of jail free. Play around with newer apps, and you can find similar faults. Plus it happened, even if later fixed to a degree.

S. Tanna
Tuesday, May 27, 2003

The major problem with 99.9% of all UI design is in the design of the "U" part of it.  If we could build the U like we wanted the "I" would take care of itself.

Tuesday, May 27, 2003

The "U" is only a problem with programmers that delegate design decisions to them, and consider the resultant mess received back as "requirements".

Joe AA
Wednesday, May 28, 2003

*  Recent Topics

*  Fog Creek Home