NIH Enterprise Architecture Website

Front End Design Style Guide

• Introduction
• Brand and Visual Voice
• Visual Specifications
• Templates
• Navigation System
• Content Design
• Front End Technology Benchmark

Content Design: Content Guideline

The purpose of this section is to provide standards for content included in the NIH enterprise architecture website. Compliance with the standards set forth in this guide will ensure that all content is readable; consistent in voice, tone, and style; and helpful to users as they complete their tasks on the site.

Content Voice and Tone for the NIH Enterprise Architecture Website

Brand Attributes

Brand attributes define the ideas and thoughts that a website or an organization should reinforce in the mind of the its users. They help guide creation of website content, both visual and textual, with specific words that the content should communicate directly and indirectly.

Based on the business context and user research work as well as the understanding of the scope for the NIH enterprise architecture website, we have selected the following brand attributes:

• Informative: Educate and support multiple users with multiple needs
• Valuable: Meant to be used, not just "check compliance box"
• Task-Oriented: Focus on needs and requirements of users
• Forward-Looking: Oriented to the future as well as the present
• Easy: Easy to find and use information
• Supportive: Supportive of business across NIH
• Collaborative: Fosters collaboration in content development and community building

Voice and Tone

These brand attributes need to be communicated to users from a combination of website elements that defines the overall user experience of the site. However, voice and tone of textual content have direct impact on the user experience in terms of the usability of the information provided on the website. Use the following principles, when writing content for the NIH enterprise architecture website, to be in synch with the overall brand (or personality) of the site and increase adoption of NIH enterprise architecture through useful and usable content for users.

1. Use simple words and write to educate users.
   While the site needs to present technical facts clearly, it doesn’t mean that the tone of the content surrounding the technical fact needs to be technical. Remember that some of the target users of the website such as project managers may be intimidated by too many technical terms. The NIH enterprise architecture website also needs to overcome general skepticism among NIH users about any kind of centralized standards. Select words and expressions that are simple and informative. Utilize contextual links such as Related Links and Action Links to provide supporting information for users to understand the content of the page and take appropriate actions.
2. Explain why.
   As the user research discovered, users need to justify their decision to adopt NIH enterprise architecture in their work. Clearly and promptly present why particular content on the page matters to them. Don’t wait until the end of the page to discuss it – present it up front in order to entice users to read on.
3. Clearly present actions users can take.
   To fully achieve adoption of enterprise architecture at NIH, users need to actually "use" it beyond just understanding what it is. They need to utilize architecture definitions when researching possible solutions, going through a CPIC process or sharing past IT project experiences with others. Present actions users can take in the context of the current page with clear language. Provide enough information so users know what happens when they decide to take an action.
4. Write to encourage users not just to present facts.
   Overall, tone of the content needs to be encouraging and inviting. The NIH enterprise architecture website is not just a report or policy announcement. Remember that the site is a communication tool to promote adoption of enterprise architecture at NIH and build community to support it.

In addition to these principles, please follow the General Web Writing Guide in the next section to provide effective content written specifically for the web medium. Also refer to Visual Style section of the style guide to review how these brand attributes need to be communicated in terms of visual look and feel.

Nomenclature

Primary Areas

Through participatory design sessions with end users, the project team has identified primary areas of the NIH enterprise architecture website as follows:

• About
• Your Part
• Architecture Library
• Tools & Resources

These four areas are used as main navigation menus on the website. Refer to the Screen List to review which pages are located under each area. These areas and their labels were determined based on user input and designed for scalability based the understanding of the long-term scope for the NIH enterprise architecture website. Therefore, they should not be modified without thorough examination of its impact on overall site structure and usability.

Consistency

Maintaining consistency in nomenclature throughout the site is the key to effective communication with users. Consistent use of standardized nomenclature makes it easier for users to learn how to navigate and interact with the site. Use the same word to refer to same element on the page or same action on the site.

Style

There are several style rules to keep in mind when writing or re-writing content for the NIH enterprise architecture website. Style rules are not meant to restrict writers, but to make things easier, more consistent, and clearer for users. Writers and editors should adopt and enforce a consistent style of content across the site, as it will help enforce and strengthen a uniform online brand.

Capitalization

Use title case capitalization in module titles, headlines, or subheads. In all other places on the site, the NIH enterprise architecture website uses sentence-case capitalization. With sentence-case capitalization, only proper nouns and the first word in a sentence (or the first word in a header or subheader or button) are capitalized.

Date Format

All dates in the site should be presented in an extended format (e.g., July 4, 2005).

Enterprise Architecture

Do not abbreviate "enterprise architecture" as EA. Always spell it out. Use "NIH Enterprise Architecture" (capitalized as seen) to refer to the body of work that defines the enterprise architecture at NIH. Use "enterprise architecture" (not capitalized) when referring to the program or general concept such as in "What is enterprise architecture?".

Error Messages

The site should provide error messages in plain language, without codes. All error messages should concisely and precisely indicate the error and tell readers how to recover from it. (However, when and where sensible, writers should create error messages that are as reusable as possible across the site.) Error messages should not blame the user or imply the user is at fault. They should avoid the use of emotionally charged words such as "fatal," "abort," or "catastrophic."

Punctuation of Module Titles, Headlines, and Subheads

Do not use end punctuation in module titles, headlines, or subheads, even if they form a complete sentence.

Spacing

One space follows a period in the NIH enterprise architecture website

Spelling

NIH enterprise architecture website follows standard American spelling conventions.

Web Related Terms

It is recommended that the NIH enterprise architecture website use the following conventions for Web- and Internet-related terms:

email:

One word; do not hyphenate. capitalize only at the beginning of a sentence.

Internet:

Capitalize in all uses.

intranet:

Capitalize only at the beginning of a sentence.

log in/login/log-in name:

The respective verb, noun, and adjective forms.

offline:

One word; capitalize only at the beginning of a sentence.

online:

One word; capitalize only at the beginning of a sentence.

Web:

Always capitalized.

website:

One word; capitalize only at the beginning of a sentence.

General Guidelines for Web Writing

Because the Web is fundamentally different from print media, Web writing must address problems unique to the medium. Among these are the fact that reading on a screen is more tiring than reading printed material, that readers can become confused about their location within a site, and that they often need to be guided through a particular task. Effective Web writing can address these needs when it:

• is clear
• understands and supports the objectives and voice of the site
• is respectful of users

The following Web-appropriate primer relates some basics about online content, from how users approach it to advice about how creators can shape it.

Why the Web is Different from Print

• User research shows people’s reading habits differ on the Web
• Text on screen is less inviting – people read 25 percent slower online
• Most people scan, rather than read word for word
• Each page has to compete with millions of others for user’s attention

Content Should be User-Focused

• Make text easy to scan, in chunks no longer than 50 words. Text on screen is less inviting
• Aim to reduce scrolling
• Help users find information quickly
• Avoid clutter: graphic design and written content should work in harmony
• Hook users and keep them, with compelling questions, appropriate advice, intriguing headers, and long-text-block breaking subheads

Rules for Creating Compelling Web Copy

• Be concise. The fewer words you can use, the better. Your users are busy and will need quick, clearly written, and accessible information. Short sentences will help hold their interest, and will generally provide information in the clearest manner.
• Write in simple, complete sentences. Content elements such as body copy should be written in complete sentences and should express a complete thought, whereas module titles and headlines do not necessarily have to conform to this standard.
• Activate the passive. Write: "Use active verbs and sentences." Do not write: "Active verbs and sentences should be used."
• Choose plain, concrete words.
• Maintain consistency in nomenclature, tone, language, spelling, and capitalization across the site. That way, readers can more easily recognize and scan the content they want, and won’t be confused by unfamiliar words.
• Show, don’t tell. Don’t tell users that something is "innovative" or "dynamic"; illustrate why it has those qualities. When you are discussing how useful a service is, for instance, give them concrete examples of what tasks they can accomplish with it, and how much more efficiently they will be able to complete these tasks. They’ll come to their own conclusions about how useful it is.
• Refrain from making assumptions about who will be reading your content. Write for as global an audience as possible. This means being careful to avoid language that might imply a bias or cause confusion among your readers.