NortheasternCommons.png

Northeastern Commons

Northeastern Commons

Overview

Summary: In October 2020 I was hired to Northeastern Library as the Coordinator of Northeastern Commons an online platform focused on creating an accessible information ecosystem that fosters collaboration between Northeastern affiliates and the broader global community. After exploring the platform at the start of my job, I realized it wasn’t very user friendly, so I started to do user research, which eventually lead to the redesign of the whole platform.

Roles: Project Manager, UX Researcher & Designer, Accessibility Evaluator

Programs Used: Adobe XD, Adobe Illustrator, Google Jamboard, Browser Stack, Site Improve, VoiceOver on Mac

UX Techniques Used: Heuristic Evaluation, Landscape Analysis, Stakeholder Interviews, User Interviews, Think-A-Loud Protocol, Wireframes, Manual Accessibility Testing

 

Background

On the Northeastern Commons users can create and/or join discussion groups based on research, labs, or events, and connect with others interested in similar academic interests or community-based projects. The groups allow for members to stay updated on the group’s activity and events, connect to other group members using discussion boards, share documents in document repositories, and manage group zoom events including a repository of previous events for users to look upon.

The platform’s other features aid in understanding research happening across the university and within users individual groups by having the following features: robust user profiles with document storage and sharing, an activity feed users can filter to their own networks or Commons wide, a members page to search for possible fellow collaborators, and private messaging to other members.

Prior to the redesign the Commons was using WordPress as it’s base with BuddyPress and other plugins to create the functionality listed above.

 

Heuristic Evaluation

The Commons was a network of sites with the same functionality, so I conducted basic heuristic evaluations for each site’s differences. Overall the findings were consistent across sites. I used Nielsen Norman Group’s 10 Usability Heuristics for User Interface Design for the evaluation. 

Key Findings 

Screenshot of a document upload screen. The spacing and options are confusing.

An example of one of the document download pages, called “Docs”

  1. Match between system and the real world: Links specifically within the platform’s architecture did not have any visible marker that they were links to be clicked, users would assume they were normal text if they didn’t mouse over the text. 

  2. Match between system and the real world: Often the language of the platform did not match previous web conventions of language for platforms. For example, “Freshness” to denote date posted and “Voices” to denote users. 

  3. Match between system and the real world: icons made for a confusing experience for users. Specially the icons had no legend on the platform and often didn’t make sense. For example, a delete icon was a set of four boxes with a X through one.

  4. Aesthetic and minimalist design: Across the whole platform spacing of elements and colors were confusing. The colors were also not web-accessible. 

  5. Visibility of System Status: After posting a discussion post, the screen would glitch and a user would not be able to tell their message posted until after refreshing the screen. 

  6. Error Prevention: It was often impossible to tell that input would result in an error until after a user had already gone through all the steps of a process, and then would receive an error message at the end of the process. 

  7. Consistency and standards: There were three different tabs that all allowed for document upload and management across the platform; files, BuddyDrive, and docs, this lead to confusion of which was the correct tab for document uploading.  

 

Decision Point

After this evaluation, I talked with my teammate, who had been the primary manager of the space before me about my findings. I asked her if any of the user’s prior had come to her about any problems that matched with my findings. She said yes and then we decided to go to our boss to talk about a possible redesign. After our conversation we got the go-ahead, we began the research needed to do a redesign.

 

Landscape Analysis

Because our Commons instance had been built off the Humanities Commons and CUNY Academic Commons, I reached out to both groups to chat about what problems they were facing with their Commons and to see if any problems were simliar. 

After my discussion with both groups, I learned that continuing with Commons in a Box was maybe not ideal for the longevity of Northeastern Commons. They both were facing similar issues I had noted in my evaluation. And Humanities Commons had recently done an accessibility assessment of the platform, which they kindly shared with me, and the accessibility was not ideal as well. 

I decided to conduct stakeholder interviews and user interviews to better understand what our users were hoping for on the platform and if there might be a different solution than using BuddyPress and Commons in a Box to create the platform.

 

Stakeholder Interviews

Since the Commons is based on groups my stakeholders were the leaders of those groups. I met with the College of Professional Studies who were our largest stakeholder, they wanted to use the Commons to connect their alumni, professors, and current students to promote lifelong learning connections using the Commons. The Boston Area Research Institute wanted to use the Commons as a way to connect Northeastern faculty, staff, and students to community leaders and policy makers of Boston. 

In my interviews with stakeholders I used the following questions as a guide: 

Screenshot of a google jamboard created affinity diagram.

Affinity diagram from stakeholder conversations created using Google Jamboard.

  1. What is the goal or goals of the commons? 

  2. Are there ways users are already completing these goals?  

  3. What makes these processes usable or not usable?

  4. What will a student be able to do on the commons? A faculty member?

  5. How will those audiences experience of the commons be different? 

  6. What assumptions do we have about these audiences?

  7. What features do your users already use on the Commons? 

  8. What do they want to be able to do and currently cannot using the Commons?

  9. What will make it beneficial for people to use this platform over others? 

From those conversations I created an affinity diagram that was condensed down into the following themes: 

  1. Accessible Intuitive Interface

  2. Connectivity between Northeastern web presences and the Commons

  3. Connection between University affiliates and outsides partners

  4. Space for building connection and collaboration on the Commons

  5. Help Documentation and Guidelines for Use

 

User Interviews

At this point in the process, I wanted to reach out to users to understand how they felt about the Commons and their needs. Because the Commons didn’t have many active users at the time and this was taking place during the COVID-19 pandemic, I wasn’t able to talk to as many users as I would have hoped during this process. 

However the ones I did talk to gave me the following themes: 

  1. The Commons is a way they would like to connect with others doing similar research, for example, a student could be in a conversation with a faculty member around a research topic they both are interested in. 

  2. A user profile should not just focus on academic pursuits like publications, there should also be space for press, projects, and talks because not every users would be so academic focused. 

  3. The Commons should easily allow for event sharing and hosting, especially during the COVID age. 

  4. The Commons itself is not intuitive, users were confused by icons and user flow. 

    • The Commons despite having a document repository feature only allowed for the uploading of very small files. 

    • Logging into the Commons was confusing because of the two login types, Northeastern Single Sign On and Social Media logins. Users would forget they created an account with the single sign on and then create a social account and the two would not merge. 

    • The search was unusable and users were unable to find users interested in similar research that they were.

If I would have had more time and resources I would have asked users this set of questions: 

  1. Tell me about how you use online networking systems? 

    • What are the most important features? 

  2. Describe to me your experience with Northeastern online systems like Canvas and Blackboard. 

    • What makes you not want to use them or use them?

  3. How do you find groups at Northeastern to connect with? 

    • What pieces of information are important for you?

  4. Describe how you learn about research happening outside your department at Northeastern? 

    • Where you do learn about this? 

  5. How do you feel about collaboration online? 

    • Describe to me how you collaborate with others online? 

    • What makes this easier? What makes this harder?

  6. What devices do you use to do collaboration online? 

  7. If you were to use a Northeastern created networking and collaboration site, what features do you think are important for how you work? 

 

Switch from BuddyPress to BuddyBoss 

After talking with the stakeholders and users, I consulted with my teammate again on if we would continue using BuddyPress and a suite of plugins or if we would look for a new way of creating the platform. We decided together that it would make more sense to use a new base plugin, not only BuddyPress was unable to facilitate all of our users goals but also because the previous installation and build was not well documented and we believed it would be easier, faster, and more affordable to create it from scratch. 

We decided to use the BuddyBoss Platform for Northeastern Commons. It would help with technical debt because opposed to BuddyPress, it did not use many add-on plugins for base functionality. The BuddyBoss Platform out of the box was also more intuitive and user friendly than the previous build and we would be able to tailor the experience for Northeastern users easily. 

 

User Testing BuddyBoss 

After moving from BuddyPress to BuddyBoss, I wanted to make sure that users could complete the basic tasks of the platform easily. To test this I used think-a-loud protocol with users over Zoom, a survey of the System Usability Scale (SUS), and Post Interview questions to test the basic installation of BuddyBoss to see what changes we would need to make for our users.  

The Tasks

  1. Imagine you are interested in finding which professors use Northeastern Commons so you can go through their profiles to see their research interests. How would you go about finding professors on the platform? 

  2. Now imagine that you are interested in learning about who on the commons you could network with around makerspaces, how would you go about finding other users interested in makerspaces? 

  3. Let’s say you are interested in reaching out to another member to ask them a question, using the website how would you do that? 

  4. Now imagine that the user you messaged, messaged you back and you want to follow and connect with them through the platform, how would you do that? 

  5. Let’s say you want to join the Example Group and add a new discussion to the discussion board so other users can give you feedback on a project. Using the website create a discussion called “Example discussion” with the prompt. “looking for feedback on a project.” 

  6. Now imagine you want to view all of the forums you have created or contributed to so you can see the new comments on those forums, using the platform show me how you would do that.  

  7. Let’s say that you notice you get a lot of emails from Northeastern Commons that are duplicates of notifications on the platform, how would you go about changing your email preferences for the platform? 

 Recommendations

  1. Member Cards should have a self-defined title of the user, users when searching for members wanted to be able to have more than a name to go on before clicking through and seeing their profile.

  2. Change Icon for Messaging Inbox, it is not easily recognized as such, 3 out of 5 users were confused by it. 

  3. Add a Clear Search Button for search results. The platform saves the last search a user did on the search page, users expected a way to quickly clear search for a new one. 

  4. Change “Connection” label to new word, on the platform. The connection term is used to denote the people you have mutually connected with, the suggestion to use the language LinkedIn uses, “My Network.” 

  5. Have the personal sidebar open at the beginning of when someone logs in. It was needed to complete task 6, and users did not think to check the collapsed sidebar, because it was just icons without explanation to them. 

  6. Change “Forums” to “Discussions” in sidebar because that more aptly reflects language used in the groups themselves.

 

Wireframing

Taking all the information gathered thus far, I began to wireframe different parts of the Commons.

Wireframe of homepage, the boxes include a Welcome to the Commons, Activity box, Digital Repository Tie In, Featured Group, Groups List, and Initiatives.

Wireframe of possible homepage design.

Wireframe of Profiles, including space for: Academic Interests, Education, Groups, Press, Bio, Publications, Projects, and Talks.

Wireframe of possible profile page.

 

Accessibility Testing 

Screenshot with boxes around elements that needed to have focus states to be keyboard accessible.

An example of places we identified that needed to have focus states to be keyboard accessible.

Accessibility of this platform was extremely important to everyone involved. To help with this effort, we hired a student to help with manual accessibility test. I taught her about accessibility, how to conduct manual accessibility testing (including keyboard testing and screen reading testing), and how to test difference across browsers using Browser Stack. 

We both worked together to test the accessibility of the Commons platform and created a list of changes need to make the Commons more keyboard and screenreader friendly. 

Most of the changes were focused on creating focus states across the platform and fixing labels in the code so a screenreader would be able to identify elements correctly. 

 

Final Designs

The Commons base development has finished, users have noted that the Commons is much easier to use now and is not as confusing or as buggy as the previous build. To see the full website please go to northeasterncommons.org.

Screenshot of the homepage of a group within the Commons.

When a user lands on the group page, they are greeted with the activity feed, along with a gloss on the right side to help them understand the tabs they will find system wide for groups. Along with a prompt to look in the Commons help documentation if they need help.

 
View of the Events Page on a group within the Commons.

A view of a group calendar, a new feature added based on user conversations in the new iteration of the Commons.

Groups page on the Commons showing the "My Groups" view.

When a user selects Groups in the upper navigation they will be brought to the group page where they will be able to select to join groups, or view the groups they belong to.

 
View of the Discussions page within a group.

View of the Discussions page within a group, which is vital for many groups as a tool of communication and memory keeping.

 
 

Reflection

  1. Designing within an existing platform can be challenging: Many of the issues found were native within the platforms we selected to use for the creation of the Commons. Iterating on something someone else built has you ask very different types of questions than being able to build the platform yourself because you are confined to specific user flows built into the platform. 

  2. Talking with folks using similar WordPress instances was necessary: Speaking to both the Humanities Commons and CUNY Academic Commons not only corroborated the problems I noticed in my heuristic evaluation, but also led to conversations about technical debt they were experiencing because of the choices they made early on, because I was in that early process, I was able to learn from their previous knowledge.  

  3. Working closely with my software developer was helpful: The changes to the platform would not have been possible without my teammate and Commons developer Jeanine. Many of the choices we made throughout the process were informed by limitations not only from the platform, but on how Jeanine could tailor the platform for our needs.  

  4. User Experience and Development is a cycle: We are still working through many of the accessibility changes we found during this project. Furthermore, our new users are finding issues or have needs that our research did not touch on or find. Prioritization of most important features and changes are needed in continued website maintenance and upkeep.