The University of Washington had at least 4 top-level HR and payroll sites plus a dozen or so smaller ones run by schools and departments that were all independently set up and operated. And now they were adding Workday to the mix. This fragmentation was detrimental to both the university and its employees.
Goal: Assemble all HR information- plus information from the new Workday HR program – into a one-stop, self-service HR website.
Dates: May 2016 – May 2017 (12 months)
Target Audiences: 25,000+ current UW employees (faculty, professional staff, and student workers), thousands of UW retirees, and countless prospective employees
My Role: User Experience Designer on the University of Washington Academic Experience Design and Delivery Team
- 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.”
- Usability testing revealed users would prefer using the new site over their current method for many HR-related information needs.
- Delivered a website, a suggested information architecture for said website, and written instructions documenting how to produce new content.
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. We were not handed very much user research to start with and the project didn’t have enough slack to do much ourselves. Luckily, because we were UW employees as well, this was one of the few times where we were our own users. We drew on our experience and the experiences of other employees we had met over the years.
We simplified these tasks 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. As often happens in agile development, some of these details changed a bit by the final product, but our initial analysis turned out to be pretty solid.
The information architecture work was a bear and took a lot of iteration. We did a few rounds of card sorts to get an initial idea.
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. It was a real challenge to blend mountains of information together in a such a way that was both agreeable to stakeholders and more beneficial for UW employees than previous options. This was a living document and changed a lot as we learned things. What’s presented here is not quite the final configuration, but it’s close.
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. Here are a couple of examples of some mobile homepage layouts we played with. Ultimately, we were mandated to go with a slightly-modified UW WordPress theme, which had its own ideas for mobile layouts, but at least this helped inform information hierarchy.
A small leap forward from there involved creating 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.