Departmental Website

(content strategy for website redesign)

the challenge

The Research Information Technology department provides a number of vital services for researchers in the College of Medicine at Ohio State. But two years into its history, many researchers were still unfamiliar with RIT's offerings. The situation was only exacerbated by the department website: one page with a description of the department's mission, an outdated list of staff, and not much else.

Armed with the department head's vision for what a revamped site should include, the design team had jumped straight to mocking up pages. I was brought on simply to write copy, but I soon realized we still needed to agree on what content we were drafting, what that content needed to do, and develop a process others could participate in beside myself.

approach

defining content types

The department head had proposed a rough site organization, along with a number of topics for pages - think back-of-a-napkin fidelity. That outline gave my team a place to start, but most of us, myself included, had worked for the department for less than a year. Half the entities described in that proposal were completely opaque to us, and likely to our user base as well. I used 15-minute weekly meetings with subject matter experts (the most time they could offer) to uncover the deeper meaning of each acronym and vaguely named service.

After establishing the "what" of these pages, I started asking about the "why" of these pages. Why would it help a researcher to know more about each topic? Common themes started emerging: because it was a service the researcher might want to ask RIT to provide, because it was a product RIT had built for researchers to use off-the-shelf, or because it was a past project that researchers might take inspiration from. Using these three throughlines - service, product, and project - I outlined different content types to meet those different needs.

Post-its with different IT topics on them, color-coded and grouped by topic

To document the relationships between different pages, my team used virtual sticky notes to arrange topics by content type.

defining roles and responsibilities

After vetting the content types by populating a few examples myself, I turned to other subject matter experts for the other pages. At first, my team sent out open-ended templates, wanting to emphasize a collaborative, not top-down process. But after deadlines passed, with the templates still empty, I realized a different approach was needed. Instead, I set up meetings with each subject matter expert to interview them on their topic. After the interviews were complete, I drafted pages, keeping track of decisions made as I was writing to inform the website style guide. The subject matter experts then acted as content approvers, rather than writers.

Worksheet with a few bulleted questions and a text box to populate content

My team created templates that would explain content types to subject matter experts, but we later realized we could have simplified the process even more.

As people saw the website taking shape, enthusiasm grew. That enthusiasm manifested in suggestions for new pages: maybe we could have a wiki! How about a blog with department updates? With each new proposal, I wanted to make sure we knew who would be responsible for it, and what success and failure looked like. By outlining the consequences of poorly-executed content, and the effort required to make our content succeed, I was able to separate short-term needs from long-term wishes.

pre-launch verification

With the content and design in place for version 2.0 of the website, my team awaited its development by the university's shared services group. They came back with one big change: the navigation design we'd wanted wasn't feasible within their CMS. After talking with key stakeholders, the UI designer and I drafted a new top-level landing page that would provide more ways of accessing the second-level content. That design also allowed for flexibility as the site grew.

The website was close to being done, but the content required one more round of approval from subject matter experts. Having learned that open-ended forms were a little daunting, I compiled a checklist for each SME of information to verify. Unlike the open-ended forms, the checklist only required a five-day turnaround time, and as expected, requested changes to the content were minimal.

Jira ticket with columns laying out the current content side-by-side with space to request edits

The content review checklists were minimal and provided a point-by-point guide to what subject matter experts needed to review.

documentation and impact

A key part of the project was avoiding a repeat of the original problem: a webpage two years out of date, that didn't display the department's full strengths. To that end, I documented procedures for updating the website so that my team and others could quickly make ad hoc changes. I also received buy-in from my manager and his manager to conduct a yearly review of the site with other managers, where we'll review what content needs to be refreshed.

Within the department, I also conducted a retrospective of the site development process, where the team discussed everything from the UI design to the different formats we had used to gather input and feedback.The results were recorded on an internal wiki, and have served to inform ongoing web and content development projects.