Story of an Intranet Redesign - Part One: IA

It was a daunting task, this Intranet redesign. The old Intranet had been in place for many years and for the most part, probably because they had to and had grown accustomed to it, people were happy with it. To a new user coming in it was a nightmare, but to those who had learned the eight click path to get to Human Resources, it was fine.

It was built on FrontPage, bots and all. This helped the few content owners who could update their own site but was a real pain as far as maintenance goes. And getting a new content owner up and running was very labor intensive. The site was largely flat and informational, with no real information architecture, other than maybe a loose org chart organization in some areas. It was very hard to find things and it didn’t help that there was no search. As a communication tool, it was poor at best. We had a weekly brochure-ware bulletin, again something that was very hard to maintain, going out, and the home page was updated on fairly regular basis by our team.

It was a mess, it had incosistant labeling schemes, no real consistent look and feel or standard navigation, no global navigation as well as other huge usability problems and the list goes on. On top of that it was hard to maintain, hard to use and for the most part static, out of date and dated.

Oh and it was pretty ugly too.

It was obvious, to me anyway (there were those who felt that since the users had adapted to it we didn’t need to change it) that it needed an overhaul so about a year ago we began to talk seriously about how to go about fixing it. It was decided at the time that the first thing we needed to go was add a search. The second was to look into a content management solution. Neither one of these things happened for quite a while. I think mainly because of the overwhelming politics that are involved, coupled with the fact that the team got smarter. I was fairly new to the organization and our department was still getting established. When you come in to an organization and start talking about changing the ways people do things you can imagine lots of resistance. You know, who are these people anyway?

We spent quite a bit of time trying to figure out how we were going to take this on and what tools we were going to use. We had a CMS in place (after countless hours trying to get the damn thing installed) and we spent some time toying with that, but I’ll get to that bit in Part Three. We also started working on the search, however, I had come to the conclusion that a search could help with, but ultimately not fix, the problem. Like I said, we got smarter.

I began to feel, as I’m sure the rest of the team did, that we were putting the cart before the horse. Since I was fairly new I could see some things that perhaps others didn’t. I felt that we needed to start from the ground up, that we needed desperately to increase the overall usability of the site and especially the findability of things. At that point I still had to ask my coworkers where to find things on the Human Resources site.

I started talking about doing some usability and reworking of the Information Architecture of the site, things my team caught on to, but the rest of the organization had no clue about.

About that time we brought on Brian Fling, our Web producer. He felt much the same way about getting more in touch with the users and doing some work on the IA. He also felt very strongly, and rightly so, about making the Intranet more transactional.

We jumped right in and began to work on the IA of the site. This was the most important thing we did. It laid the foundation for our success. If you are going to build or redesign an Intranet you need to put some time into the IA.

We started by doing a content inventory and gathering data about our users. We analysed the content, went through our logs and tried to figure out what our users found useful and how they were going about accessing it.

It was obvious that there were many parts of the site that most users didn’t see, or that weren’t important to the “average” user. The Phone Directory was by far the most used part of the site, but this was no surprise. Based on this research we could tell that people were having a very hard time figuring out where things were on the site.

We decided to do some card sorting exercises and the like with the team and a few others. Once we had hashed that out, and trust me it was a difficult process as there was a vast difference between how a new person to the hospital viewed the IA and how someone who had been there a long time looked at it. We then did the same exercise with our stake-holders and our Intranet Review Board. Yes we have many of those type of things, I’m not going to get into the politics too much, except for to say that it’s something you have to deal with, and it’s largely because people really care about this stuff. In any case, again we saw that where you sat, and how long you had been at the hospital, greatly effected how you saw the content organization. The org chart raising it’s ugly head as it likes to do. If there was one clear result from these initial card sorting it was that everyone separated the administrative information from the clinical information. It was a place to start.

We gathered our findings and took an initial stab at the organization of the site. At that point we realized that we were having some problems with semantics, and we hadn’t even been able to run this by the users. We held several meetings to nail down the initial taxonomy and labels. We then brought this back to the review board for clarification, all of this done with the caveat that our users should have the final say. The good thing was, for the most part, the users ideas fell in line with what we came up with. It’s important to point out that when working on an Intranet like this, the majority of wrangling is at the lower levels. You hear things like, “well, actually, this is part of such-and-such department and shouldn’t be in with clinical.”

At that point we had the basic site structure, at least at the top worked out. We went with an audience based structure for the most part, but with a few major differences. With an Intranet you pretty much have to go with a mixed architecture. Our main content areas were (are):

• Information about the hospital, maps, directions, hospital goals and initiatives
• Departmental information, pretty much a list of departments with Intranet presence
• Clinical resources, tools and information
• Education and training information
• Staff resources, coffee break, and things for “every” employee

We also had a few notable stand-outs that didn’t quite fit in any one single area, Policies and Procedures (obviously a big deal in a hospital) and our Phone Directory being the biggest. We thought about giving them their own area, but decided that we would place them beneath the others and bring them out in other ways. The Phone Directory, for instance, would “live” in the Staff Resources area, but be accessible from every page.

At this point, with the structure of the site pretty much bought off on (I say pretty much because we’d find down the road that the labels would change and we’d make minor changes at the second and third levels) it was time to bring our users into the mix and do some usability, not that we were done with the IA process, it weaves its way throughout the overall redesign process and is ongoing. You can’t just do it and be done with it.

Whew, okay! Well, that’s it for Part One, in Part Two I’ll get into user research, some usability studies and get into the design of the Intranet. Part Three will talk about our CMS issues, some real world solutions and the actual implentation of this beast.