I started with style guides like any other obsessive-compulsive designer: with the desire to make it simple to maintain and grow a design. Plus, knowing which component to use in a given situation is nice, too, right? Since making this a regular practice, I’ve found it’s been like having a nice combination of a CSS class and a pattern library all in one.

One of the first questions, understandably, is why use Fireworks for a style guide? Well, for me, it’s mostly because of symbols and styles. Sure, you could use similar things in Photoshop, but I find Fireworks’ implementation to be smarter.

Here’s why I love it:

Symbols update everywhere, and you have to update them only once.

Symbols have states, which let you easily show things such as selected and unselected states.

Symbols may be placed on a single page for easy editing.

If the styles are for the Web, you can easily export them as CSS.

This article is all about understanding why you would want to set up a style guide using Fireworks, and you’ll also get a little starter template that I like to use.

Important note: Fireworks’ future is uncertain, as Adobe decided to feature-freeze it in May 2013. There are rumors of Adobe working on a replacement, but nothing definite so far. I’ve spent the last few months with an alternative, Sketch1, and found it to be… well, pretty fantastic! It’s a young Mac app but shows promise. Also, while Fireworks (CS6) is unlikely to receive any major updates in future, it is still distributed and supported by Adobe and should work on the latest Windows and Mac machines. You can read more about Fireworks’ future in this pretty detailed article2.

What is exactly a “style guide”, and why would you want to create one? Let’s start with a brief quote from a well-known encyclopedia3:

“A style guide or style manual is a set of standards for the writing and design of documents, either for general use or for a specific publication, organization or field. The implementation of a style guide provides uniformity in style and formatting within a document and across multiple documents.”

The biggest reason to create a style guide? The sheer amount of time you’ll save. Depending on the size of the project, reproducing your changes could take minutes or hours. Imagine designing a game, a complex website, a mobile app or a large corporate intranet: having to update one element that appears on dozens or hundreds of pages would be a tedious, madness-inducing task. You have better things to do, like look at cute cat pictures — why waste your time doing the same thing over and over again?

4A style guide helps you to maintain a consistent look over time, and Fireworks can save a lot of time.

Instead of wondering how to style headings, you could look to the style guide for answers. As your design grows and you add elements, putting all of the elements on one page will help to ensure that they look like they were all crafted by the same hand — or at least look consistent. The secondary benefit is that you won’t have to solve the same design problem multiple times.

If you work on a team or for a client, handing off the document to someone else is very easy. You’ve already done the work of specifying how things should look; so, anyone else can step in and pick up where you left off.

Speaking of which, if you’ve ever applied a CSS class or ID to an HTML element, then you’ve basically written a style guide — even if you didn’t necessarily formalize it as such.

When you’re presenting a design to a client or team, use the style guide to guide your presentation. A lot of people are talking about style tiles, style prototypes and element collages these days; there’s no reason why a style guide can’t fit in there. It’s a great way to help someone visualize what a product will look like without having to design every screen.

The short answer is: a lot of people. Companies use them; banks generate reams and reams of documentation on how the logo should be implemented and which pixels should go where. While extending a brand across a wide range of products and services is complex, a small company typically does not need such extensive documentation yet still would benefit from consolidating its design standards into a single set of guidelines, a style guide.

So what should be included in a style guide? Well, I usually put these few things in mine:

headings;

text size of body copy;

links (don’t forget visited links if you’re making a website!);

sizes and treatment of images;

logo;

important modules, like headers and carousels.

If you’re making an app, the list might be a little more extensive. I’d also include elements such as:

button types and styles;

navigation bar styles;

table styles;

icons.

Fireworks is not the most suitable application for defining such things as animations, CSS transforms and transitions, or non-Web-font families (or CSS styles in general, although Fireworks does export CSS code, if needed). These are a critical part of the experience but might be better defined with a prototype or the like.

(Some specifications of motion design are useful in a style guide — such as easing, timing, gradient, rotation, and scaling end points — but an interactive prototype would demonstrate these much better than a static image or document.)

All that being said, the size of the style guide should fit the project. If you’re making a simple app, you could probably keep it lean. If you’re working for a financial institution, then it might need to be substantially bigger and more prescriptive. The format and level of detail are up to you.

If you’re developing a mobile app, ensure that the design and development team is familiar with the human interface guidelines of the relevant device or platform. Apple5, Google6, Microsoft7 and others publish guidelines to ensure quality and consistency. The guidelines are geared to designers, but you might want to ensure that your team understands things like the minimum touch size for buttons (44 × 44 pixels for iOS, by the way) and the standards for typography and icons.

I try to keep everything on one page in Fireworks, because exporting slices is much easier if all elements are on the same page (more on that later). The alternative is going to each page, exporting an image, checking that I’ve put it in the right folder, and then cursing myself if I’ve accidentally saved it to the wrong spot.

Speaking of which, aren’t slices in Fireworks awesome? Without them, we’d have to do something like this:

copy symbol to new document,

paste symbol,

trim canvas to fit,

save symbol,

close,

repeat 50 times (getting sadder each time).

Clearly, no one would want to do this. If slices were a person you could hang out with at a bar, I’d buy them drinks all night.

Use symbols and styles as often as possible. With them, you can easily create something once and update it throughout the document. (By the way, Fireworks doesn’t always honor updates to styles inside of symbols. Sometimes you’ll have go into each symbol and refresh the style individually. It’s a bit of a drag, but it happens so rarely that I’m not bothered.)

Use a symbol when a UI element repeats throughout the website or application. The usual candidates are buttons, icons, images and logos. A symbol has states, too, giving you the flexibility to display various states of an element (for example selected and unselected) or just to test various iterations of an item.

Once your symbols are set, create a slice for each element. Fireworks’ naming convention is not human-friendly (it comes from old Web layout practice: [Document Name]_[Row Number]_[Column Number]). So, look to the all-powerful Properties panel to create your own names for slices.

Useful tip: You can highlight multiple elements and create individual slices for each one. Simply select all of the elements on the canvas, and go to Insert Rectangular Slice → Multiple slices! It’s a real time-saver.

If you’re creating an app, try to work with vector graphics whenever possible, which make it much easier to scale icons infinitely to higher-resolution devices. I’ll have to gloss over some finer points, such as ensuring that icons scale down well.

Usually when designing for the Web, an icon font is most helpful. I have nothing but love for IcoMoon22, which creates an icon font from SVG graphics that you upload, for free. Icon fonts currently have some limitations, such as individual elements being confined to one color. So, if you need multiple colors, gradients and so on for your icons, then exporting an SVG or a @2x PNG might be best. (Note: SVG is supported in Internet Explorer 8+ and in recent versions of all other major browsers.)

Picking the right time to build a style guide isn’t an exact science. I usually start once I’ve determined a direction for the project. Creating it first usually wouldn’t make sense because I’ll often experiment with fairly different ideas. Doing twice the work doesn’t appeal to me.

You also don’t want to end up a slave to the process early on. Creativity should be messy, weird and fun — bottling all that up in a style guide too early on would really break your groove and stifle the design. The style guide should reinforce your creativity and, therefore, should come second. Don’t wait till the end either, because you want it to guide the rest of the process.

In short, don’t do it too early, but don’t wait until you’ve finished the design. Having to duplicate objects from page to page is a good sign that you should create an asset (i.e. with symbols) or define a style (i.e. with styles). My style guides usually start out as a working canvas: Design elements and type treatments that I like will hang out on the canvas until I decide they should be standardized (and become part of the style guide) or discarded.

Using symbols and styles early on also means that you won’t have to apply endless updates if one icon changes. I’ve overlooked doing this a few times and probably said some words that I regretted as I went back to adjust each little mistake afterwards.

Teehan + Lax has made its own UI PSD for iOS 724 that is perfect for getting an app style guide going. Even though the file is not in a native format of Fireworks, it can be easily opened in Fireworks; all of the elements are vectors and so are perfectly editable. (Fireworks can read PSDs pretty well in general, with just a few minor limitations.)

You might not want to give the style guide the shape of an app or website, or else a client or team member might think that they’re viewing an actual app.

Drag in some interface elements and start experimenting! Depending on the scope of the app, you’ll be dragging in various elements. Here are a few that appear in almost every app I make:

status bar,

menu bar,

action icons.

Once you’ve determined a direction, there’s no reason why you can’t begin to customize this style guide to match the feel of your app. It’s a nice way to ensure that everything you’re designing works holistically. Plus, your client will appreciate the details.

I’ll also start to use the guide for some production duties, like saving assets. When designing for iOS, ensure that the normal versions of icons look as crisp as the @2x versions. I’m a big fan of “Snap to Pixel” when working with icons (go to Modify → Snap to Pixel or type Control/Command + K) — it helps with keeping things looking sharp at small sizes. I fully admit that this is a case of designer’s OCD27, and I’m OK with that. I’ll create the normal-sized versions later in the process, when I’m ready to send over some assets to the developer. No sense in creating extra work for myself early on.

Also, I design at the @2x resolution by default because I find that scaling down for smaller resolutions is easier than scaling up. Remember, though, that your font sizes and other elements will be double their normal size when you do this. When working with text, specify in the style guide the intended type size, not what Fireworks says. (When scaling text along with the document’s overall size, Fireworks will change its size, but the Properties panel might not report the actual new size. It seems to be an odd limitation of Fireworks’ text engine).

Here’s where it gets more fun. Now that your buttons, logos and other elements are in the style guide, you can easily highlight them and creates slices. If you’re working on a project that requires higher-resolution assets, then duplicating your symbols on the style guide’s canvas and exporting them directly from that page is simple.

Select all of the elements to be sliced, and then go to Edit → Insert → Rectangular Slice. (Remember what I said earlier about human-unfriendly slice names?)

Note: When Fireworks asks, choose “Multiple,” or else it will create a single large slice.

Slices are ready to be exported whenever you’re ready! You can even give slices their own export settings (PNG32, PNG24, PNG8, GIF or any custom format — for example, PNG8 with a limited number of colors, JPEG Progressive with a set quality, etc.). The settings will be saved in the Fireworks PNG file, so exporting and re-exporting assets is very easy.

The Pages, Layers and States panels help you to navigate quickly through the Fw PNG file. I use states to prototype designs for a particular view or page, and each view or page will have its own page in the document. I’ll generally make a master page (containing the chrome and unchanging elements in the design, such as the menu or tab bar) so that I have one less thing to paste in the page.

Styles are helpful because you can select an element and immediately apply a style to it.

The document library holds all of the symbols, and it’s an easy reference point if you need to drag something onto the canvas. I find myself just copying symbols from an existing page. (Quick aside: Fireworks has some issues with trackpad scrolling in panels, but you Windows geeks should be just fine with scrolling, I hear).

Finally, the Properties panel gives you complete control of the properties of all types of objects, including vector objects, bitmaps, symbols, auto shapes, vector masks, slices and more.

Style guides, in their various shapes and sizes, are a critical part of any project, and using one brings many benefits, including the following:

keeps the project visually and functionally consistent as it grows;

keeps you from having to repeat the same task over and over;

helps the developer understand how to build what you have designed, so they’ll ask you fewer questions;

makes it easier to grow or modify the website or application.

In short, if you’d like a consistent, healthy app, then don’t overlook style guides. A guide converts design styles into values and standards of coding, and it could be invaluable to your project.

If you use Adobe Fireworks in your daily design workflow and have any questions about how to build a style guide, let me know on Twitter39 or here in the comments — I’d be more than happy to help! I’d also be glad to hear of your own experience with making (and updating) style guides.

Angel Montiel

Thanks for this friendly and inspiring article, this is very helpful to organize your workflow and to be consistent through your all website or application, I will let you know how it goes while trying myself, BRAVO!!! and thanks for sharing.

Kris Jolls

Hammad

Jenikya

I’ve actually done something like this when I’ve created designs for a web application. It was really useful to have all of the elements in one place and then to pick and choose to build up other designs. It worked well for me.

0

10

bryan chalker

Great article Joshua. Long-time Fireworks user and lover. Fantastic tool that fit(s) web needs like a glove. This is a nice use of it’s strengths. Still feel like I’m being unfaithful, every time I launch Photoshop…

Joshua Mauldin

Andy Parker

Thanks for sharing your workflow, it is good to see how a designer approaches web visuals, but it does worry me a little.

By adding application chrome to it you’re implying it’s on an iPhone? That is incredibly risky. Can you now make me one for a Blackberry Bold, Curve and 10, then one for a HTC Desire HD, HTC Wildfire, Nokia Lumia 800, Samsung Galaxy S2, S3 oh and an iPad 2nd generation and retina.

This is a risky format, not just for setting expectations but also for digging yourself into a hole.

0

17

Joshua Mauldin

Thanks for the note. I think I get your point, and I scoped this style guide specifically for an iPhone app.

If you’re looking to be a little broader and work for 10 platforms, you may not create something exactly like this. It may need to be closer to a pattern library, or you may need to be less specific here terms of an element’s presentation to focus more on things like type size, color, layout, etc.

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book →

Meet the new Sketch Handbook, our brand new Smashing book that will help you master all the tricky, advanced facets of Sketch. Filled with practical examples and tutorials in 12 chapters, the book will help you become more proficient in your work. Get the book.

Meet SmashingConf San Francisco 2017, featuring front-end ingredients, UX recipes and nothing but practical beats from the hidden corners of the web. Only practical, real-life techniques and recipes you can learn from. Get your ticket now!