The problem

The Evergreen State College has a unique academic structure that presents special challenges for students planning their degrees. As students moved from skimming a printed catalog to browsing and searching online over the last decade, they came to expect more. Our team’s challenge was to match the special challenges of the technology and content with the audience’s expectations for this top feature of the website.

Unique challenges

• No majors, no departments: students at Evergreen do not have majors, and the college is not organized into traditional departments. Instead, students build their own course of study based on their interests, and faculty associate in looser affiliations for planning. Additionally, most courses are a full 16-credit load with multiple subjects and faculty, and some offerings may last two or three quarters as well. While this model can be intellectually empowering, it also creates a lot of cognitive load when selecting what to take.
• Frequently changing curriculum: within this structure, faculty also have flexibility to try new courses, with major changes, almost every year, and sometimes even from quarter to quarter. While some courses have been stable for many years, particularly in the sciences, courses in the humanities are much less likely to recur from year to year. This means that students can’t always rely on knowledge of the curriculum gained over prior years.
• Integrating external data: the main source of the catalog was a database developed and managed by the college’s central IT department, exported to the site as an XML feed. While I was at Evergreen, this database had not had a major upgrade in about 15 years and was itself a home-grown solution on top of the ERP system that managed enrollment. 

The evolution

Continuous assessment

Because the catalog was always been one of the most heavily trafficked parts of the website, evaluating and improving this feature was a critical aspect of my work at Evergreen. 

Prior to the pandemic, at least once a year our team conducted usability testing on the catalog, using the Steve Krug methodology. Sometimes the users were current students in order to see what they were already doing, other times I tested with people with less prior knowledge, to map onto the prospective student experience. 

I contributed to the list of tasks and took turns with the designer on our team to recruit participants or conduct the actual testing. In the sessions where he ran the testing, I managed the stakeholders in the observation room.

An interesting thing that happened regularly is that in unrelated usability studies, subjects working on tasks related to understanding the college or academic planning ended up in the catalog. This often provided insight into how the catalog connected to the rest of the site and how users experienced the catalog in context, as well as providing bonus usability testing.

I also solicited feedback from staff in advising, admissions, and academics — people who often interact with current and prospective students. Any time we made major changes, I reached out to our main contacts in these areas, both to get their perspective and to make sure they could include the updates in their support work.

Adapting to user needs

I learned that current students had their own criteria for quickly narrowing their choices: logistics (quarter and class standing), then subject matter (“Field of Study”), and then often selecting specific faculty, either from experience or reputation. This helped me to build filters that made their work easier.

Seeing how students used the catalog also reinforced the importance of displaying this information in ways where it could be quickly spotted when skimming a list of offerings. In every iteration of the main catalog index, the designer and I both worked to make these filter options clear and visible: I built out the actual display, originally in hand-written PHP and then later as a View in Drupal; the designer expanded on that with visual hierarchy and icon choices.

Students who were trying to decide between options, or who were concerned about a class being full, would keep a piece of paper next to the computer, or multiple tabs with the different classes. They needed easy access to the “course reference number” (CRN) for the actual registration system. To support this need, I built a new feature that allows visitors to add classes to a list, and then in the display of that list the CRNs are easy to spot for quick reference while registering.

On the individual pages, the designer and I also worked together to highlight this critical information, although the actual text of the description was more prominent for students looking for more depth in their decision-making. We always worked iteratively and collaboratively as we sketched out ideas together; I developed the templates and he wrote the CSS.

Advocating for site visitors

An important part of my work on the catalog was social rather than technical. Some stakeholders who had less interaction with students or prospects were astonished when they saw how people actually used the catalog. Their experience with usability testing made them more supportive of our changes and better advocates with other stakeholders.

In usability testing with non-students, we often saw that participants skimmed by title. They expected course titles to be more like most schools, where the subject of the course is at the beginning of the title (“English 101”, etc) — this is not true at Evergreen. [grab some examples] 

For a number of years, the dean’s office held a yearly curriculum planning event with faculty leaders, advisors, admissions, and marketing. I participated in this event and advocated for clearer titles that included the main subjects of the classes. In some cases, I persuaded the faculty leaders to go back to their colleagues and make titles that were more useful for new or prospective students.

Managing multiple generations of technical updates

One of the reasons I advocated for migrating to Drupal was to address the needs of the catalog. When I started at Evergreen, the catalog as it existed was a tangle of hand-written PHP for parsing XML. It was extremely fragile, buggy, and not integrated with the rest of the site’s content management. It also ran slow and sometimes crashed under high load, particularly during peak usage as students tried to plan and register. While I made improvements within that system, there was a limit to what we could accomplish.

As part of our overall site migration to Drupal, I created the content type, mapping the XML to structures available in Drupal. I directly connected the faculty directory to the catalog, with references between the content types for consistency. I also created a taxonomy for the subjects that students used to skim, and then the taxonomy pages contained not just lists of the items, but also content about how students learn in that area, college resources for study of that subject, and so on.

By switching to Drupal, I also made the underlying infrastructure more robust and the import mechanism more standardized, which made a more stable system for high-use content. 

This upgrade created a more cohesive, more robust catalog for students and faculty.