The federal government’s focus on clear and understandable writing is supported by www.plainlanguage.gov. The purposes and directives for the site have evolved since its origin, necessitating revision of the site structure. Teams of students and professionals worked through a five-phase framework to organize and manage the change process. Their strategy started with gathering data on stakeholders’ priorities and what worked and didn’t work on the existing site structure. The redesign team developed several personas representing various types of anticipated site users and their specific needs. They evaluated the collected data from these perspectives and identified real users’ top tasks. To organize content semantically, the team developed a taxonomy with four primary facets and built out the taxonomy following standard principles of vocabulary control. Two taxonomy versions emerged, providing site navigational labels and metadata to mediate retrieval. The teams developed, tested and revised mock-ups until the final stage of the effort produced a new site design having an arrangement of text, labels, links and relationships that better supports the site’s new mission as the design continues to evolve.

information architecture
planning
design
evaluation
index language construction
case studies

Bulletin, August/September 2011


An Information Architecture Story: Reshaping www.plainlanguage.gov to Meet Changed Needs

by Thom Haller

Have you ever asked, “What do people do when they develop a site architecture – especially if there is little time and no money?” 

If so, this article’s for you. 

Background
I teach information architecture/user experience classes to adults in the Washington, D.C. area. Typically, the class consists of current or beginning practitioners who want to further explore the field. It also includes people who have a passion for information structure and helping others, workers who are changing direction in their jobs, and, often, people who have never heard of the terms but think it all sounds somewhat fascinating. 

Class participants often work on projects so we can experience some of the real-world challenges faced by people in the field. Several years ago, the class reshaped www.plainlanguage.gov to give it usable structure. I was proud of our work and described it in a 2006 Bulletin article [1]. Our finished product supported federal writers who were looking for resources on writing more clearly. But the site, highlighting definitions and benefits, also was positioned as an argument that government writing could be clear and understandable. 

Figure 1
Figure 1. PlainLanguage Site (Before)

Then times changed. In a 2011 Bulletin column, I identified the changes that had affected the global architecture. (Figure 1 illustrates these changes. Notice how the front page “map to site content” was removed from the 1996 build-out.) But what captured my attention more than anything else was how the rhetorical needs of the site had changed [2]. 

Thanks to new legislation, the site had a new purpose – it now serves as the “go-to location” for federal guidance on writing to support citizens and information on how agencies can comply with federal legislation. In fact, guidelines are the key to the new site structure. 

So once again, I volunteered my students and a bevy of local content professionals. Together we gathered data on the site’s mission and goals from the perspective of both stakeholders and typical site users; we learned about different audiences and their priorities on the site; we clustered content, identified labels and compared our labels to those of other researchers; we developed and tested prototypes, incorporating what we learned; and we aligned the current structure with a larger taxonomy that will support continued development of the site. (See the accompanying sidebar, “Exploring the Taxonomy Underlying www.plainlanguage.gov by John Heffernan.)

To explain our work, I use a five-phase framework. The phases themselves have a waterfall-like structure in that each could end with products for client sign-off. We operated in a more fluid, almost agile manner – trying to incorporate client input as often as we could and presenting only one official “deliverable” during the 10 weeks of class.

The framework can be divided into five sections: Gathering, Evaluating, Chunking, Knowing/Testing and Optimizing.

Phase I. Gathering
Our project differed from a work project in that we had two groups working independently at first. (We were also 100% volunteer.) The project included students (who were learning about the field and not immediately ready to plunge into a project) and volunteers on a content strategy work team. It was the second set of folks who primarily dove into early discovery and analysis.

Table 1 identifies six steps we followed during the gathering phase.
Table 1

Phase 2. Evaluating
During the second phase of our architecture project we looked at the data we had gathered and began to evaluate it, asking, “What data is important to whom?” 

As we began to collect data, we viewed it “through the eyes” of actual users by interviewing members of distinct user groups. We developed brief personas to give us a visual understanding of different audiences. 

Three questions served as the foundation for evaluation at this stage:

  • Who are the audiences?
  • What do they want to do with the information?
  • What is the context in which they will use information?

By concentrating on these seemingly simple questions, we are able to identify content that deserves priority status – those elements in the site that might be made visually important on a fully articulated website. We can identify content that matters most to people and contrast it to the content that means little to people. Prioritizing helps us as we move to the next phase of the project – clustering content in groupings and relationships to support different audiences. 

These steps are identified in Table 2. 

Table 2.  Evaluating
Table 2

Phase 3. Chunking
To build web structure (or to structure any document) we need to decide how discrete elements relate to each other and how they might be ordered so audiences experience them in a certain way. 

In the third phase of the plain language project, our groupings and conversations (and those of our colleagues working through the GSA) served as the basis for initial renderings – rough prototypes showing how we might arrange the content in the web environment. Our intent was to develop low-fidelity prototypes that articulate structure and serve as the basis for moving forward. I helped organizations bring content together for testing. (Table 3). 

Table 3. Chunking
Table 3

Phase 4. Knowing (Testing)
Knowing how users think is essential in developing web structure. We have often seen how, with little cost, we can quickly get feedback on usable information structures. 

During the fourth phase of our architecture project, we continued to fill in the blanks by testing possible structures and revising mock-ups accordingly. We also related our choices back to the research (Table 4). 

Table 4. Knowing/Testing
Table 4

Phase 5. Optimizing
By the end of the 10-week class, we had identified two designers to support the plain language development team in creating the new site. We also wanted to ensure that the content recommendations – placement of text, links and relationships – reflected the guidance we had received throughout the project. 

So as the final phase in our work, our content strategy team worked to optimize the site to ensure it supported the measures of success identified at the beginning of the project. We also worked with other volunteers to ensure that page-level text provides people with the content they need to get their jobs done. Our optimizing tasks are identified in Table 5.

Table 5. Optimizing
Table 5

Next Steps
So how did we do? Figure 2 shows an architectural mockup of the home page. Class has ended, but several volunteers are working with the Plain Language Action and Information Network to migrate content (both old and new) into the new architectural framework. We plan to continue to study the site in another IA/UX class – next time tackling the challenges (and taxonomy) of examples and better relating those examples to writing guidelines.

Figure 2. The PlainLanguage site (After) – In progress.
Figure 2

Summary:  Highest-Ranking User Tasks

  • Find self-guided plain language training materials
  • Download checklists that support plain language writing styles
  • Learn what documents are considered "covered" in the Plain Writing Act
  • Find best practices in plain writing
  • Find out what "continuing compliance" with the Plain Writing Act means
  • Get information on plain language/clear writing news and events
  • Download checklists that support plain language writing styles in print documents
  • Download plain language style guides
  • Find the full text of the Plain Language Act
  • Join an online social network/forum to communicate with other plain language liaisons
Personified Clusters-
Strategy for Thinking about user Groups and What They Want from the Site
_______________________________________________
Plain Language Liaison
  • Find guidance and requirements of the Act
  • Set up plain language program at agency
  • Find out the requirements fro plain language area of website

Writer's Manager

  • Find out if the Act applies to the agency's intranet or only to the public-facing website
  • Find out whether the Act applies to new content only or also to existing content
  • Locate tools to evaluate compliance

Manager

  • Review OMB and PLAIN guidance
  • Communicate requirements to agency employees
  • Learn what needs to be done to set up website required by the Act
 High-Level Manager
  • Find out the Act's general requirements
  • Find out the deadlines for complying
  • Oversee writing of compliance documents

Plain Language Advocate

  • Find guidance and requirements of Act
  • Set up plain language program at agancy
  • Find out requirements for plain language area of website
  • Find out what "continuing compliance" with the Clear Writing Act means
  • Communicate plain writing requirements to employees
  • Find detailed information about implementing the Act
  • Find suggested approaches for setting up a plain language program at an agency
  • Find suggested approaches to training employees in writing clearly/using plain language

Resources Mentioned in the Article
[1] Haller, T. (2006, April/May). IA column: Information architecture success story: The development of www.plainlanguage.gov. Bulletin of the American Society for Information Science & Technology, 32(4), 27. Retrieved July 11, 2011, from http://www.asis.org./Bulletin/Apr-06/haller.html>

[2] Haller, T. (2006, April/May). IA column: The ouch factor: What happens when user needs change. Bulletin of the American Society for Information Science & Technology, 37(4), 48-49. Retrieved July 11, 2011, from http://www.asis.org/Bulletin/Apr-11/AprMay11_Haller.html>

Thom Haller serves as the IA editor for the Bulletin and teaches principles of performance-based information architecture and user experience. In Washington, D.C., Thom teaches IA/UX classes at The Graduate School, where he launched one of the initial classes in IA (1998). A writing teacher and believer in clear writing, Thom lead the effort to reshape the plain language site in 2005. He served as director for the Center for Plain Language in 2006/2007. Thom can be reached via email at thom<at>thomhaller.com, or @thomhaller on twitter.