If you develop a software product that has a graphical user interface, a document that describes the visual style that the product will portray can save a great deal of time.  One of the problems that engineers face is that they have so many decisions to make.  The more that are made for them, the faster they can go.

Style decisions can be made before the software is developed.  This includes screen guidelines such as resolution, colors, fonts, and the size and placement of common controls.  It can extend into print and into sound and video as well.  Although some are very talented, most developers I know are quick to admit that they aren’t the best at developing the style elements, so these things help immensely.

On the web and desktop, style sheets and themes are common.  These are valuable tools that are read by the code itself.  Style guides that can be represented as data or files that the real software uses.  This is what I prefer because they must be accurate to actually work and they are real so the designer is actually a real significant part of software development.

Reporting systems also have style elements separated and typed out in separate files to a degree that makes this job easier.

It’s important that it is clear that style guides are only a part of the development of software.  It isn’t fair for a customer representative to deliver only pictures and expect the software engineers to know how to build the system.  These things can be very valuable additions to discussions, but by themselves, they are not enough.  Stories should be developed and user story tests as well.  Style guides can be used to make the process go even faster.

As usual, I don’t suggest doing it all up front.  Get the software engineers developing code as soon as possible so you get feedback about how effective the designs are when painted on working code.  It’s pretty easy to change these things, which gives you even more reason to get it going as soon as possible.