Homepage of the Integrated Service Center showing three people walking, framed by content

Integrated Service Center Website

Overview

Goal: Assemble information from disparate HR sites around the UW – plus information from the new Workday HR program – into a one-stop, self-service HR shop.

Dates: May 2016 – May 2017 (12 months)

Target Audiences: Employees of the University of Washington, special emphasis on new hires

My Role: User Experience Designer

Outcomes

  • Received a UW-IT recognition award for negotiating difficult compromises with the client.
  • Our client – an internal Human Resources team to the UW – praised us for delivering “a beautiful website that works, on-time and on-budget” and recognized our “important contribution to this very big and complex project.”
  • Successfully combined 5 HR department’s worth of content – plus new Workday content – into a single web portal that our late-round usability subjects liked using, indicating they would prefer using this over their current method for many HR tasks.

Process

We were not handed very much user research to start with and the project didn’t have enough slack to do much ourselves. How unusual! Luckily, this was one of the few times where we actually were our users because we were UW employees as well. So we drew on our experience and the experiences of other employees we had met over the years. From there we drafted up some loose personas, thoroughly brainstormed the sort of HR questions people have at the university, and created a combination content audit and task analysis for the different personas in various stages of their careers.

Mindmap showing various ways to describe UW employees

 

A spreadsheet showing user tasks, questions that might relate to those tasks, and where the answers live for various personas
Snippet of a spreadsheet inventorying content based on user tasks and various personas. Click through to the full PDF.

 

As you might imagine, trying to model user flows for every single line-item in that spreadsheet would have taken far too long. So we simplified and based them off how we thought various information-seeking behavior would work in our system. Pictured below are the two larger flows we worked out.

A flow-chart

A flow chart

Once we had the use flows worked out, we modeled some basic page flows to give the developers an idea of how pages would fit together. I think it’s fair to say some of these details changed a bit by the final product, but this is still pretty solid.

A pageflow, showing how different pages of the site would interact with each other

 

The information architecture work was a bear and it took a lot of iteration. We did a few rounds of card sorts to help get an initial feel of it.

Piles of index cards stacked on a table
One participant’s groupings

We used the data from a card sort to produce a dendrogram, which gave us a nice idea of the groupings for the top level of the information hierarchy and main navigation labels.

A dendrogram looks a lot like tree roots, and where the lines come together is how you can tell groupings

 

We built a skeleton site in Axure that was just navigation to test out some proposed schemas. Once we became confident that we knew what would work, we created an IA/Navigation document that indicated levels of hierarchy/pages, connections to other material, locations of content (external or internal), keywords, and more. The information architecture of the site was by far the most challenging part, particularly given the consensus-driven decision making.  It needed to both encapsulate and inform the content the client would write. It was a real challenge to blend mountains of information together in a such a way that was both agreeable to stakeholders and was more beneficial for UW employees than previous options. This was a living document and changed a lot as we learned things, but what’s presented here is more-or-less the final configuration.

Topics shown in a hierarchical format

From there it was time to dig into wireframes. I don’t all the artifacts to completely explain the evolution from beginning to end, but that’s actually a good thing; you don’t want to be scrolling through 27 pages of this. Here’s a few key things. We did what we called an “element analysis” which is sort a bridge between IA and wireframes

A table showing which elements would appear on which pages
Analysis of which elements should live on which pages

We also did a lot of whiteboarding of many layout options for the pages – mobile first, of course. This was ultimately fruitless because we ended up getting handcuffed by WordPress themes, but it was fun (and instructive) anyway. Here are a couple of examples of some mobile homepage layouts we played with.

A wireframe showing an arrangement of elements for a mobile homepage

A wireframe showing an arrangement of elements for a mobile homepage

A small leap forward from there involved creating what must have been at least 30 different versions of Axure prototypes. It took a while to find a balance between what the clients were asking for and what we knew the users needed. Here’s one such homepage example we showed to them. It’s reasonably close to what actually made it to production, at least initially. (The production version is the cover photo for this portfolio project.)

Previous version of homepage with centralized search bar and different treatments
The homepage a few iterations before visual design was finalized

Because this project needed to have a clean handoff (meaning, there was to be no support from us after the end-date) we had to supply them with documentation. The engineers supplied their own documentation for their webmaster and I was in charge of writing the documentation for the content creators. This is actually the document to read if you really want to understand the site architecture as it was delivered.

This image shows instructions for how to use the "posts" view in WordPress; details unimportant for this context