I was not specifically trained for visual design, as a graphics artist would be. I've developed my own aesthetic sense from doing design and from internally critiquing other designs. One of my main practices in visual design is to keep a sketchbook full of projects I've worked on and projects I'm working on. This gives me a chance to look at what I've done before for ideas. Also, the sketchbook very strongly gives me the impression that I'm doing conceptual design--it doesn't matter if I get the buttons precise, within a pixel, because I'm not working at that level yet. Thus, I can explore design ideas without being concerned about precise placement. In fact, I will frequently do at least one major shift of a UI element from the drawing to the finished product. Now, keeping a sketchbook is not a new idea in artistic fields, but for someone with a computer science background, it was novel.
I collected some other interesting ideas on visual design from the (now-defunct) smallhci mailing list. Paraphrasing Doreen DeSalvo (doreen@geoworks.com): she keeps folders of designs she comes across, divided into good, bad, ugly, and "mine".
One person said that she divides her sketchbooks into folders on a per subject/per room (she's an interior designer) basis to make it easier to come back and find the ideas later.
Merryl Gross (Merryl_Gross@SilverPlatter.com) suggested using screen-shaped pieces of paper to design on, then using these as a sort of paper prototype for the UI. These designs are then helpful for communicating with other people on the team.
Another idea I've adopted came from one of the CHI (Computer-Human Interactions) conferences (sponsered by the ACM). I believe it was CHI '92. The tutorial was called something like Exploring the design space and it was a collection of photographs of various user interfaces from different OS platforms and different applications. I adopted this idea for our company's products--I put together some internal web pages with screen shots from some of our products and a discussion of the design.
Once I've generated a visual design of part of the UI, I start working on implementing. The first task is to lay out the classes (I usually work in C++, so my discussion will reflect that). Being a software engineer, I'm in love with white boards. (Well, not really--I'm really in love with my fiancee--but white boards are certainly one of my favorite tools). I will frequently sketch the UI onto one white board and lay out the class on another. If the class and design is simple enough, I don't bother with the white boards--I put the UI directly into the computer using a resource (i.e. visual) editor and program the corresponding classes directly. However, for more complicated classes I hit the boards. One board is my current view of the visual layout of the UI. I update this one as needed--erasing, marking over bits, adding annotations. The other board is usually a text-based version of relationships and/or functionality I need to keep track of. If there are more than a few (2-3) classes involved, I will ususally draw them as boxes with the name of the class inside each box and lines connecting them in some sort of relationship. That way, I can manipulate the programming design opposite the visual design until I'm happy with how things are layed out and how the classes and class relationships are going to work. After all of that, then I'm ready to start programming. As is always true, sometimes the implementation of the design sparks some changes to the design--improvements because of repeated bits that weren't obvious from the design, changes to make things easier, etc.
As usual with web pages, this isn't done. I will add more on a somewhat irregular basis. However, this is my latest project on my personal web pages, so it should be somewhat frequently updated.
Comments questions and other such can be sent to me at scott.machaffie@gte.net