It is far from the sexiest project I’ve ever worked on, but this redesign of an intranet for underwriters is one of my favorite projects because the odds were stacked against its success (50% of all Sharepoint projects fail due to lack of adoption), any success it might have relied completely on having an IA that worked for its users, but (spoiler alert), it was massively successful. I’ve talked about the process and what I’ve learned in a presentation, IA in a Complex Business Context, but that doesn’t talk much about the design itself. From an IA and prototyping perspective, it was significant because it was the first time I was able to convince the powers that be to let me prototype with a significant amount of real content and metadata. This experience was so metadata-centric that a lesser simulation wouldn’t have given us the information we needed to really validate our approach.
For this process, I was one of the key practitioners. I facilitated generative user interviews at the beginning, open card sorts in the middle, and usability testing at the end. I also constructed the navigation, built the taxonomies and information models, created the testable prototype in Axure, and helped present deliverables to the client.
Our prototyping process began with page description diagrams. This was before we’d introduced more robust content modeling into our process, and if I were going to do it again, I would still do PDDs for list pages, home pages, and anything else more one-off. I would make sure to add an object-oriented content model, however, to capture how the more dynamic, reusable objects would function.
As I discuss in the talk linked to above, however, the PDDs played an important role in our process, though, by making us decide on one thing at a time (just what’s going to be on a page, not where it goes or how we show it), and discuss it with the client in a focused way.
At this point, I also created a navigation model. I deliberately call it a model, rather than a sitemap, because it’s intended to be a representation of how persistent navigation should work and what its rules should be, rather than a factual description of where pages are in a directory structure. At the time, we presented it as a diagram like this:
Annotations showed which parts of it would be controlled by taxonomies and what the rules for their interactions might be. When I create navigation models now, I like to make sure they also include some more explicit statement of the rules, so stakeholders can understand why the navigation is constructed as it is, and changes are easier to make. For a recent client, I created the following diagram early in the project, to socialize and validate the model I was thinking about, so we could iterate on it early:
This diagram doesn’t list out all the taxonomy terms, but it shows how each category could be constructed. It let us talk about the idea early, instead of waiting until we’d done a lot of busywork by populating each of these categories.
For the intranet, after we had sign off on the PDDs and the navigation, we returned to prototyping. In order to make sure we were faithfully simulating the experience, I quickly tagged the content that had been audited previously in the project, using the information model we had created. This was a great way to validate the taxonomies against the content and to get a content set that I could use in Axure via repeaters.
(Many of the details needed to be anonymized in order to be published publicly, as the intranet is entirely internal and proprietary.)
The purpose of this intranet was to enable underwriters to find the documents they would need to make decisions about policies and claims. Since they were already experts in the domain, and we wanted to do usability testing with fairly realistic goals, the prototype had to be built out to a high degree of informational and interactive fidelity, even though it was visually very minimal.