Emergency Response Division Intranet

An intranet to help scientists, developers, and support staff of NOAA’s Emergency Response Division locate and leverage office resources

Overview

Thousands of incidents occur each year in which oil or chemicals are released into the environment as a result of accidents or natural disasters. The Emergency Response Division (ERD) of NOAA's Office of Response and Restoration provides scientific expertise to support an incident response. 

ERD has thousands of files located in dozens of locations, with no standard documenting or filing process. ERD leadership formed the ERD Intranet team to create a system through which team members could locate information they need for their day-to-day operations.

Planning

Our card sort results spread across the table at team meeting

In order to set the scope of the project, our team began by creating three criteria to determine if files would be included or linked to from the site:

  • Static

  • Widely used

  • Either commonly used or of critical importance

We then had to inventory and audit all of our existing and new material to determine if it fell into these categories.

In addition, the platform we chose for our tool would largely impact the structure and organization of its contents, so we tackled this question early on. We had two primary options:

  1. Integrate our content into an existing Intranet that served our team as well as several others

  2. Create a new intranet on a low-barrier platform like Google Sites that could be catered to the specific needs and tasks of our team members

This was a challenging and somewhat political decision. Ultimately, we decided to build a Google Site that would complement the other Intranet, since this choice would give us the freedom to structure the content and hierarchy in ways that specifically catered to ERD users. Additionally, our office has more familiarity with Google than they did with Drupal, which would help ensure that the site was maintained.

Research

ERD encompasses responders, scientists, developers, outreach specialists, and more. With such diverse needs and day-to-day tasks, we knew it would be important to hear from each type of role in order to make the site usable for them. However, when there is a conflict of needs, it’s important to have a clear prioritization of users. We decided to prioritize the needs of our responders, since their needs are often the most urgent and have the biggest implications if not filled.

We already had a criteria for choosing what content would be included on the site, but we weren’t sure how to organize that content. We created some rough buckets that would translate to tabs within the Intranet navigation, and used an online card sort to see if our users categorized the content similarly or differently from our team.

Through the card sort, we found a few major trends: 

  • Users found some tab names too similar to distinguish where content should be placed.

  • Some labels that were crystal clear to our team confused our users. This trend came through in the moderated card sorts, although it was more pronounced in the user testing (discussed below).

  • Some users proposed a completely different restructuring than what we had originally envisioned. This led us to remove some tabs and add some new ones.

Design

The structural and navigational design of the site was largely completed through our card sort analysis. The visual design of the site was limited by the options within Google Sites, but still gave us enough flexibility to convey the nature of the site to our office users.

Testing

The use cases we had articulated for the Intranet proved very helpful in user testing. Our scenarios reflected the activities that users in different roles (responders, developers, biologists, etc.) would encounter, and allowed us to provide real-life situations to a variety of users and see if they could use the Intranet to solve their problem. We learned that there are a few very distinct working styles among our office—the “I’d just use the search bar” method, or the “I’d read every navigational heading” method. We had already put a lot of effort into ensuring that our navigational structure was sound, but this led us to double-check the search feature to ensure that content was labeled properly and coming up as-expected in searches.

Results and Learning

One of my biggest takeaways from this project was the importance of personal outreach when soliciting feedback. We first sent out an email blast asking individuals to complete the card sort, and about a third of the office responded. After sending personal emails to staff who had not yet participated, participation rates nearly doubled, raising participation from 31% of the office to 65%. Individual and personalized outreach isn’t something that every project has the luxury of using, but when getting feedback really matters, I’ll definitely build in time and funds to allow for personal outreach to participants.