creating a web style guide - university of michiganjwithrow/materials/styleguide.pdf · • the...

Jason Withrow ([email protected])

Creating a Web Style Guide


Overview• Introducing Style Guides• The Value of Style Guides• Issues with Style Guides• Style Guide Development Process• Writing the Style Guide• Rules for Interface/Interaction Design• Rules for Form Design


Web Style Guides: A Broad Focus• Traditionally, a style guide was focused on

rules for writing and verbal expression • While writing is one part of a Web style

guide, we need to look more broadly (the Web is much more than a book):– Interface design– Fonts and other aspects of visual presentation– Interaction issues, such as form validation and

error handling, launching a new window, etc.


The Developer’s ‘How To’ Guide• Think of a style guide as a ‘how to’ guide for

the development team– Used primarily for development and

maintenance purposes– Created along with use cases

• Authored by business analysts, the target audiences are typically: – Programmers / Coders– Graphic designers– Any other interested stakeholder


Style Guide Content: Sets of Rules• Each instruction/guideline in the style guide

is referred to as a rule• Rules are grouped at a high level based on

core categories/aspects of the website– Within those core groupings are sub-groupings

used to cluster rules at a more precise level– As there are often a number of rules, breaking

them down into these smaller groupings speeds up the process of locating a desired rule or sub-group of rules


Choosing Top-Level Categories• Depends primarily on the scope of the style

guide; the ‘correct’ categories are ones that divide the content up in a meaningful way.

• Is the goal:– To describe the ins and out of form design on

the website?– To be a general interface/interaction style guide,

considering a wide range of issues?– Focused on a specific web application, so

content is tailored to that specific functionality?


Audience Considerations• Ideally, a style guide addresses all the

questions raised by the programmers and graphic designers (or other members of the development/site maintenance team)

• Stated bluntly, the goal is to prevent the programmers from doing interface and interaction design by giving explicit rules– For the graphic designers it is more about

restraining any ‘creativity’ during development that introduces design inconsistencies


Life Without a Style Guide• As each programmer is coding and

gets to an undefined aspect of the layout, two things can happen:

1. They consult with the business analyst or graphic designer or

2. They decide to ‘wing it’• Sadly, the second option is often the

one chosen. Across multiple programmers this is quite a mess.


The Limits of a Mockup/Storyboard• Mockups and storyboards can only get

developers so far, because they display a static image

– Compared to mockups the storyboards are more useful, but in both cases relatively few specific details (e.g., font sizes) about the interface are conveyed

– Not every page has been mocked-up or storyboarded (storyboards show more screens than mockups, so are more useful)


A Document for Future Teams• Over time websites will often change

‘ownership’, in terms of who is in charge of site maintenance/additions– Due to team members changing jobs, layoffs,

new hires, organizational restructuring, etc.• A very real danger is that the new team will

not have sufficient information to keep the design and interaction consistent

• The style guide conveys the guidelines necessary for consistent design over time


Also Useful with a CMS• Even using a Content Management

System, which automates publishing with a series of layout templates, there are questions that arise:– What situations call for a 2-column layout?– What situations call for a 3-column layout?– When can boldface and italics be used?– When should headings be used?– What capitalization style should be used?– What rules govern creation of a new template?


Relationship to Other Deliverables• Various tie-ins exist with other deliverables:

– Functional Specifications (detailing how specifications will be visually displayed, although rules are generic and specifications are highly specific so it is not a 1-to-1 relationship)

– Technical Specifications and Personas(ensuring that specifications are met and that the needs of personas, such as font size scaling for low vision users, are also met)


Relationship to Other Deliverables• Various tie-ins exist with other deliverables:

– Mockups and Storyboards (providing details such as fonts to use, font sizing, use of white space between sections of content, etc.)

– Other deliverables?


The Value of a Style Guide• Increased consistency (especially when

multiple authors are involved)– Makes the site look more professional

• Improved efficiency– Due to fewer questions from developers

• Fewer errors– Reduces development costs

• Less confusion when the site is ‘turned over’ to another group


Issues with Style Guides• Political concerns

– These arise because so many individuals are potentially impacted by the style guide

– The big question: Will they use the style guide?– May need buy-in at various levels of the

organization• Time and cost

– To do these well takes careful planning– Not just text; good style guides include visual

examples as well


Issues with Style Guides• Iterative looping

– Simply put, you might not get it right the first time through

– During production it becomes apparent that some things look good on paper but don’t work well when implemented

– ‘Fixing’ rules during production requires going back to earlier code and changing it, but at least future production should be free from errors and (hopefully) further changes


Style Guide Development Process• The topic covered by a style guide can be

as broad or as narrow as desired:– Focused just on form design– Considering the entire website interface and

interaction design– For specific web-based applications– Dealing with internationalization of a website– For hand-held devices– Other topics?


Development Timeline• The style guide needs to be developed prior

to the interface being coded• Tailor rules to the specific client needs, but

keep in mind that you could generalize the rules to all forms, or all hand-held devices, and then use the guide on other projects

• If you develop a general-purpose style guide (one not tailored to a specific client) you could also use screenshots from websites showing desired practices


Finalizing the Style Guide• Final changes to the rules will need to occur

prior to launching the website or web application; at that point the site (and style guide) are turned over to other parties– This could be the client (if they are doing

maintenance)– It could be another group inside MCIT– Or it could be your own team


Writing the Style Guide• Start with a cover page

– If done in landscape mode with 2 columns the title/website name/author name/version number could be on the left-hand side and the table of contents could be on the right-hand side

• Begin the content by noting:– The target audience for the document– The purpose/function of the document– See the sample style guide for an example


Phrasing Rules• Write these as instructions, which means

conveying a tone of authority and being direct

• Be firm in your phrasing– Avoid ‘probably’, ‘usually’, ‘often’, ‘sometimes’,

‘maybe’ or any other hedging terminology• Maintain third person and the active voice• Never phrase rules as questions


Presenting Rules• Rules should be shown in boldface• Additional explanatory text following the rule

should be in the same paragraph and should not be boldface

• Groups and sub-groups of rules are numbered similarly to site diagrams– e.g., 2 leads to 2.1 which leads to 2.1.1– These will mirror the numbers given in the table

of contents


Uses of Explanatory Text• Useful for noting what exceptions might

occur with the rule when it is implemented. – The rule itself should not indicate the exception.

• Used to clarify why a rule is necessary. – This can educate the client and/or developer

concerning usability.• Should not be included with every rule.

– Only include when further details are deemed necessary. Some rules are self-explanatory.


Including Examples & Illustrations• For some rules you will find yourself writing

a paragraph. While brevity is good, there are times when you need multiple sentences to convey precise instructions.– In those cases it is probably good to also

include an example, generally a visual example of the rule being implemented.

• Visual examples are recommended any time when implementing the rule could get confused or mixed up in some way


Providing a Caption• Examples/illustrations should always have a

caption, which is centered below the image.• Insert the image in the flow of the

document, ideally just after the pertinent rule(s).


Sample Illustrations


Multiple Rules Per Item• For a given item (e.g., ‘Required Fields’)

there can be as many rules as are necessary. Don’t limit yourself.– It is better to chunk rules realistically and try to

ensure thorough coverage of the domain• Rules are not prioritized; they are

considered to be equally important• There will be cases where some aspect of

the website is detailed under multiple categories, using a wide variety of rules


Rules for Interface/Interaction Design• Top-Level Categories:

– Layout– Navigation– Text– Form Interaction


Layout Sub-Categories• Page Layout

– Header– Body– Footer

• Form Layout– Chunking– Starting the Form (e.g., introductory text)– Alignment– Grouping– Required Input


Navigation Sub-Categories• Global Navigation• Local Navigation• Technology• Graphics (e.g., use of alt text, using text

links or a graphical navigation bar)• Linking (e.g., unlinking/boldfacing the link or

button for the current page)


Text Sub-Categories• Fonts• Technology• Sizing

– Page Headings– Section Headings– Body Text– Secondary Text

• Capitalization• Color


Text Sub-Categories (cont.)• Emphasis

– Boldface– Italics– Underlining

• Graphical Text• Link Text

– Link Phrasing– Length


Text Sub-Categories (cont.)• Alternative Text• Introductory Text• Examples


Form Interaction Sub-Categories• Technology• Tab Ordering• Buttons (e.g., submit, reset, radio)• Checkboxes• Text Input Fields• Menus• Required Input• Input Validation• Action Confirmation


Rules for Form Design• Top-Level Categories:

– Form Planning– Layout– Text Appearance– Fields– Submission– Multi-Page Forms


Form Planning Sub-Categories• Content Chunking• Technology Considerations• Providing Examples


Layout Sub-Categories• Starting the Form• Field Labels and Input Fields• Buttons• Providing Examples


Text Appearance Sub-Categories• Fonts• Technology• Sizing• Capitalization• Emphasis• Examples


Fields Sub-Categories• Required Fields• Types of Input Fields• Standard Elements• Tab Ordering


Submission Sub-Categories• Submitting the Form• Validation• Confirmation


Multi-Page Forms Sub-Categories• Displaying Prior Information• Modifying Prior Information• Submit Button Labeling

creating a web style guide - university of michiganjwithrow/materials/styleguide.pdf · • the...

Documents