The Problem

The Human Resources department needed a redesign of their outdated website. The last time the website had been updated was in 2011, and the site wasn’t accessible or responsive. The stakeholders felt that their previous site didn’t adequately communicate their services and knew that faculty and staff had trouble finding information on the site.  They desired a more intuitive navigation, a fresh visual design and a better user experience.

They were also specifically looking to achieve the following:

  • Attract potential new hires
  • Allow faculty and staff to easily find information on benefits and policies
  • Make the main navigation more intuitive
  • Allow editors from multiple departments to easily update the site.
  • Have an FAQ section that would answer some of the most commonly asked questions.
  • Update forms/documents in one place

The Solution

Through reviewing analytics, interviewing stakeholders and tree testing the current and future architecture, we were able to determine pain points with their previous site and identify the things that needed to be improved on the future site.

  • Navigation shouldn’t be based on department organization
  • Have a searchable FAQs and policy sections
  • Show upcoming events and courses
  • Highlight common tasks that users are looking to perform

Step One: Get to know the users

We had a general idea of who the users for the Human Resources website were, but we wanted to learn more from other departments at the university. We had proposed doing a survey, but due to the nature of the site and how old it was the department felt like we would only receive complaints and not what was working well.

A content audit was done to help us identify the content on the site and aid in better understanding the material and subject matter.  We interviewed key stakeholders and current editors of the site. We also talked with the customer service staff that handles the day to day calls and they kept a very detailed account of the things that people were struggling with.  We paired that information with Google analytics to find usage patterns, popular topics and frequent search terms to help us come up with personas for the site.

From this research we ended up determining the following audiences:

Faculty

Joshua

Staff Member

Joshua visits the HR website periodically throughout the year. He checks benefit information when open enrollment comes around to see what has changed, and also uses the HR website to find out when the university holidays are. He is familiar that HR offers development classes, but he is unsure as to where to learn more about them.

grad-student

Joan

Prospective Hire

Joan has recently moved to Cleveland and is interested in seeing what kind of careers the university has available. She’d like to be able to quickly scan the jobs and see if any would be a good fit for her. She’s also interested to see what benefits might be available to her if she was hired.

undergrads

Jessica

Manager

Jessica oversees a research staff and visits the HR website to learn more about hiring staff for vacant positions and guidelines for writing the job descriptions. She also uses it to download forms for employee reviews and recognition.

Step Two: Information Architecture

Because of the way the old website was created, we had to meet with multiple content owners to make sure that we were structuring the new site in a way that kept what was important to each department but also display it in a way that matched the user’s mental model.

To do that, we ran a tree test on their current site to get a better idea of where the pain points were and then came up with a new information architecture based off our research and the results of the first tree test.

The new architecture was also tested and in doing this second test we realized that there were still some areas that people were struggling with. We used Optimal Workshop to perform these tests, and the great thing about that software is the ability to dig into the results to click paths. With that information, we could improve the IA. To address these issues, we moved the content to a different section or we included the content in those multiple places.

Step Three: Rewriting Content & Wireframing

With the large-scale changes that we were implementing to this site, we knew that the content would need to be rewritten. This way we could ensure that the content was written for web reading, but that it would also be updated with the correct information. Something that the HR department struggled with since they didn’t have a content management system and would need to update the HTML directly.

Since we were moving this content into the university’s content management system (CMS), Drupal, we already had predefined templates created. So we only needed to create wireframes for some of the pages where the design called for unique features.

As these wireframes were built out in Drupal we realized that some of the functionality needed to change due to the nature of the CMS. So you can see on the live site that we had to break apart FAQs and Forms and Policies so they could be searched correctly.

Step Four: Drupal Build & Content Import

In addressing the needs of the HR department, one of the biggest projects on the development side of things was to give them a central repository where they would be able to upload a form, and then be able to update the reference when the form changed next year. While you can update forms in Drupal, these forms are also being searched which led to another level of complexity in the build. In working with the developers we were able to come up with a solution that was easy for the editors to update.

Upload Documents form - for the editors

We were then able to use this solution to help us build out the FAQ section. Instead of creating a unique media bundle, as we did for the documents we created a unique content type. The editors are also able to select what FAQ category this question would fall under from the editing screen.

FAQ content type

Once the build was finished we had our content editors import all of the FAQs and Forms and tag them appropriately.

Step Four: Quality Assurance & Site Launch

The development team reviewed the site build to ensure that all of the modules and permissions have been added to the site.  Content editors also reviewed the site to ensure that the headers have been structured correctly, links are working and all images have proper alt tags to aid in accessibility.

Once the site has been approved for launch, we work with the University Technology team to schedule the go-live date. Once the site is live, all of the pages and redirects are double-checked to ensure they are working correctly.

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search