When designing website mockups, I always do my best to stick to a reasonable number of typography styles, and make sure there is clear intent behind the hierarchy and styles. Doing so keeps the final result more consistent and it leads to cleaner development files. Basically, future-me will be a lot happier. But as the project hums along, and the number of Photoshop files starts stacking up, it gets tricky to remember the original intent with the style choices.
This led me to explore the idea of a basic style guide. I’ve read about web style guides in the past, but I always understood them to be large, complex documents created at the end of the design phase to pass off to developers. Totally intimidating. Plus, this didn’t solve my problem of keeping my own design direction in order along the way.
So with a recent web design project I spent some time mapping out what the different markup tags would be (based on the sketches) and what characteristics those tags would have. I did this before I even created the first layout file. I wouldn’t guess that determining the styles before even beginning the mockup would work very well, but I was pleasantly surprised!
What I found was that by solving all of the different type styles that I could identify from the sketches, there was less decision making on the fly with each individual mockup. This led to more consistent layouts from one section to the next. And happier future-me.
Sample web typography style guide
The developer, Jeremy, was happy with this new step as well. Instead of scouring the mockups for common font styles (and guessing when they were mis-matched slightly) they were all mapped out in one place.
I posed this idea on Twitter:
“Developers: How much would a web typography style guide help when developing? Main goal is to reduce the many different styles in mockups.”
The response was positive:
@claytonlz said that the guide would help a lot during development, even more if developers didn’t have to do much to make it work. He and @markng also said that understanding the purpose and intent of the guide is important, referencing the Twitter Bootstrap CSS documentation.
@jerrythepunkrat mentioned that his team creates a UI style kit on web projects, including HTML/CSS for the typography, forms, and buttons. For naming these items, he suggested conventions such as “has-gradient” or “big-search-btn”.
What are ideas you guys have for managing the many styles that are established throughout the course of designing a website? Also, I’d love to hear any thoughts on how to convey the purpose and intent of the guide.
Love it!
And as a follow-up to my original comment about Cardinal Path’s use of UI kits, we’ve since implemented a fuller CSS framework to begin every site design. Something similar to Twitter’s Bootstrap CSS framework that includes both base visual styles as well as a CSS grid framework.
http://twitter.github.com/bootstrap/
This is fantastic stuff Amy! Really good ideas, here. I’d like to implement this in future Mockups, would make handling text more consistently wayyyy easier. Thanks!
Thank, guys!
Mike, I’m curious to hear how your framework is going. Are you creating a custom one from scratch?
Stephen, as you adapt this idea to your process, I’d love to see some samples of the guides you develop!
Really interesting post. I was wondering if you have a template (for example a PDF document) that can be used as a start for the style guide.
Antonio, I don’t but that’s a really great idea. I start by marking up tags on a printout of some page mockups, and then I make a Photoshop file according to those tags. But a template would be smart so I don’t accidentally miss some tags that don’t happen to be in the mockup yet. I know I forget things like lists a lot.
I’m going to work on that and I’ll post a follow-up. Thanks!
Amy, sorry for the delayed answer here! Our CSS framework is a homebrew that’s primarily based on Twitters Bootcamp framework and a responsive grid framework called Skeleton. We’re baking in some additional pieces and customizing for our process. And of course it’s meant to just be a framework to start from. We begin with this, build out all the global styles for the new site, and then customize as we build the site.
Mike, I’ll have to check out Skeleton since I’m interested in responsive these days. I haven’t figured out the nuances of frameworks — we tried one here at Forty on a previous version of our site and it ended up causing us serious maintenance headaches. The way we built the site we had to add so many classes to each element, and it wasn’t at all understandable to someone who hadn’t worked on the development. I guess it’s that “customize as we build the site” step that is important :)