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
- 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.
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.
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.
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.
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.
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.
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.
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
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 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.)
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.