General Design Guidelines that Reinforce Slicer's Brand

Core values of the 3D Slicer software and development effort

GUI Appearance:

Clean white background
Precise hairline around buttons, icons, menubuttons, and white background.
Black text labels where reasonable.
Verdana is the font of choice, if GUI toolkit permits (can compromise on this for usability issues).
Icon conventions are here
All icon image data for application GUI can be found in Slicer3/Base/GUI/ImageData. Individual modules may use these icons too, as well as define their own.
Conventions for icons as menubuttons, radiobuttons and checkbuttons, see here
Application should have a consistent presentation of checkbuttons and radiobuttons. So either use the custom icons provided in above reference, or use default presentation consistently, application-wide.
It's very important to acknowledge contributing projects, labs, and funding agencies. Provide a standard space for acknowledgement for any software module within the module.
Preserve the footprint of space beside Slicer's logo; do not include other logos in the main application GUI.

Compact, readable design:

Where possible, multiple pop-up interfaces should be avoided; this can lead to clutter.
Functionality in module interfaces should be clearly and cleanly grouped
Where possible, group functionality in collapsible frames, so a user can hide unused elements and simplify Slicer's face.
The highest level of functionality grouping should be visually dominant (e.g. "Input", "Parameters", "Display", "Results"). See Stacked or Tabbed groups.
All modules should reinforce the same organization.
Choose a tabbed panel if each subpanel will require scrolling; choose a stacked panel if there would be too many tabs arrayed horizontally.
Arrange stacked or tabbed subpanels in an order representing workflow, up-to-down, or left-to-right respectively, where appropriate.
A secondary level of functionality grouping should be more subtle, and visually distinct from the highest level.
The density of widgets should be carefully considered. Widget packing should provide enough space to maintain readability, yet be compact enough to minimize the need for scrolling.
All widgets have balloon help on mouse-over for clarity.
Maintain keyboard shortcuts if possible. Please keep a consolidated list of all keyboard shortcuts as they are defined.

Behavior:

In general, users should have to CLICK the mouse to trigger a UI event. Try to avoid UI behaviors that trigger on mouse-over, except for balloon help.
Any pop-up widgets that are designed to withdraw on a MouseLeave event should have a footprint big enough so the user doesn't accidentally exit the widget.
Good to have message dialogs that have "Message" "Warning" "Error" icon on them (this isn't currently consistently presented).
All collapsing panels should contain an indicator that communicates that they can be opened/closed.
The option to minimize/hide chrome and GUI around Slice Viewers is required, so a very minimal data viewer can be presented.
Commonly implemented mouse-control of window/level/threshold would be ideal, or some variation on this that doesn't interfere with pan & zoom.