Intranet for Northwest Justice Project

26 Sep 2013


Starting in July of 2010, I developed an intranet portal for the attorneys at the Northwest Justice Project. By meeting their needs in the areas of document management, information sharing, and governance, the portal (officially launched mid-2012) allowed them to serve their low-income clients much more efficiently.

User Research

I used several methods for understanding the attorneys who would use our new system. These included:

  • Interviewing. I carried out four interviews with attorneys in a variety of roles. This provided me with insight into the culture at NJP, how they get their work done, what works for them, and what doesn't. This is one of my favorite parts of the beginning of a project. Before you have any ideas, before you commit to a solution, you are simply an anthropologist trying to understand how technology can improve an organization's ability to achieve its goals.

  • Contextual inquiry. I shadowed one attorney as she took calls on the legal advice hotline, a service provided by NJP free of charge to all Washington State residents. The interesting part about this was a) witnessing first-hand the almost astounding diversity of legal problems these attorneys handle every day and b) how many "workarounds" (as Beyer & Holtzblatt might say) they utilized to get their work done. I hoped to document some of these workaround in order to incorporate them into the new system. For example: they attorney I watched had a huge list of bookmarks she referred to while on the phone; she had to maintain this list herself, though, and nobody knows how her list differs from the next advocate's. She also showed me a variety of boilerplate paragraphs she uses all the time---but these, again, require effort to maintain and could benefit from collective maintenance by all attorneys.

  • Surveys. Once I was ready to propose a first-draft taxonomy (more on that below), I created a survey to help me prioritize the elements it contained. That produced very useful results. Not only was I able to understand which parts of the taxonomy were useful, I understood which parts were useful to whom. In other words, some things were more useful to attorneys who litigate, while others were more useful for those who simply provide advice over the phone.

  • Looking at documents. One of the unique things about doing this kind of IA in a workplace setting is that you have access to what an archaeologist would call the material record. You get all kinds of things to rummage through: training materials, memos, entire network drives, intranet pages, and so forth. This is invaluable! I used all this as background for developing the taxonomy and requirements gathering.

In the end I created three personas to help differentiate the unique needs of the three types of NJP advocates who would use the system.

Taxonomy Development

The most important part of designing a taxonomy is understanding what words your users prefer to use when describing their work. Here’s how I went about doing that, cribbed from a more detailed blog post I wrote called How to Develop a Taxonomy for Your Legal Services Organization:

  1. Pick one substantive legal area as your "pilot" area. Mine was housing law.
  2. Gather 25-30 sample documents and examine them carefully, looking for patterns and words that come up frequently.
  3. Get acquainted with your organization’s case management system. See how it’s organized, and use those ideas in your new system. This will ensure interoperability down the line.
  4. Find places where advocates talk about your legal area of focus in their own words. These could include email listservs, meetings minutes, etc.
  5. Identify the unique needs of each individual user group you’re designing for.
  6. Immerse yourself in all of the above, then make a list of the salient attributes you’ve discovered. These are called facets. In my system some important facets are Issues, Forum, County, Substantive Area, and so on.
  7. Get another round of feedback via online survey: how did you do in step 6?
  8. Put it all into a giant spreadsheet. Add proposed values for your facets; for example, the Issues facet in Housing could have values like “foreclosure”, “eviction”, etc.
  9. Refine and prioritize.
  10. Take your facets, along with proposed values for each, to an expert to go over the details. Go on to design and prototyping from here.

Planning the Information Architecture

Site Map

First I sketched out a site map on paper. Given all I now knew about the needs of our attorneys and the information we would be storing, I found it helpful to draw the whole system from a high level point of view, in what is called a site map (here’s a good introduction if you’re interested in more details).

Sketching the site map allowed me to try out many different configurations without the burden of actually building anything. I could begin to work through (if not solve) a lot of problems that way. A single box represented a single page, and arrows pointed out to the other pages you could reach from it. It’s a good way to tackle the details of what you’re building for the first time. Once I was happy with the site map, I created a version of it in Visio.


Next I moved to sketching each individual page in the system. Having worked through the entire site map, I now knew what kind of pages I needed to build, and what I thought each page should do for the user. Or at least I knew enough to build something against which to test my assumptions with hands-on user research.

For most pages I began with a pencil sketch on graph paper, then moved on to Visio. I drew the layout of a given page in blocks. Each block had a corresponding piece of functionality or content such as “Essential Documents” or “Metadata Navigation”, etc. Just as with the site map, this allowed me to work through the details of how my pages fit together and what they should look like.

Developing the SharePoint Prototype

I won't dwell too much on the parts of this that are unique to SharePoint. It's difficult to learn, but I was able to build the pages I thought the attorneys needed. What's more important to say about this is the iterative, hands-on refinement I went through, and the constant trying of new things. Whether I'm working in a browser with HTML/CSS/JavaScript, in SharePoint, in Drupal (if you're reading this on you are experiencing this directly), or in some unforeseen environment, I think it's really important to tinker with things. And to make them real as quickly as possible. Don't waste time on high fidelity Photoshop mockups! Things need to change quickly, and you shouldn't get attached to a design. That's why live prototyping is better.

Usability Testing

I tested the system with three attorneys who were given four specific tasks. All of them were successful, but I learned a lot in the process. You can read more details about this in my blog post at LSNTAP6 Lessons from Usability Testing a SharePoint Project.