Where’s that data again? The sequel
In 2021, Rebecca Blakiston, UX researcher at Ad Hoc and the previous UX Strategist at the University of Arizona Libraries, wrote an article about the creation and impact of the University of Arizona Libraries’ research repository.
In this article, Rebecca explained the problems that our UX team was facing at the time: having hundreds of research findings but nowhere to store them in an organized fashion. Without having a centralized location to store this research, it posed a risk of wasting time and energy recreating studies we had already done or spending time parsing through documents to find a complete research study. To address these concerns the UX team created a research repository.
What’s a research repository?
The research repository, or research repo, is a hub where our UX team stores past findings, trends, and next steps that we have for UX projects at the library. It was created as a reference tool so we could go back and look at past research and use it to inform current projects.
Our repo was created in a Notion table with tags to make categorizing and filtering the data more simple and easier to browse. Once the table was created, the team retrospectively created repo entries for research studies that dated all the way back to 2016. The entries in the repo had a template to follow, so all items were consistent in formatting and what information they included.
The creation of the research repo was huge for our team. It addressed the concerns of wasting time looking for past research findings and continues to serve as a hub for our research. It additionally made it easier to share our research findings and methods with other library colleagues.
However, as the repository grew, we noticed usability issues in the initial design of the repo that prompted our team to audit and address its pain points. This article will cover how we approached the redesign of our repo and the impact of our redesign.
Usability issues with our research repo
My name is Megan Straffon and I have been working on the UX team at the University of Arizona Libraries for 2 years. When I decided that the research repository needed a makeover, I was only thinking cosmetic. I designed a new banner for it in Canva and was ready to call it a day.
However, the UX team decided that if our goal was to have more people in other library departments use and access our repo findings, we had to make it more accessible and usable. Making cosmetic changes to the repo snowballed into a complete redesign of our research repository.
We identified a few usability issues we wanted to address in the repo:
- The repo used a lot of UX jargon to explain the methods we used in various projects, which made it difficult to understand for people who are not a part of our team or don’t have a background in UX.
- The number of columns used to organize different features of our repo entries, like the library department we worked with or the UX research method used, was far too many and made skimming for information extremely difficult.
We decided that the repo needed a full-blown makeover to better serve its intended purpose of documenting and sharing research findings in an accessible format.
Planning the redesign
To plan our redesign, we created user stories to help steer us in the right direction.
We did our user stories in Figma. We considered many different user experiences, voted on the ones that we thought were the most important, and then combined them into our priority user stories. The user stories contained several audiences, needs, and tasks of repo users. This process allowed us to narrow down the priorities of our repo and gave us a common terminology to talk about our users.
Our prioritized user stories were:
- As a full-time staff on the UX team, I want to quickly find and analyze UX research insights so that I can create a user-informed strategy and plan UX research, content, & design projects.
- As a UA Libraries employee, I want to see results of talk-back boards so that I know how people responded to the whiteboards I saw when I exit the library.
- As a full-time staff on the UX team, I want to pull a relevant research repo entry so that I can share our work with library stakeholders to advise on projects.
With this newfound clarity, we were ready to tackle the research repo makeover.
What did we do? And why?
With our intended audiences clear, our team then decided this project’s scope and major goals. These goals of the redesign included:
- Reducing the number of columns and amount of information in the repo table
- Streamlining how many UX methods are tagged for each article
- Creating content guidelines with a consistent naming structure to make the repo more browsable
Auditing the information
The columns and tagging system that we implemented in the initial repo was very thorough but did not align with our new goal of making it accessible for anyone to use. We found that the research repo was overwhelming the intended audience with information and made it too difficult to use because you couldn’t see all the columns at once and some of the column titles were unclear or had duplicative information.
We wanted to review what information we included in the repo, whether we wanted to keep that information, and if that information should be displayed in the repo table or within the individual entries.
We audited the columns and tags by first deciding if we wanted to keep that information in the repo. For the columns and tags we wanted to keep, we marked them as “slay,” meaning we wanted to keep them. Then, for all information we decided we wanted to keep, we decided whether they should appearing the table, in the entry itself, and or both. After these revisions, only 4 tags appeared on both the table and the card and 3 tags appeared only on the card of each article.
Streamlining our methods
Alongside our issue of having too many columns, we also discovered there were too many UX methods as well. The UX team did a content overhaul and analyzed each method in a FigJam and placed each one in our three categories: Slay, Mid, or Flop. Slay meant that we would keep it as it was and met our criteria. We decided the methods in the slay category needed to be:
- Broad enough to reflect research we typically do
- Possess an easily understandable name
- Reflect methods we discuss with our intended audience so they could use the methods tags to filter our research repo articles
Mid was our gray zone for the ones we weren’t sure about. We came back to the mid category several times to finally sort them into our final slay and flop categories. Our flop category contained the methods deemed not necessary. Our criteria for putting methods in the flop category was if the method repeated a different method or was too jargony for a non-UXer to understand. We started with 19 tags and ended with 8 after this review process.
Setting content guidelines
Once we decided on the format of the research repo table, we then had to address content guidelines. The naming of our articles was inconsistent and not easily skimmable. We decided to make our entry names more clear, concise, and specific by including the name of the project or product, and the main research goals in 3–5 words.
To keep our articles consistent both visually and in relativity to each other, if a certain project contains several articles in our repo, they will all have the same emoji. Otherwise, every article needs a different emoji to maintain the difference. In addition, we emphasize only using completely necessary tags. Doing so helps avoid visual clutter and increases the speed and ease for any user. This ensures that the repo will be usable and skimmable for the foreseeable future, and a tool that can be sustainable long term.
What was our impact?
By making these revisions, our research repository is now more accessible and enjoyable to use for not only ourselves but the rest of our intended audience. The changes we made to our research repository set us up for long-term success. We now have clear content guidelines for our team to follow, so our articles are skimmable and our tags are consistent.
We also changed the repo entry template to have more clear sections that are easier to complete and read. Our audience is now more likely to find what they need in our repository and our team can easily review and update our research. The UX team continues to use this to share with library stakeholders and keep ongoing records of our research. Feel free to take a look at our new repo with updated articles!
Before:
After:
What I learned
The research repo has shown me the importance of habitually keeping tabs on research and having a good place to store that information. In this project, I learned that when you use something often enough and get used to going through the motions, it can slip your mind that these tools can be improved.
This project was a much larger undertaking than I originally expected, and I would not have done it without the input and expertise of my team members. This was also my first time being the leader of a refresh project and it taught me the importance of collaboration with others. In future UX projects, I will use what I learned about research and collaboration in order to create the best end product possible.
