Come up with what Joel calls "imaginary users"/"scenarios" and Alan Cooper calls "personas" - describe the prototypical person who will use the software. Or if there are several very different possible users, write that down too. Maybe you need to have two paths through the UI for different audiences.

Write down the goals of your target users; what are they trying to get done? Set some clear direction for your software. Create a list of tasks the software will support.

Don't assume a priori that if you're writing the "XYZ tool" that the tool must be one window opened from one menu entry. Maybe supporting your list of tasks should involve file manager extensions, applets, web frontend, wizards, etc. Your goal should be to support all the tasks appropriately somewhere in Fedora Project, not to "write an XYZ tool."

Do at least a quick and easy UI specification before you write code. Joel's book, and the Isaacs and Walendowski, discuss how to write such a spec. It doesn't need to be lengthy. Refer to the following examples:

Post any or all of the above to the website and/or development mailing lists. If nothing else, you can refer others to these specs when they ask why you do or don't have a particular UI feature.

As you write code, try to stick to the guidelines that are just as easy to follow as not follow; get the pixel spacing right, use clear plain language in messages, and that sort of thing.

Be sure to use libraries when appropriate, such as GTK+ and Qt. Avoid toolkits that don't properly fit in to Fedora Project (such as Motif, Tk, or Swing). Libraries will handle some important details for you.

If you use a GUI builder to create resource files, tweaking UI details will be a whole lot less annoying. (With GTK+2 for example, load dialogs from .glade files at runtime, using libglade.) This way you can rearrange the UI without changing all the code.

Don't be afraid to do some quick "user testing" on non-technical people. You can get useful information quickly, this need not be a high-overhead undertaking.

Categorizing your tasks using the 2x2 matrix in Chapter 6 of the Isaacs and Walendowski book is quick to do and very valuable; you might think of this as the old API design rule, "make easy things easy and hard things possible," applied to the user interface instead of the application interface.

Feel free to email <fedora-devel-list@redhat.com> with comments, questions, or proposals.