HTRC user documentation (information architecture)
The seed of this project was planted during the 2021 UX audit, which revealed user frustrations concerning both the amount of documentation, as well as the difficulties they experienced when trying to find the page they needed for particular tasks.
The problem
At the outset of this project, the HTRC Analytics documentation wiki space had been in use for approximately a decade. Many pages had been added by different authors over this time span. As a result, HTRC documentation was sprawling and lacked a rigorous structure. There was a need to assess the current-state of this site (i.e., what pages were where, what those pages contained), and design a more intuitive organizational layout for our users’ benefit.
This wiki site structural revision project needed to address these user-reported issues to create a more intuitively designed layout so that HTRC documentation would be easier to navigate, and provide a more satisfying experience for the information finding needs of our users.
First steps
From the user tests and interviews conducted during the HTRC Analytics UX audit, I hypothesized that users were experiencing content overload, and feelings of being overwhelmed when they visited the HTRC documentation wiki. One major problem was the amount of pages, and many categories linked directly from the wiki’s homepage – i.e., all categories were listed on the homepage, with confusing child page embeddings, some that could only be reached as hyperlinks from child pages. Content creep had affected the organization of pages shown from the homepage, but important pages were nonetheless buried in child pages, and could not be easily located. Funnily enough, two opposing problems were hampering findability for users: 1. Too much info on the homepage, making users feel overwhelmed, and 2. not enough was strategically shown from the homepage to help users understand there were additional important pages they would need to have access to. The HTRC documentation wiki space needed to be reorganized and restructured to help users know what documentation existed, and where to find it.
The current state
My first questions were: how many pages are hosted on the wiki documentation space, and what is on those pages? Using the SEO software tool Site Bulb, I directed a graduate assistant to pull all page URLs associated with the wiki space into an Excel spreadsheet. I directed her to categorize each page and then perform a minimal content audit upon the pages: page name, page description, yes/no up-to-date assessment, yes/no active (meaning that the page had been updated within the last year).
Please note: The goal of this project was not to perform a complete content audit, which would have, at minimum, involved closely reading, analyzing, and updating or discarding pages. The goal of this project was to organize the wiki space for an HTRC-user-focused audience, in essence updating the information architecture of the space. A content audit will be a separate future project.
Once all the pages had been gathered, categorized, and minimally assessed, I created a current-state site map of the wiki.
Site map
In order to get an honest picture of how many pages users were witnessing when they navigated to the HTRC wiki space, I used Google’s draw.io tool to create a hierarchical layout of the site from the wiki’s homepage. The following images give a snapshot of the map. Overall, there were a total of 9 categories with 23 subcategories, and then even more child pages hyperlinked within each of these subcategories, all directly on the homepage. Confusing and overwhelming, indeed!
Image: Fully zoomed-out image of the complete current-state sitemap that depicts every page linked from the wiki documentation space’s homepage.
Image: Just a small portion of the expansive current-state sitemap of the wiki documentation space
Next steps: user input
User tests
Over Zoom, I conducted remote user tests with five HTRC users. I wanted to discover what users thought about the help documentation wiki generally, and then watch them perform two documentation-based tasks designed to see how easy it was to find document pages. I asked users to share their screen with me and to think aloud as they answered my questions or completed the tasks. My GA was also present during the tests and took notes on what users reported.
The top three findings from these tests were:
Poor organization of content based on user expectations
Poor labeling – users must click on pages to read through them before they know what they are about
Outdated time-sensitive material
Based on my hypothesis, I was expecting findings 1 and 2, but 3 was a surprise!
Card sorting
Because this project focused on the organization of content, I conducted individual card sorting activities with each of the users in a separate session from the user tests. Card sorting is typically performed with Post-It notes or index cards in person, but because HTRC is remote from most of its users, I simulated this activity by using Google’s Jamboard app. From the minimal content audit, I put every major category of documentation onto Jamboard sticky notes. Here’s the master list of the original categories on my master Jamboard:
Image: Master Jamboard card sort showing all major categories of information on the HTRC wiki documentation space
Then I met with each user again over Zoom and shared with them their own copy of the master list, and asked them to group the sticky notes around into self-created categories that made sense to them.
Here are a couple excerpts of the user-organized Jamboards:
Image: One page of participant 2’s reorganized Jamboard
Image: One page of Participant 5’s reorganized Jamboard
Once each card sort was completed, I analyzed the Jamboards to come up with the following conclusions:
“Help” needs to be categorized with “Troubleshooting” and anything related to the user having a problem and seeking an answer
the concept of a “building our community” section needs to be its own section
need for items like “news”/announcements and outages to be more oriented towards the top/beginning of the page (and they need to be updated regularly! – all participants noted this in some way)
General complaints were: the page dates show that pages have not been updated recently, and for pages like “Announcements”, this is confusing to users, and makes them think that the website is generally not up-to-date and suspicious of the documentation.
Takeaways from the users
After testing, I concluded that users needed distinct, well-labeled parent categories in order to intuitively find the documentation they needed; that ideas related to ‘community’ were important to users; and Help was a top-level category that included ‘Troubleshooting’ for facilitating problem-solving user-directed sessions.
Putting it all together
With this user-based information, I created a wiki sitemap proposal – a sitemap that depicted a new information architecture with 6 top-level parent categories for their corresponding children: Announcements and News; What can I do on HTRC Analytics?; Use the data; Need help?; Community Engagement; and Development work at HTRC. Below is quick view of that sitemap:
Image: Overview of the sitemap proposal with 6 parent categories
Image: Snippet of sitemap proposal showing 4 parent categories: Announcements and news; What can I do on HTRC Analytics; Use the data; and Need Help?
How this structure can help users
As I worked towards reorganizing HTRC’s user documentation, I realized there was a lot of redundancy between the original 9 parent categories, and 23 subcategories. While it is nice for users to have more than one entry point to documentation pages, the sheer amount of pages and how many times each page was highlighted across multiple parent categories was contributing to the overabundance of information on the documentation wiki. I brought the parent categories down to 6, and then eliminated much of the 23 subcategories buried within each. In a sense, I was flattening out and pruning categories in order to streamline the information foraging process for users.
For instance, in the original documentation organization, there was a top-level category called ‘Getting Started Guide.’ While the category was well-intentioned, it contained child pages found in the sub-categories like ‘Examples and Use Cases’ and ‘All HTRC Tutorials’ (along with 14 other child pages, from ‘HTRC, Help!’ to ‘Workshops and Education Materials’). Needless to say, this kind of page listing was confusing and overwhelming to users, causing them, ironically, to be unsure of where to start. I eliminated this kind of redundancy by creating user-informed parent categories with minimal, high-level subcategories.
The new design
Here is the new design I implemented on the HTRC documentation wiki:
Image: Newly organized HTRC documentation wiki space with finalized parent category tabs listed: Announcements and News; Text as Data; What can I do on HTRC Analytics; Need Help?; Community Engagement; and Development Work at HTRC
Image: Text as Data section – all child pages listed
Image: Need Help? section showing all help documentation pages, including the Troubleshooting and FAQs page
Image: Snippet of the Community Engagement documentation section; sub-categories are Outreach and HTRC Research Projects, the latter containing two sub-sub categories HTRC Advanced Collaborative Awards and Projects and HTRC's Grant-Funded Projects.
I created a draft of this design in the Wiki space and showed it to my previous testers to see if they considered this a logical rendering of the information. Each one was very enthusiastic and agreed that these categories, some of which they had specifically requested, had made it into the final draft. Once I had confirmation the draft made sense to the users, the draft was pushed as the live version of the documentation wiki.
Challenges
One of the biggest challenges with reorganizing the wiki space with user input was realizing that each of the five users maintain an individual outlook for their own organization styles. This was evident in analyzing the card sort Jamboards. No two users organized their Jamboards in exactly the same way! This is because every user is an individual. That being said, it was still extremely beneficial to receive their feedback, and to generalize some repeated recommendations between users. In the end, I had to combine user feedback with my own information architecture expertise and insider knowledge of HTRC Analytics to come up with a final solution.
Another obvious challenge was recognizing how much more work the HTRC Analytics documentation needs. A major complaint from HTRC users is that they struggle hopping between the different platforms needed to use and understand HathiTrust resources. There is the Digital Library platform, which is completely separate in its mission and online presence from HTRC Analytics, as well as their documentation pages, plus HTRC Analytics’ website and our documentation wiki (which is an Atlassian product). I would like to cut down on some of these platforms our users must navigate, potentially hosting our documentation pages on the HTRC Analytics site itself. Doing so would also require devising a major page-level content audit, as well as content strategy and content management plans. These are all major undertakings and will need to be organized and deployed with cross-functional team input and help. For now, these plans are beyond the scope of this initial reorganization.