Skip to main content

Graphics & Style Guide

Graphics and marketing materials for SWAN and the services we support.

Graphics & marketing resources

Logos

Full color

Greyscale, black text

Greyscale, white text

Monotone 

Only for use on transit labels and other printed materials where greyscale and full color are not available.

Color Palette

The SWAN color palette is drawn from the colors available through the Material Design system. We use 5 core colors, each of which has a dark and light version to use as accent colors. 

We must follow accessibility standards for color contrast when using this palette for text elements, including links, buttons, and other text elements. Color contrast is determined by both the font-size and the contrast between the foreground and background colors.  

 

Primary color 

Use the primary color for interface elements containing text, such as buttons and links. This color meets accessibility standards for text on a white background at any font size. 

Cyan #00838e 

Light: #4fb3be

Dark: #005661

Secondary colors 

Use these in addition to the primary color. Some of these colors can be used as text where indicated. Some can only be used for accents or background colors to dark text. 

Pink #AD1457 

For text, use at any font size and on a white background.  

Light: #e35183

Dark: #78002e

Blue #1565c0 

For text, can use at any font size on a white background. 

Light: #5e92f3

Dark: #003c8f 

 

Orange #c63f17

For text, can use at any font size on a white background. 

Light: #ff7043

Dark: #8e0000

 

Yellow #fdd835 

Use as an accent or background for black text. Do not use as text on a white background.

 

Body text & gray-scale colors

Body text should generally be dark gray(#666666) or black(#000000) on white for readability.

On web properties, we use a light gray, #f5f5f5, for backgrounds. 

Use the Gray 50 palette in Material Design to select additional gray-scale colors for graphics and interfaces.

Status colors 

Often we need to represent a status in an interface. The following color pairings are suggestions if you have the option to customize a status. If an interface doesn't allow you to customize the errors and alerts, that is okay - just try to generally follow the suggested color/status pairings.

Red: Error status 

  • Text on white background: #c62828
  • Background with black text: #fbe9e7 

Green: Success status 

  • Text on white background: #2e7d32
  • Background with black text: #e8f5e9 

Yellow: Warning status 

  • Background with black text: #fff9c4 

Blue: Informative status 

  • Text on white background: #1976d2
  • Background with black text: #b2ebf2 

Typography

Primary typefaces 

  • Source Sans Pro, an open-source sans serif typeface
  • Georgia, a widely supported serif font used for some headings 

Secondary typefaces 

If our primary fonts are not available in a system, you may use: 

Font stacks 

 In our web properties, we use the following font stacks: 

  • Georgia, serif;
  • “Source Sans Pro”,-apple-system, BlinkMacSystemFont,“Segoe UI”, “Roboto”, “Oxygen”, “Ubuntu”, “Cantarell”,“Fira Sans”, “Droid Sans”, “Helvetica Neue”, sans-serif; 

We attempt to mostly use native system UI fonts on web properties to improve performance and display. 

Font pairings & styles 

Title(Print Only) 

Font: Source Sans Pro, regular or semibold, font-size 5xbody text; 

Heading 1 & Web Title

Font: Georgia, regular

This is a heading 2

Font: Georgia, regular

This is a heading 3 

Font: Source Sans Pro, bold

This is a heading 4

Font: Source Sans Pro, italic, regular

This is a heading 5 

Font: Source Sans Pro, bold

Body text is Source Sans Pro regular at a minimum size of16px.

Printable list of SWAN libraries with a map.

EBSCO

Search by product (database) name and filter by resource type for quick access to print bookmarks, handouts, posters, and so much more! Many of these allow for libraries to upload logos and type in additional information.

Consumer Reports

Available graphics and printable, editable materials for spreading the word about your subscription.

ComicsPlus

ComicsPlus logos and marketing material available for print. These appear to be non-editable, but nice variety of posters and bookmarks, as well as Social Media Posts.

eRead Illinois

Graphics and editable templates for marketing materials, including posters, signs, and bookmarks. 

*must be signed in with L2 credentials to view

CloudLibrary

Editable bookmarks

Hoopla

Ready to print, non-editable.

Getting Started with Hoopla materials:

All materials above plus additional materials:

Kanopy

Flyer and graphic available to download and print. Not editable.

OverDrive

Free resources that can be completely customizable as well as ready-to-print brochures, flyers, graphics, bookmarks and so much more!

Content style guide

Adapted from the 18F Content Guide.

Address the user

Address the user as “you” whenever possible to refer to the primary audience for the page or site. If you need to use “member” or “patron”, use it as a descriptor of “you” --“As a member of SWAN, you can…”, “As a SWAN patron, you can..”

Avoid duplication

Duplicate content creates poor search results, confuses people, and damages our credibility. If users find two pieces of content that say different things, they will be more likely to open a ticket, or worse, give up.

Before you write new content:

  • Do a Google search--does the content already exist in SWAN support, or an external site such as the RAILS website or SirsiDynix Support?
  • Ask yourself, “Is SWAN the most authoritative source?” Do we control this information?
  • For content that already exists, we should either link to the most authoritative source, or trust that our members will find it if it comes up easily in a search.

Sometimes it will make sense to write on the same topic for different audiences (e.g. holds management for patrons vs. library staff).

Be concise

Do the hard work to make it simple. Concise writing is harder to write, but easier to read, than wordy writing. Save our members time, and take the time to edit your writing.

  • Use short sentences of 25 words or fewer. Sentences longer than 25 words are more difficult to understand.
  • Vary sentence length to make your writing more interesting.
  • Don’t let caveats dictate grammar: “You can...” not, “You may be able to...”
  • Use pronouns, base verbs, and active voice, and avoid unnecessary modifiers, e.g. "We updated your configuration," not "The configuration for your library has been updated by SWAN staff."
     

Use plain language

Use plain language that our members understand.

  • If you need to use jargon and acronyms, include context and clear explanations.
  • Minimize definitions - if you need them, define words as you go and avoid a list of definitions.
  • Use words consistently - see the terms list.
  • Short words are faster to scan than long words.
  • Active voice is easier to read than passive voice.

Structure the content

People read differently on the web than they read print -- they tend to skim, scan, and read only about 25% of the text on the page.

  • Put the most important information first, in inverted pyramid style.
  • Break up text--use short paragraphs, headings, bullets, and numbered lists.
  • Avoid FAQs. They’re difficult to scan, and they’re usually duplicating content that is (or should be) in other areas of the site.    

Make content web-first

Create your content so it is easier for our members to read and search online, and easier for content authors to maintain over time.

  • PDFs, Word Docs, Excel files, and PowerPoints can’t be read on all devices and often require proprietary software.
  • It is easier to update, link to, and search HTML content.
  • HTML content doesn’t “orphan” the user in a new place -- they still have the site’s menus, navigation, and structure.
  • HTML content is responsive--our members can read it on any device.
  • HTML content can also be printed or saved as PDF.


There are some situations where a non-HTML format is appropriate:

  • Information meant to be downloaded and used in a spreadsheet format, such as statistics
  • Presentation slides for a workshop or meeting

In these cases:

  • Include a last updated date in the document.
  • Include the URL where the document can be downloaded.
  • Avoid using a format that requires specific, proprietary software (e.g. Microsoft Word, PowerPoint, Excel).

Note: Presentation slides are never a substitute for information that should be in HTML. Policies, documentation, and other forms of content should be updated as HTML content before or very shortly after the presentation.

Maintain, refine, & retire

Regularly review and update your content. Take advantage of regularly scheduled content audits, but don’t wait to update your content if new information becomes available or older policies and procedures change.

Review web analytics for:

  • Pages with high and low traffic
  • Pages with high and low reading times
  • Common search terms
  • Common user flows

Review tickets for common issues and questions --this could be a sign new documentation is needed.

Your content may need to be archived or deleted as it becomes outdated or redundant. Be thoughtful about deleting content and plan for URL redirects and other tools to help users that are used to finding that content. When it doubt, it is easier to archive or unpublish than re-create from scratch!

Right content, right place, right time

When you create a new piece of content, consider the best content type and location for it. Always ask:

  • Does this need a new page, or is it better as an addition to another piece of content?
  • Where should it go in the main menu?
  • What are related areas of the site that should link to the new content?
  • Are there any tags, categories, or other taxonomy items that your content will need?
  • Remember, not everyone searches -- all content needs to be findable by browsing, too.

See Content Types for more guidance on the right place for your content.

Audiences

Audiences we serve, in priority order, include:

  1. Patrons
  2. Member library staff
  3. SWAN board, committee, and user group members
  4. SWAN Staff
  5. Potential members
  6. Peer institutions and consortia

Page titles

Titles organize pages and guide readers. A title appears at the beginning of a page or section and briefly describes the content that follows.

Titles are (you guessed it) in title case (every word capitalized except for a, an, and the).

Don’t use punctuation in a title unless the title is a question.

H1 is reserved for titles.

Headings and subheadings

Headings and subheadings organize content for readers. 

Headings (H1) give people a taste of what they’re about to read. Use them for page titles only.

Subheadings (H2, H3, etc.) break articles into smaller, more specific sections. They give readers avenues into your content and make it more scannable.

Headings and subheadings should be organized in a hierarchy, with heading first, followed by subheadings in order. (An H2 will nestle under H1, an H3 under H2, and on down.)

Include the most relevant keywords in your headings and subheadings, and make sure you cover the main point of the content.

Be consistent with how you phrase titles. If your guide or tutorial has several pages, stick to the same naming convention for scannability, such as:

  • Nouns: Policies, Teams, Offices
  • Verbs: Create an account, File a report, Download our data

Use title case for page titles (h1). Use sentence case for subtitles H2 and smaller. In sentence case, you do not capitalize every word (you write it as a sentence).

Links

Use links to point users to relevant content and trusted external resources.

Don’t include preceding articles (a, an, the, our) when you link text. 

Examples:

  • Yes: Read the reports and statistics guide for details.
  • No: Read the reports and statistics guide for details.

    
If a link comes at the end of a sentence or before a comma, don’t link the punctuation mark.

Don’t say things like “Click here!” or “Click for more information” or “Read this.” Write the sentence as you normally would, and link relevant keywords. 

The same link text with different links is an accessibility violation.

Buttons

Buttons should always contain actions. The language should be clear and concise. Capitalize every word, including articles. It’s OK to use an ampersand in button copy.

Examples:

  • Log In
  • Sign Up
  • Contact Us

Lists and instructions

Use lists to present steps, groups, or sets of information. Give context for the list with a brief introduction. 

Number lists when the order is important, like when you’re describing steps of a process. 

Don’t use numbers when the list’s order doesn’t matter.
    
Use clear verbs to tell readers how to interact with interface elements:

  • Choose from drop-down menus.
  • Select or deselect checkboxes and radio buttons.
  • Click or tap buttons.
  • Follow or open links  

Emphasize the interface label, e.g.

  1. Enter your Library Card Number and PIN
  2. Click Log In

Use the greater than symbol > for hierarchical menus:

  • In the Circulation menu, go to Reports > Annual Reports > Current Annual Report

Images and screenshots

Images must use alt text.

Images should not be the only method of communication, because images may not load or may not be seen. Avoid using images when the same information could be more clearly communicated in writing. See tips for when to include images.

Avoid the ‘zig-zag’ image layout. Format images all to the left or right on a page.
Avoid using images of fonts. If you need to use a screenshot, aim for high contrast between your font and background colors. 

Add images using the image icon in the body text editor: 

Alt text

Alt text is a way to label images, and it's especially important for people who can’t see the images on our site. It also improves search results. 

Alt text should describe the image in a brief sentence or two. 

When you upload an image you will be prompted to add alt text:

Format

Photographs should be in .jpg format. 
Screenshots and graphics should be in .png format.

Screenshots

Take screenshots of what your user sees, and avoid screenshots of the entire screen - this can be overwhelming and hard to read.

Focus on the specific element you are demonstrating, with just enough context the user knows where the element is on the screen.

Video

Videos must include closed captions. YouTube provides instructions to edit and add closed captions.

Consider these additional best practices for video content.

Tables

Tables are only for tabular data: two or more “objects” (rows) that share two or more “values” (columns). 

Add tables as a page section, or in the body text editor.

In tables, column widths are the same for all rows, which can make them easier to scan visually. 

Tables are easily navigable for sightless users so long as the content is organized in a logical way. Here are some other guidelines to consider:

  • When listing numbers, it’s good practice to align them to the right of their cell, with the same decimal precision (“40.50” and “1.00”) so that the numbers are easier to compare while scanning.
  • Always align column headings up with the values in the columns. For example, numeric column headings should be aligned right if the values are, too.

View guidelines for accessible tables from WebAIM.

Files

Only use files for content that is meant to be offered in print, or downloaded and manipulated. For example, a patron brochure or a dataset in spreadsheet form. 

Always include the file format in a link to a file.

For meetings or agendas, include the date created or the meeting date as YYYY-MM-DD first, followed by an underscore. For other documents, do not include a date.
Always separate words with an en dash (-). Don’t use spaces.

  • Examples:
    • 2020-01-01-agenda.pdf
    • 2010-01-01-minutes.pdf
    • usability-testing-handbook.epub

Linking conventions

Include the document format in the link, at the end of the description in parentheses.

  • Examples:
    • Download the Usability Testing Handbook (PDF)
    • Download the Membership Map (PNG)

Formats

Offer documents most widely available format, while also including an editable source when necessary.


For example, include a brochure as a Word file and as a PDF. 

Updating files

It is always preferred to update a file instead of uploading a new version. Then the same link will work, and display a new file.

Abbreviations and acronyms

Spell out an acronym the first time it is used. Then use the short version for all other references. If the abbreviation isn’t clearly related to the full version, specify it in parentheses.

Example:

  • First use: BLUEcloud Analytics (BC Analytics)
  • Second use: BC Analytics

Active voice

Use active voice. Avoid passive voice. 

In active voice, the subject of the sentence does the action. In passive voice, the subject of the sentence has the action done to it.

  • Yes: Merle logged into the account.
  • No: The account was logged into by Merle.

Capitalization

Title case capitalizes the first letter of every word except articles, prepositions, and conjunctions. Sentence case capitalizes the first letter of the first word.

Titles are in title case. 

Headings and subheadings are in sentence case (H2, H3, H4, etc.) -- In general, just always use sentence case unless it's a title. When writing out an email address, use all lowercase. 

Don’t capitalize random words in the middle of a sentence. Do not capitalize: website, internet, online, email.

The exception is if you are writing interface instructions and exactly transcribing a button or link. 
Example:
    • Go to Events > Add Event

Use title case for job titles. Example: The Executive Director will lead the presentation.

Capitalize the first letter of an item in a list. Example:

  • Beans
  • Potatoes
  • Cornbread

Commas

We use the Oxford comma - use a comma after the first two, before the “and”.

Example:

You can check out DVDs, books, and audiobooks.

Contractions

Feel free to use contractions.

Dates and times

Days of the week

Abbreviate days as on three letters:

Sun., Mon., Tue., Wed., Thu., Fri., Sat.

Months

Abbreviate months as:

Jan., Feb., Mar., Apr., May, June, July, Aug., Sept., Oct., Nov., Dec.

Time of day

When writing time, use “a.m.” and “p.m.”, lowercase.

All-numeral dates

Use the forward slashes between months, days, and years if writing the date out numerically. Always include the year.

Example: 10/29/2018

Times

Always include the full time, and use periods in a.m. and p.m.

  • 9:00 p.m.
  • 9:30 - 10:00 a.m.
  • 11:30 a.m. - 12:00 p.m.

File names

Always save file names with a hyphen between each word. This improves search indexing.

Don’t include spaces in file names. Use all lowercase. 

Example: library-calendar-widget.png

For links to files, always include the file extension at the end of the link label, in parentheses. Put file extensions in all caps. If the file is over 1MB, include the file size rounded to the closest whole number.

Example: 
Download the My Accounts brochure (PDF - 20MB)

Numbers

Spell out numbers that begin a sentence. Otherwise, use a numeral. All numbers more than three digits get commas, unless it is a barcode.

Barcodes should be written with no dashes, commas, or spaces, as it would be used in the application software.

Examples:

  • Two libraries join SWAN, 1 leaves
  • 999,999,999
  • 21140001280758 (barcode

Phone numbers

Write phone numbers as (xxx) xxx-xxxx when displaying contact information for SWAN staff.

Otherwise, use the formatting required in the interface or software. For example, if Workflows uses the format XXX-XXX-XXXX, in documentation about entering phone numbers into Workflows use 312-555-5555.

Symbols

Use the % symbol for percentage.

Use the & symbol in titles, but use “and” in body text and headings.

Titles for books, etc.

Book titles, movie titles, and other specific titles available for checkout should be italicized. If italics aren’t available, use quotation marks. Follow heading capitalization rules for documents, blogs, and materials.

Writing about people

Also see the Diversity Style Guide and Disability Language Style Guide

Age

Don’t reference a person’s age unless it’s relevant to what you’re writing. If it is relevant, include the person’s specific age, offset by commas: The CEO, 16, just got her driver’s license. Don’t refer to people using age-related descriptors like “young,” “old,” or “elderly.”

Disability

Don’t refer to a person’s disability unless it’s relevant to what you’re writing. If you need to mention it, use language that emphasizes the person first: ”she has a disability” rather than “she is disabled.” When writing about a person with disabilities, don’t use the words “suffer,” “victim,” or “handicapped.” “Handicapped parking” is OK.

Gender and sexuality

Don’t call groups of people “guys.” Don’t call women “girls.” Avoid gendered terms in favor of neutral alternatives, like “server” instead of “waitress” and “businessperson” instead of “businessman.”

It’s OK to use “they” as a singular pronoun.

Use the following words as modifiers, but never as nouns:

  • lesbian
  • gay
  • bisexual
  • transgender
  • trans
  • LGBT

Don’t use these words in reference to LGBT people or communities:

  • homosexual
  • queer
  • lifestyle
  • preference

Don’t use “same-sex” marriage, unless the distinction is relevant to what you’re writing. (Avoid “gay marriage.”) Otherwise, it’s just “marriage.”

When writing about a person, use their preferred pronouns. If you’re uncertain, just use their name.

Hearing

Use “deaf” as an adjective to describe a person with significant hearing loss. You can also use “partially deaf” or “hard of hearing.”

Medical conditions

Don’t refer to a person’s medical condition unless it’s relevant to what you’re writing.
If a reference to a person’s medical condition is warranted, use the same rules as writing about people with physical disabilities and emphasize the person first. Don’t call a person with a medical condition a “victim.”

Mental and cognitive conditions

Don’t refer to a person’s mental or cognitive condition unless it’s relevant to what you’re writing. Never assume that someone has a medical, mental, or cognitive condition.

Don’t describe a person as “mentally ill.” If a reference to a person’s mental or cognitive condition is warranted, use the same rules as writing about people with physical disabilities or medical conditions and emphasize the person first.

Vision

Use the adjective “blind” to describe a person who is unable to see. Use “low vision” to describe a person with limited vision.
 

  • Acquisitions
    • If describing software, be sure to use the full name of the software,  e.g. BLUEcloud Acquisitions. Subsequent reference can use the accepted vendor abbreviations, e.g. BcAcq.
  • Article Search
    • Use for the public-facing display of the EDS API integration in Aspen.
  • Aspen
    • Use Aspen Discovery for the first mention, and Aspen for subsequent references.
  • BLUEcloud
    • BLUE is always in all caps, cloud is lowercase.
    • Proper full abbreviation is "BC" and the product name, e.g. "BC Mobile". SirsiDynix has adopted the standard of BcProduct, which is acceptable.
    • BLUEcloud Analytics or BcAnalytics
      • Do not use BCA.
    • BLUEcloud Acquisitions or BcAcq
    • BLUEcloud Cataloging or BcCat
    • BLUEcloud Circulation or BcCirc
    • BLUEcloud Mobile
  • Bibliographic Services
    • Bib Services is also acceptable.
    • Do not use BS.
  • Catalog
  • Cataloging
  • Checkin and checkout
  • Circulation
  • Circulation Policy
    • Use to describe the SWAN Circulation Policy. Use Symphony policies to describe policies in the Symphony software.
  • The Current
    • This is the official SWAN newsletter
  • Custom Long Overdue Report
    • Do not use CLR
  • Discovery system(s)
  • Documentation
  • EBSCO
    • Use the acronymn not the full name spelled out
  • EBSCO Discovery Service (EDS)
    • Use to refer to the system, but not the public-facing integration in the discovery system--use Article Search instead
  • E-Audiobook
  • E-Book
  • E-Video
  • Electronic resources (E-Resources)
  • eResource Central (eRC)
  • Forums
    • Use SWAN Community Forums
  • Integrated Library System (ILS)
  • In-transit
  • Interlibrary Loan (ILL)
  • Information Technology and Systems Support (IT)
    • Okay to use IT on its own.
    • Only use ITSS internally, use IT in anything member facing.
  • MailChimp: Always use the name of the newsletter, not MailChimp.
  • MARC
    • Use the acronym not the full name spelled out
  • Members
  • Membership
  • Nonfiction
    • Do not use non-fiction (no dash).
  • Online Patron Registration
    • Do not use OPR.
  • OPAC
    • Use the acronym not the full name spelled out. Use for library catalog computers, e.g. OPAC stations.
  • OpenAthens
    • Abbreviate as Athens, not OA
  • OTRS: Use Ticketing System or OTRS Ticketing System. Spelling out the acronym is not necessary.
  • Pre-cat
    • Use as you would a common noun - don't capitalize in the middle of a sentence, and "cat" is not capitalized.
  • RAILS
    • Use the acronymn not the full name spelled out
  • RDA
    • Use the acronymn not the full name spelled out
  • Serials (also Periodicals, Magazines)
  • SirsiDynix
    • Use to refer to the vendor, or as a descriptor of software. Do not use to refer to software as a standalone term, e.g. SirsiDynix Symphony WorkFlows. Do not use Sirsi, always SirsiDynix.
  • SWANcom
  • SWAN Community Forums
  • Symphony
    • Use to refer to the ILS, but use WorkFlows to refer to the staff client.
  • Training
    • Use to refer to an in-person training event or a synchronous, online training event (with a specific time).
  • Tutorial
    • Use to refer to an online, asynchronous tutorial (that can be viewed at any time).
  • User Experience (UX)
    • Okay to use UX on its own.
  • Webinar
    • Use online training instead.
  • Wizard
  • WorkFlows
    • The "F" is always capitalized.
    • Use lowercase "workflows" for a process not related to the application.
    • Use WorkFlows in place of SirsiDynix Symphony WorkFlows.

7 steps for technical writing

  1. Define your audience and scope
  2. Plan
  3. Research and write
  4. Test, review, and revise
  5. Deliver
  6. Evaluate and get feedback
  7. Revise, archive, or remove

 

Define your audience and scope

This is the who, what, and why: Who are you writing for, what do they need to know, and why do they need to know it.

Choose a persona - this can often be a real-life person representative of your audience. "Representative" is the key phrase here: Write for the rule, not the exceptions.

  • What do they already know?
  • What do they need to know and why?
  • What is the real-life context, where and when will they need to know it? 

Plan

Define the how, where, and when.

  • Where is the best place to put this information? Think about where your persona will need it and where they'll be most likely to find it.
  • When does it need to go live? Plan out your timeline.
  • Who do you need to get involved to help you or to consult with?
  • How are you going to test and review it, and make sure you get the feedback you need?
  • Will you need video or graphics? How are you going to create those?

Research and write

Consult with other experts, spend time with the interface, and do the research you need to make sure your documentation is accurate and meets the needs of your persona.

  • Define the information your persona needs to know using a task-based approach.
    • Map out steps into smaller, achievable parts.
    • Think of each part as a block you can move around - it should make sense on its own.
    • Assume people will skip over parts and skim.
  • Don't assume anything about your persona.
    • If you assume things they don't know, they will be lost.
    • If you talk down to them, they will be offended and won't use what you create.
    • Define jargon and acronyms.
  • Be clear and precise.
    • Use active voice.
    • Avoid long paragraphs and dense blocks of text.
    • Only use graphics that support learning - don't use irrelevant decorations.
    • Check your capitalization, punctuation, and style - consistent formatting and terms helps with clarity.
    • Edit and then edit some more - most documentation is better if it is shorter.

Test, review, and revise

Always have someone edit your documentation. You may want to have multiple editors, one for style and one for content. Whoever it is, make sure they feel comfortable critiquing you and that you don't let your ego get in the way. 

When you are the one editing, look for:

  • Accuracy
    • Are the steps and information correct?
    • Does it meet style guide standards?
  • Simplicity
    • What can be cut?
    • Is there passive voice, jargon, or acronyms?
    • Is there information that lives elsewhere that could just be linked to?
  • Effectiveness
    • Does this do its job?
    • Is it super boring or hard to read? How can you make this more digestible.

Deliver

Make your new documentation live to the membership. To do this:

  • Publish and check permissions - make sure the people who need to access it can.
  • If it is a new page on a website, make sure it has a place in the menu structure.
  • Share your work through the appropriate channels: email lists, the SWAN Community Forums, user group meetings, etc.

Evaluate and get feedback

Once your documentation is in the real world, you will find out if it is working or not.

Monitor statistics and use - very low use might be a sign your documentation should be moved to another location or that it is not valuable to your audience.

Be prepared to make changes based on feedback from your audience, whether that is library directors, patrons, or another group.

Revise or remove

Documentation often has a limited lifespan - hardware, software, and websites change regularly, we add and remove services. Documentation takes more maintenance effort than other types of content, so be prepared to manage it through it's full lifetime.

To help with this process, the UX team leads a yearly content audit.