Faux Stylin'

Our brains have two distinct hemispheres. Some people believe that we are almost two different people living in the same body with a minimal connection between. The left side of the brain is the rational intellectual one, while the right side is creative. This split is important to our world-view. I've badly paraphrased these ideas, which are described quite well in the classic reference:

http://www.amazon.com/Drawing-Right-Brain-Betty-Edwards/dp/0874775132

Irregardless of our physical structure, we all have an inherent duality in our nature between our intellectual side and our emotional side. The two are oil and water, mixing as poorly as our concept of right and wrong so clearly fail to mix with the law of natural selection. Intellect is a higher, abstract perspective that sits above the grittiness of the real world. A while ago I finally learned to unify the two, by not bothering to try anymore.

Art -- at least the really compelling stuff that captivates us -- is the act of somehow almost magically embedding some emotional context into a work. Great songs move us emotionally, great paintings touch us deeply. The very best films we've seen leave a lasting low-level emotional connection buried deep into our sub-conscious. Good art encapsulates emotions, even if we can't exactly define what that means.

Somehow it reaches out and touches us deep inside.

Creativity, as I've often guessed, is some sort of intrinsic human flaw. After all, we combine elements that don't belong to get something new. That's clearly got to be a short in the circuitry of some type. The brain's wiring just isn't staying restricted to the "rational" things that it should. Creativity is just some kind of bug, or glitch that we manage to survive anyways. It's not fatal, but that doesn't make it normal.

The glitch can occur no matter what we are doing. So, in that very sense it doesn't matter if it's applied towards things that are emotional or things that are intellectual. Both are really the same as far as glitches go. Either half of our brain can short out at any time. Creativity is not restricted.

Building something like software, while it is composed of a complex set of underlying parts that all need to fit together and interact with each other, is clearly not an emotional exercise. It is intellectual. Other than crying out in frustration, software doesn't generally move us, we simply use it to accomplish our goals. Its byproduct could be artwork, but the mechanics of its existence are just cold and hard intellectual efforts.

Thus, it's pretty fair to say that software programming is usually an intellectual pursuit, however the visual design of that software is not.

Graphic design is an industrialization of art -- work done specifically to make revenue -- yet it is still tied into the underlying emotional context of artwork. A good design or layout retains vestiges of emotional context; that is why we find the design pleasing or correct. It may not have the grand impact of its fine art cousin, but it is still quietly and carefully touching people.

A well-designed magazine is pleasing to look at, not because it is an exercise in intelligence, but because its design, colors and overall layout are esthetically pleasing. There is still an emotional sub-content embedded in that design.


PROGRAMMERS AREN'T GRAPHIC DESIGNERS!

Most professionals know their limits, but software developers have some weird mistaken belief that because coding is intellectually creative, that it somehow translates into their being able to do design issues. To be emotionally creative. That all creativity is somehow the same.

Programmers are notorious for undervaluing most other disciplines. Possibly because we do so much deconstruction work that it is easy to simplify everything to the point where we foolishly think we understand it better than we really do.

And there is no other discipline that we constantly undervalue as much as graphic design. It's not uncommon to run into programmers who are extremely proud of their home-grown butt-ugly interfaces. Butt-ugly rules the industry.

Somehow we like to zoom ourselves into believing that it looks good, when it clearly is hideous. Bad colors, cramped designs, awkward interfaces, etc. These things litter the programming world and often behind them is a proud, but oblivious set of coders. Sometimes even bragging about their abilities...

Because of this I need to make a very STRONG point:

- There is nothing about programming that is even remotely related to graphic design. The two are complete opposites (or at the very least should be considered so).

Being a good or bad programmer is completely unrelated to any sort of ability do graphic design work. One is about precise intellectual work, while the other is about sloppy emotional work.

Good graphic design feels right, for completely non-rational reasons. If you can apply a pattern or create a formula for it, chances are it isn't good graphic design. Good programming on the other hand is clean, simple and obvious. Patterns are useful. There are clearly rules that can be applied, even if as an industry we have not yet progressed far enough along that we can all agree upon them.

And it's not like you can just read a couple of books or take a few course and *presto* you 'get' graphic design. Unlike programming, graphic design isn't intellectual, it's driven by a non-rational emotionally driven foundation. A good sense of style, experience and a mentor are amongst the things needed by graphic designers to learn to connect with themselves on an emotional level and then channel that into creating something pleasing. If it's rational or a formula, then it just isn't emotional is it?

If you can lay it out in a set of simple rules of thumb and follow it blindly, then it definitely isn't graphic design.


SOFTWARE DEVELOPMENT

If you're serious about writing a high quality commercial-grade piece of software there are a few things you JUST do. Some are obvious, like using source code control. They are well-known.

One thing you definitely do is hire a graphic designer to create the interface and overall experience. Artistic fellow programmers -- no matter how hard they swear they have a good design sense -- just do not have the experience or training to do a good enough job in the design. And it's not an aspect of the product that you really want to leave to chance.

In a restaurant, all cooks know that "presentation" is at least half the experience. Poorly plated food is a disaster. The same is true for software applications. If they look good, they are just so much easier to appreciate. Ugly interfaces make for cranky users.

Graphic design is absolutely critical.

Now, that being said, hiring a graphic designer is both expensive and sometimes a difficult issue. You often need to review a number of them, since they all have very distinct styles that you are buying into. Hiring a graphic designer with a retro style to create enterprise applications probably won't help sales. Hiring a corporate-style designer to create an interface for kids won't work either.

It's not easy to find a designer, and in many circumstances the depth of the project makes it unlikely to fund the work either. Sometimes, we just have to wing it. It's unfortunate, but sometimes unavoidable.

Now, before I continue I need to add in a rather hefty disclaimer:

I am not a graphic designer, and I have no idea how to really do graphic design. Most graphic designers would pee their pants laughing at the utter simplifications in the following advice. Nothing I am about to say should be taken seriously as "graphic design", and please whatever you do don't mention any of this at any party that happens to have one or more grouchy graphic designers hanging about, just waiting for a non-designer to foolishly open their mouth and spout some gratuitously anti-graphic design dogma. And in no way should the preceding sentence cast any sort of implication whatsoever that I think that many or all graphic designers are either grouchy or overly sensitive about their profession. I do not. They are generally very nice people, when they are not mad at you.

With that in mind, I'd like to list out a few simple yet key items that can help programmers get around their lack of graphic designer access for a while. If you must go for a time without a designer, then keep the following in mind while you are laying out the interfaces. These small bits of attention to detail will help in making your product suck less, up to the point that you finally give in and hire a real graphic designer to clean up your mess.


GRAPHIC DESIGN ISSUES

1. Apply a Real Color Palette

Colors work together or they do not. It's a little bit science but a lot of emotional madness. Unless you get it, you probably don't get it.

Whichever way, it is very hard to find a group of compatible colors that work together. The larger the size of the group, the harder it becomes. There are lots of web sites out there on the Internet to help. They will give a list of colors in a palette. It might seem easy then to just use one, but you always have to keep in mind the total number of colors. Palettes of 4 are easy to find, but most applications need 7 or more colors for the whole system.

Once you have the colors, they have to be applied consistently. Even though elements of graphic design are irrational, consistency in the user experience is still vital to a good design. Little inconsistencies come across as sloppiness, but not the good retro design kind...

You can also steal colors off a painting or other color artwork, but that's a bit of harder trick to pull off. Don't try this, unless you've been through a lot of color painting courses yourself.

You often see programs that started out with a reasonable design, but then later other people started applying other colors indiscriminately. That's just a quick ticket to a mess. If the circumstances for colors don't fit, then you need to redo it all as one big unit. All the colors need to fit, you can't just throw in an extra one as needed.


2. Don't Allow too Many Fonts

Nothing screams amateur like a screen full of different fonts. And yet it is so common to see this, particularly on web pages.

Of course it's harder than most people realize, because you'll find that many graphic designers take "different font" to mean any variations on the same font: such as size, color, bold or italic, not just differences in family.

Application screens shouldn't be composed of twenty different fonts (or variations on those fonts), it is just ugly. Somewhere I remember reading that 4 or 5 was a good number on a screen, but I'm not sure where that came from.

Everything shouldn't be one font either, since that is also hard to read. Fonts help to draw attention to the different screen elements. They serve a valuable role in helping the users navigate the functionality. They are more than just pretty decorations.

A couple of different font families can look nice together, but a lot of them might set off weird issues. Two is most likely safest.

Also, mostly it is better to drop the serifs. They are dainty ornamentation which looks good in "some" circumstances, but overall it is best to go for a simpler design where possible. San serif fonts are fine for most things.


3. Use Negative Space

Another thing people do frequently is cram the screen with as much crap as possible. That craigslist aesthetic can present an intimidating wall to the users; eventually they might learn to ignore it, but one doubts that they'll ever really forgive you for subjecting them to it.

Negative space is all about the blank areas on the screen that are not being used. A good graphic designer can use these areas very effectively to drawn in the user and position their interest. Again, this is about controlling the individual navigation within a specific screen. Keeping this under control allows the users to get to their intended locations a lot faster and with a lot less aggravation.

Using negative space is very complicated, but in its simplest form it is probably just best to say that non-designers should make sure that some large percentage of the screen is just blank. Great graphic designers might push upwards of 50%, but it probably works for most applications to try to keep at least one third of the screen from having stuff on it. That should keep it from looking too cluttered, while not looking too empty. A delicate balancing act.


4. Create a Design Grid

To keep the same feel across a large system, all of the pieces have to have some overly common elements that are the same. Some designers will create a 'design grid' that becomes the structural framework to hold all of the pieces.

They can be quite complex, and have interesting geometrical attributes. The design might be trying to drive all of the visual elements towards a diagonal line in the center for example, or they make be pushing more simplified compositions. For instance photography likes the 1/3 rule of composition.

Whichever way, the "big" elements in the screen should have positions that don't vary for all of the screens in the same grid. A complex program may actually have a couple of design grids at different levels, but it gets more complex to pull that off.

Keep it high-level, and keep it simple. A design grid should only have a half dozen or so things hanging off it. Draw it out in the beginning, and then stick too it. If something breaks the grid, first try with all of your effort and might to get it to fit. Only go for a second one if it's impossible for the first one to work, but they you have to rejig all of the existing similar screens to match for consistency, which can be a lot of work.


INTERACTIVE DESIGNER

The above items work for static "print" like representations. Many dynamic computer systems have a few other intrinsic issues that come under the category of interactive design, a sort of off-shoot from traditional graphic design that is dedicated towards interactive experiences.


5. Consider Flow and Resizing

The screens change in size, and in many cases the data can grow to be rather large. These changes need to be taken into account in the design grid, so that as they grow, the design doesn't get uglier.

The easiest thing to do is to restrict the flow to only one direction. That is why many web apps have a fixed width and a growing height downwards.

Two expanding directions becomes very difficult particularly if the design grid is based around some proportional representation. A fully re-sizable web application, for example, doesn't even have a default size anymore. Laptops, wide screen monitors and a huge array of different devices mean that nothing is certain for the screen dimensions.

If you need to grow into both directions, then trying to keep some type of even balanced layout is best, yet extremely hard. As the aspect ratio of the screen changes, the characteristics of the screen layout change as well. Diagonal growth is both a complex coding trick and a complex design interaction.


6. Minimize Navigation for High Frequency Operations

History is responsible for far more of the organization when it comes to where a lot of the functionality ended up in most modern software systems. As such you get the "Microsoft Problem", where after years of junior-level independent teams haphazardly adding mass amounts of functionality to overloaded bloated applications like "Word", the structural organization of the functionality -- which started at one time as deterministic and orderly -- is now basically erratic. You never really know if a piece of functionality exists in an application until you've completed an exhaustive search of all of the menus. A problem that is both irritating and wasteful.

The best thing to do is to get real statistics on which functions are used how often and by whom, then use those numbers (and consistency) to drive the placement of the functionality in the application. Of course, as this does change as the application grows, it provides for a strong argument for using very short, loose coupling between the triggers for the functionality and the functionality itself. Growth often drives the need for occasional interface reorganization. Accepting that, means less work in the long run.


SUMMARY

Presentation is half of what makes up a good program. In order to use something well, you have to want to use it, and crappy tools make themselves more difficult. Less inviting.

Many people mis-estimate the complexities involved in making things look good, so they often don't. They delude themselves into thinking that they have the skill-set required to do real graphic design. Just because something isn't intrinsically interatable -- it's impossible to write an all encompassing manual for it -- doesn't mean that it is simple. Programmers know this about programming, but refuse to accept this in other domains.

In the end, an ugly application that is hard to navigate still does the job, but it is nothing to be proud of. Often it's not that hard to get help, and it's not that much work to apply it. For some people, they have to get beyond their own narrow view that it's not hard or it's not complex, or worth the extra money or time or effort to get it right. It's hard, expensive and always worth it. That is, if you want professional results.

If you really think you have graphic design skills -- and you just might -- the only way to know for sure is to start taking a lot of art courses. A lot of art courses; one or two just isn't enough. A raw design sense and some untrained ability is not enough to do a professional job, but it is enough to be able to justify spending more effort learning. Programmers -- especially as they age -- need more than just programming skills to survive; half coder, half designer is a strong combination, but it has to be backed by real knowledge and experience, not just hubris.