Kassblog

A colleague recently asked me to document the process we undertook to redesign the Catlin Gabel website. Here is a summary.

Accept need to redesign

In our case, the school wanted to add features to a website that a parent volunteer had very capably created and managed for a number of years. The technology director and communications director acknowledged that the school’s needs had exceeded its website model at the time.

Identify project leader

I proposed leading the project myself, because I had both school leadership and website development experience. It helps to have a single leader to bear responsibility for keeping the project moving, and to serve as a single point of contact for external vendors.

Convene task force

Including a team that is committed to working together for the benefit of the whole is more important than representing all possible stakeholders. Ours included representatives from admission, communications, alumni, academics, technology, and parents, though not always the directors of these departments. Many people held two of these roles, some three. We held three intensive meetings, and then I kept the group apprised of progress and consulted with them to make additional decisions as needed.

Identify priority audiences

Many schools try to have its website serve all potential visitors. We were lucky to have a parent volunteer with media experience who advised us to carefully narrow our priority audiences to three or fewer. We selected families, employees, and alumni, though we did cheat a little: families included both current and prospective, as did employees. We left out students, the press, and the general public. If we did a good job with the priority audiences, then these secondary audiences would still have a good experience on the site.

Work from audiences -> values -> roles -> needs -> features

Some schools move to site features too quickly. The website committee completed “audience and roles” worksheets in small groups to better understand community needs that might indicate specific website features.

What values do these priority audiences hold most dearly (both about Catlin Gabel and about education in general)? What roles do our priority audiences play within the school? What needs do they have that the website might fulfill? Finally, what site features are necessary in order to meet these needs?

Rigorously following these steps kept the site design process focused on humans’ needs and ultimately more satisfying for the user.

We also consulted the school’s admin team to find out which features of the current site worked well and which did not. This helped us identify site features that we should definitely retain, and others that we should definitely discard. For example, the home page slideshow was identified as a much-liked feature because it included recent snapshots from the life of the school, instead of highly posed photos that many school websites feature.

Preview the changes for the school community

We made presentations to faculty, the board, parents, and students to build excitement, relieve concerns, and invite contributions into the process.

Hire a great graphic designer

The site look and feel is one of the three pillars of any website (the other two being site architecture and development platform). We solicited proposals from a number of designers. The committee was most attuned to the examples of other websites that designers had created. We were again fortunate that our parent volunteer referred us to his favorite designer.

The result was an extension of our human-centered design approach to the graphic design, as well as a unique design that does not look like any other website and truly embodies important values of Catlin Gabel. The design represented both progress and tradition, interrelatedness and independence, and the woodsy aesthetic of the Pacific Northwest.

Finalize the design plan

This included one section for each of the three pillars of website design: wireframe sketches for the look and feel, a visual map of primary and secondary sections for the site architecture, and lists of pros and cons for different website development platforms. Discussion and revision of the design document allowed the team to refine, change direction, and iterate through design document revisions while the site was still pliable.

The group accepted my recommendation of using Drupal for the development platform. It took a long time to build the support necessary for this choice, which seemed new and ambitious to people who had not worked with open-source software before. Several factors contributed to the ultimate decision to support Drupal.

• We interviewed school website development companies, but their presentations left committee members feeling underwhelmed.
• I built a clone of the current website in Drupal to demonstrate that a Drupal site would be sufficiently capable and could look like anything (the graphic design layer is mostly independent). I ran some auxiliary website functions, such as a podcast platform, on the clone site for a few months one year.
• The parent volunteer on the website committee felt that nonprofit organizations should consider open-source their first option. “Why wouldn’t a school use open-source software?” Even though Plone was his favorite platform, he supported the choice of Drupal.

Develop the site

In our case, I became the lead developer. Other schools might hire an external lead developer or contract with a school website company to deploy a website based on the company’s platform. Making this my special project for the year in addition to my regular job, I built the site part-time over a period of about six months, from January – June. The needs assessment and design phases had taken place in the fall of that year.

Working with open-source software, I had the ability to experiment with pieces of functionality and make decisions about what modules to use for what purposes. I also built a few site prototypes, the last of which proved strong enough to continue to develop into the production version of the site.

At the same time, graphic design work proceeded through selection of favorite elements from the prototype designs, development of a first draft final design, and then refinement and revisions.

Drupal has many community-contributed modules that overlap in functionality, and the Drupal community has posted articles comparing different approaches to calendaring, signup, and image galleries, among others. I also hired a local Drupal consultant to recommend ways to provide common types of functionality in the site. It was easy for him to say “SimpleNews” when I said “newsletter.”

I hired a summer worker to help migrate some of larger bodies of content (e.g., dozens of photo galleries) from the old site to the new. In some cases, he wrote small Drupal modules to load and reform the old content into new, and at other times, he migrated content manually.

The new site was built on a new server with a unique website address, so that I could invite many people to look at the site in process and send comments. The site launched in July, by simply repointing DNS for the main website address to the new site. The old site lived on using a new website address, so that we could search for content missing from the new site if needed. We eventually took down the old site but kept the database running longer for the purpose of content recovery.

Celebrate

We held a small party to recognize the milestone and express appreciation for the contributions of the members of the website committee and the designers and developers involved.

Introduce the site to the community

Similar to the presentations of the previous spring, I made many presentations and held workshops to orient people to the new website and train those who would maintain its content.

Continue developing

The open-source model that we adopted facilitates continued development especially well. We considered the launched website just the beginning of an ongoing development process, not a final product. The school’s needs don’t stay fixed over time, and neither should the website’s feature set. The first fall with the new site involved a fair bit of additional development work to fine-tune certain features of the site in response to user feedback, fix bugs, and add functionality not completed in time for the initial launch. By winter, nearly everything in the final design document was built. I carefully managed an extensive to-do list of wished-for features and desired usability improvements and gradually worked to complete them.

In subsequent years, I have dedicated only a small fraction of my total job to new website development. We added social media integration, a complete admission application system, mobile theme, and also slightly changed the direction of certain features, for example changing the “all school” section into “co-curricular.” Summer has proven a good time to do substantial new code development and Drupal configuration work.

Anticipate the next version

When will we have to repeat the design process and re-launch or significantly upgrade the site? We know that the shelf life of a school website is approximately four years, and we are currently in year three. Drupal 6 won’t be supported forever, and Drupal 7 and Drupal 8 are calling. We believe that the website still meets people’s needs, but this is increasingly coming under pressure as mobile users want easier access to site content and tools, the site design has begun to feel a little old, and we see other websites with more modern features that enhance usability.

My departure from the school may also accelerate consideration of a new website. I mitigated this to a degree by training over 60 people to be content editors and two colleagues to become develop portions of the site. Many people here know a lot about the site. That said, the departure of the principal developer leaves a vacuum, and the school will take much of next year to determine whether to continue with the Drupal strategy indefinitely or to begin to work toward a new website solution.